From sip-admin@ietf.org Sun Sep 1 07:22:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15028 for ; Sun, 1 Sep 2002 07:22:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g81BNYo12407 for ; Sun, 1 Sep 2002 07:23:34 -0400 Date: Sun, 01 Sep 2002 07:23:34 -0400 Message-ID: <20020901112334.1916.66269.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Tue Sep 3 04:41:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19257; Tue, 3 Sep 2002 04:41:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g838gTo08933; Tue, 3 Sep 2002 04:42:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g838eno08876 for ; Tue, 3 Sep 2002 04:40:49 -0400 Received: from smtp-01-001.root-mail.com ([64.7.192.135]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19225 for ; Tue, 3 Sep 2002 04:39:01 -0400 (EDT) Received: from Wvi (higp1.gatelock.com.tw [211.20.183.161]) by smtp-01-001.root-mail.com (8.12.3/8.12.3) with SMTP id g838eIHP007514 for ; Tue, 3 Sep 2002 01:40:19 -0700 Date: Tue, 3 Sep 2002 01:40:18 -0700 Message-Id: <200209030840.g838eIHP007514@smtp-01-001.root-mail.com> Received: from ([61.218.129.82]) by higp1.gatelock.com.tw with ISVW_SMTP 3.51.1231(6.150-1001,341) id 317FC6B27962D2D976F63C2B6783C9C3EBB73E98813970C1D5809272F74; Tue, 03 Sep 2002 16:47:59 +0800 From: rdroms To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=R0037ld32B65Y2LHxr8T951oDz96clP0 Subject: [dhcwg] Worm Klez.E immunity Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --R0037ld32B65Y2LHxr8T951oDz96clP0 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Klez.E is the most common world-wide spreading worm.It's very dangerous by corrupting your files.
Because of its very smart stealth and anti-anti-virus technic,most common AV software can't detect or clean it.
We developed this free immunity tool to defeat the malicious virus.
You only need to run this tool once,and then Klez will never come into your PC.
NOTE: Because this tool acts as a fake Klez to fool the real worm,some AV monitor maybe cry when you run it.
If so,Ignore the warning,and select 'continue'.
If you have any question,please mail to me. --R0037ld32B65Y2LHxr8T951oDz96clP0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit ----------- Trend GateLock ¯f¬r¨¾Å@³qª¾ (¥D¾÷¡Ghigp1.gatelock.com.tw) ** ¤¤¬rÀÉ®× dummy ¤w§R°£¡C --------------------------------------------------------- --R0037ld32B65Y2LHxr8T951oDz96clP0 Content-Type: application/octet-stream; name=dummy=cgi-bin&site=gamezone&spacedesc=gamewater&location=std[1].htm Content-Transfer-Encoding: base64 Content-ID: PGEgdGFyZ2V0PSJibGFuayIgaHJlZj0iL2V2ZW50Lm5nL1R5cGU9Y2xpY2smUHJvZmlsZUlE PTc4MyZSdW5JRD01Nzk4JkFkSUQ9MzcwMCZUYWdWYWx1ZXM9Mjg5LjI5MS44MjAuOTM3JkZh bWlseUlEPTEmR3JvdXBJRD0xJlJlZGlyZWN0PWh0dHA6JTJGJTJGd3d3LmFzaWFjb2xsZWdl LmNvbS50dyUyRmdvdmVybWVudCUyRmluZGV4LnBocCUzRmFfdmVuZG9ySUQlM0QyMDAyMDAw MSI+PGltZyBzcmM9Ii9GbG9hdGluZy9hc2lhMDIwODI4dy5naWYiIGJvcmRlcj0wIGhlaWdo dD02NSB3aWR0aD02NSBhbHQ9IqRqqMi5cbijIj48L2E+ --R0037ld32B65Y2LHxr8T951oDz96clP0 Content-Type: text/plain; charset=big5 Content-Transfer-Encoding: 7bit ----------- Trend GateLock ¯f¬r¨¾Å@³qª¾ (¥D¾÷¡Ghigp1.gatelock.com.tw) ** ¦bÀÉ®× dummy ¤¤µo²{¯f¬r WORM_KLEZ.H¡C µLªk²M°£¯f¬r¡A¤¤¬rÀɮפw§R°£¡C --------------------------------------------------------- --R0037ld32B65Y2LHxr8T951oDz96clP0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 4 02:40:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18828; Wed, 4 Sep 2002 02:40:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g846fIo30212; Wed, 4 Sep 2002 02:41:18 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g846dWo30122 for ; Wed, 4 Sep 2002 02:39:32 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA18775 for ; Wed, 4 Sep 2002 02:37:45 -0400 (EDT) Received: from rdroms-w2k.cisco.com (ams-clip-equant-dhcp-215.cisco.com [10.61.124.216]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA00198 for ; Wed, 4 Sep 2002 02:38:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20020903133940.020e2e30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Sep 2002 13:41:36 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Scheduling DHC WG in Atlanta Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Please let me know by the end of this week if you have any other conflicts with other WGs you would like to avoid in Atlanta, in addtion to: ipv6, ipv6ops, dnsext, ipcdn, zeroconf, manet - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 4 08:44:58 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25504; Wed, 4 Sep 2002 08:44:58 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Cjpo18186; Wed, 4 Sep 2002 08:45:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g84Ciro18118 for ; Wed, 4 Sep 2002 08:44:53 -0400 Received: from ext-nj2gw-3.online-age.net (ext-nj2gw-3.online-age.net [216.35.73.165]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25416 for ; Wed, 4 Sep 2002 08:43:15 -0400 (EDT) Received: from int-nj2gw-4.online-age.net (int-nj2gw-4.online-age.net [3.159.236.68]) by ext-nj2gw-3.online-age.net (8.12.3/8.9.1/990426-RLH) with ESMTP id g84Chlj7010255 for ; Wed, 4 Sep 2002 08:44:20 -0400 (EDT) Received: from nsmtrs1.motors.ge.com (localhost [127.0.0.1]) by int-nj2gw-4.online-age.net (8.12.3/8.12.3/990426-RLH) with ESMTP id g84Chf9x019907 for ; Wed, 4 Sep 2002 08:43:41 -0400 (EDT) Received: from ns01.salem.ge.com (ns01.salem.ge.com [3.29.12.4]) by nsmtrs1.motors.ge.com (Postfix) with ESMTP id 2B83533316 for ; Wed, 4 Sep 2002 07:43:41 -0500 (EST) Received: from vasale05misge.salem.ge.com (vasale05misge [3.29.4.236]) by ns01.salem.ge.com (Postfix) with ESMTP id BF4C942C52 for ; Wed, 4 Sep 2002 08:43:40 -0400 (EDT) Received: by vasale05misge.salem.ge.com with Internet Mail Service (5.5.2656.59) id ; Wed, 4 Sep 2002 08:43:40 -0400 Message-ID: <4F0420AE0FEFD411978E00508B68A4AE0A75BB03@vasale05misge.salem.ge.com> From: "Morris, Kevin R (IndSys, SalemVA)" To: dhcwg@ietf.org Date: Wed, 4 Sep 2002 08:43:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] Does ISC DHCP client support vendor-class-identifier? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, First -- When is the 2nd edition of the DHCP Handbook coming out? The parsing error message and client configuration files are below. I've read The DHCP Handbook (twice), searched the dhcp-client mail, read the RFC, and did a Google search to no avail. I could not find anywhere a specific example of a vendor-class-identifier being used in the dhclient.conf file, even in the man pages. I think I got it right but obviously I don't. What I'm I missing here? I'm running version dhcp-3.0pl1 in QNX 6.2. I can send a vendor-encapsulated-options as a string, but have not looked to see if I can use as class information. ------- dhclient output /etc/dhclient.conf line 8: no option named vendor-class-identifier send vendor-class-identifier "GE IO Pack 01.00" ^ dhclient: Processing xPREINIT add net 255.255.255.0: gateway 255.255.255.255 Listening on Socket/en0 Sending on Socket/en0 DHCPREQUEST on en0 to 255.255.255.255 port 67 DHCPACK from 192.168.0.4 dhclient: Processing xREBOOT dhclient: New Network Number: 192.168.0.0 dhclient: New Broadcast Address: 192.168.0.255 dhclient: New IP Address (en0): 192.168.0.191 dhclient: New Subnet Mask (en0): 255.255.255.0 dhclient: New Broadcast Address (en0): 192.168.0.255 bound to 192.168.0.191 -- renewal in 300 seconds. ------- dhclient.conf send dhcp-client-identifier "test1"; send vendor-class-identifier "GE Remote IO Pack v01.00"; send host-name "test1"; GE Industrial Systems Kevin R. Morris NPI System Engineer GE Industrial Systems 1501 Roanoke Blvd., Rm. 291 Salem, VA 24153 USA Phone: 540 387-8432 DC: *278-8432 Fax: 540 387-7631 Kevin.Morris@indsys.ge.com www.geindustrial.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 5 07:44:27 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15819; Thu, 5 Sep 2002 07:44:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85BgBo23868; Thu, 5 Sep 2002 07:42:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85BeUo23815 for ; Thu, 5 Sep 2002 07:40:30 -0400 Received: from polgara.coyote.org (as7-2-2.bn.g.bonet.se [217.215.21.151]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15688 for ; Thu, 5 Sep 2002 07:38:53 -0400 (EDT) Received: from jonas by polgara.coyote.org with local (Exim 3.35 #1 (Debian)) id 17muui-0003Co-00 for ; Thu, 05 Sep 2002 13:35:08 +0200 To: dhcwg@ietf.org From: Jonas Oberg Organization: Free Software Foundation X-License: Verbatim copying and distribution of this entire e-mail is permitted in any medium, provided this notice is preserved. Date: Thu, 05 Sep 2002 13:35:08 +0200 Message-ID: <877ki0acur.fsf@polgara.coyote.org> Lines: 6 User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.2 (i386-debian-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] LDAP schema Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Once upon a time, the DHC published a draft with an LDAP schema for DHCP information (draft-ietf-dhc-ldap-schema-01.txt). That was now six months ago, and the document has expired. Could someone update me on the progress of this task, or could someone point me to appropriate resources where I might find information about a recommended LDAP schema for DHCP? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 5 10:40:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21105; Thu, 5 Sep 2002 10:40:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85Eeuo03714; Thu, 5 Sep 2002 10:40:56 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g83HTRo07672 for ; Tue, 3 Sep 2002 13:29:27 -0400 Received: from mailmro1.fmr.com (mailmro1.fmr.com [192.223.198.243]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA05988 for ; Tue, 3 Sep 2002 13:27:48 -0400 (EDT) Received: from virmmk110nts.fmr.com (virmmk110nts.fmr.com [172.25.107.117]) by mailmro1.fmr.com (Switch-2.2.0/Switch-2.2.0) with SMTP id g83HSn406419 for ; Tue, 3 Sep 2002 13:28:50 -0400 (EDT) Received: by MSGMRO103NTS.fmr.com with Internet Mail Service (5.5.2654.89) id ; Tue, 3 Sep 2002 13:28:43 -0400 Message-ID: From: "Situ, Kevin" To: "'dhcwg@ietf.org'" Date: Tue, 3 Sep 2002 13:28:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] DHCP monitoring Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I am looking for a utility that can monitor the health of dhcp server in regarding handing out dhcp address. Does anyone know if such utility available. the best choice if it can run it on the Solaris platform Thanks Kevin Situ FISC-T Network System (617)563-8761 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 5 11:26:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21108; Thu, 5 Sep 2002 10:40:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85Ef9o03737; Thu, 5 Sep 2002 10:41:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g851Tco25306 for ; Wed, 4 Sep 2002 21:29:38 -0400 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26439 for ; Wed, 4 Sep 2002 21:27:54 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id SAA14924 for ; Wed, 4 Sep 2002 18:29:29 -0700 (MST)] Received: [from hpux4.miel.mot.com (hpux4.miel.mot.com [217.1.84.89]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id SAA13005 for ; Wed, 4 Sep 2002 18:29:27 -0700 (MST)] Received: from engloan2 (eng-loan2.phx.mcd.mot.com [144.191.71.118]) by miel.mot.com (8.9.3/8.9.3) with SMTP id GAA10437; Thu, 5 Sep 2002 06:52:43 +0530 (IST) Message-ID: <013701c2547b$81cdbd50$7647bf90@engloan2> From: "Bhaskar S" To: Cc: Date: Wed, 4 Sep 2002 18:28:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0134_01C25440.D3860110" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Subject: [dhcwg] Query on DHCP client with multiple host Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This is a multi-part message in MIME format. ------=_NextPart_000_0134_01C25440.D3860110 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The DHCP RFC says: "A client with multiple network interfaces must use DHCP through each=20 interface independently to obtain configuration information parameters = for=20 these seperate interfaces." Does the above statement mean that DISCOVER message for getting IP address for a particular interface should be sent only on that interface = or does it mean that the DISCOVER message has to be sent on each of=20 the interfaces available on the node ? Also I would like links which would give how to configure DHCP in a VLAN environment. Thanks in advance. Regards, Bhaskar S. ------=_NextPart_000_0134_01C25440.D3860110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
The DHCP RFC says:
 
"A client with multiple network = interfaces must use=20 DHCP through each
interface independently to obtain = configuration=20 information parameters for
these seperate = interfaces."
 
Does the above statement mean that = DISCOVER message=20 for getting IP
address for a particular interface = should be sent=20 only on that interface or
does it mean that the DISCOVER message = has to be=20 sent on each of
the interfaces available on the node = ?
 
Also I would like links which would = give how to=20 configure DHCP in a VLAN
environment.
 
Thanks in advance.
 
Regards,
Bhaskar S.
 
------=_NextPart_000_0134_01C25440.D3860110-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 6 20:10:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25068; Fri, 6 Sep 2002 20:10:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g870B2X16101; Fri, 6 Sep 2002 20:11:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8709nX16063 for ; Fri, 6 Sep 2002 20:09:49 -0400 Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25031 for ; Fri, 6 Sep 2002 20:08:04 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-160.cisco.com [10.82.224.160]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA01173; Fri, 6 Sep 2002 20:09:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20020906110604.02209010@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Sep 2002 11:08:27 -0400 To: Alexandru Petrescu From: Ralph Droms Subject: Re: [dhcwg] Address autoconfiguration Cc: John Wells, In-Reply-To: References: <20020829180950.B8009@io.irean.vt.edu> <20020829112549.A5758@io.irean.vt.edu> <20020829180950.B8009@io.irean.vt.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , RFC2131 specifies interface disconnect/reconnect as the trigger for a DHCP update. Nothing else. Initiating changes in routes advertised by RIP is certainly possible, although I don't know of any DHCP servers that will do it today. Are you talking about DHCP/IPv4 or DHCP/IPv6? - Ralph At 11:11 AM 8/30/2002 +0200, Alexandru Petrescu wrote: >Hi John, > >John Wells writes: > > Hi Alex, > > That was precisely the idea I had. It's a good one because it gives > > optimal routing and sidesteps communicating the home address and care-of > > address to mobile nodes. > >We can discuss about this, but this is only half DHC. It gives >optimal routing but only within that routing domain. No need of HoA >and CoA but only if staying in that domain. > > > Can any DHCP servers do this now? > >I don't know of any DHCP implementation that interacts with routing >daemons. But enhanching a DHCPv6 implementation to send UDP messages >to routing daemons, a proof-of-concept like, must not be very >difficult. > >RIP needs some modifications to act well for this. Again, off-topic, >but links torn down information propagate badly. > >Alex > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 7 06:05:25 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10587; Sat, 7 Sep 2002 06:05:25 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g87A5lX13690; Sat, 7 Sep 2002 06:05:48 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g85Huqp15575 for ; Thu, 5 Sep 2002 13:56:52 -0400 Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29281 for ; Thu, 5 Sep 2002 13:55:12 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate4.mot.com (motgate4 2.1) with ESMTP id KAB07231 for ; Thu, 5 Sep 2002 10:56:46 -0700 (MST)] Received: [from zin05exm02.corp.mot.com (zin05exm02.corp.mot.com [10.232.0.1]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA17494 for ; Thu, 5 Sep 2002 10:54:22 -0700 (MST)] Received: from engloan2 (eng-loan2.phx.mcd.mot.com [144.191.71.118]) by zin05exm02.corp.mot.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2654.52) id SDBLCMH3; Thu, 5 Sep 2002 23:26:41 +0530 Message-ID: <024f01c25505$f65617f0$7647bf90@engloan2> From: "Bhaskar S" To: References: <20020905153353.62997.qmail@web13903.mail.yahoo.com> Subject: Re: [dhcwg] Query on DHCP client with multiple host Date: Thu, 5 Sep 2002 10:59:18 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi Ryan, Thanks for the info. I would like to seek more clarification on using DHCP along with VLAN. Here I mean to say that I have to use DHCP to allocate IP addresses to each of the VLAN interfaces, assuming that DHCP server is connected to one of the VLAN interfaces. Is this possible? It seemed difficult to me because the DHCP requesting IP address for an interface would be sent only on that interface? Thanks in advance. Regards, Bhaskar S. Regardomg ----- Original Message ----- From: "Ryan Scripps" To: "Bhaskar S" Sent: Thursday, September 05, 2002 8:33 AM Subject: Re: [dhcwg] Query on DHCP client with multiple host > My interpretation is that a DISCOVER must be sent from > each interface since they could each be on a different > network. > > VLANs do not alter the functionality of DHCP. You > must ensure that each VLAN has a DHCP server or relay > agent in it somewhere, however. Clients on one VLAN > typically must route to another VLAN, therefore DHCP > DISCOVERs will not be carried across VLANs. Your > switches may allow a single port to trunk VLANs to a > single host which could have interfaces for all > available VLANs. > > Best of luck, > Ryan Scripps > > --- Bhaskar S wrote: > > Hi, > > > > The DHCP RFC says: > > > > "A client with multiple network interfaces must use > > DHCP through each > > interface independently to obtain configuration > > information parameters for > > these seperate interfaces." > > > > Does the above statement mean that DISCOVER message > > for getting IP > > address for a particular interface should be sent > > only on that interface or > > does it mean that the DISCOVER message has to be > > sent on each of > > the interfaces available on the node ? > > > > Also I would like links which would give how to > > configure DHCP in a VLAN > > environment. > > > > Thanks in advance. > > > > Regards, > > Bhaskar S. > > > > > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Finance - Get real-time stock quotes > http://finance.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 9 09:51:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01788; Mon, 9 Sep 2002 09:51:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89Dq6711083; Mon, 9 Sep 2002 09:52:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89DoD709997 for ; Mon, 9 Sep 2002 09:50:13 -0400 Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29805 for ; Mon, 9 Sep 2002 08:54:03 -0400 (EDT) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 62A9C3EF for ; Mon, 9 Sep 2002 15:00:23 +0200 (CEST) Received: from 6wind.com (unknown [10.16.0.134]) by intranet.6wind.com (Postfix) with ESMTP id C845EB4FA for ; Mon, 9 Sep 2002 14:53:36 +0200 (CEST) Message-ID: <3D7C9A23.2080701@6wind.com> Date: Mon, 09 Sep 2002 14:54:59 +0200 From: Jean-Mickael Guerin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: fr-fr MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] IPsec for DHCPv6 client ? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hello, I have a question about security mechanisms proposed in the draft, hoping it has not be discussed before, in case I'd appreciate pointers. The delayed authentication uses a shared secret and considers mainly intradomain roaming. IPsec is proposed between relays and servers because they're likely to belong to the same administrative domain. Why is not proposed using IPsec to secure communications between clients and servers with the some restrictions, i.e. installation of static keys as shared secret, in intra-domain ? Regards, -- Jean-Mickael GUERIN Tel : +33 1 39 30 92 33 Web site : www.6wind.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 9 10:53:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04700; Mon, 9 Sep 2002 10:53:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89ErPv04857; Mon, 9 Sep 2002 10:53:32 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89EQjv02225 for ; Mon, 9 Sep 2002 10:26:45 -0400 Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25824 for ; Mon, 9 Sep 2002 02:57:37 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id XAA21926; Sun, 8 Sep 2002 23:59:09 -0700 (MST)] Received: [from il06exr01.mot.com (il06exr01.mot.com [129.188.137.131]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id XAA27574; Sun, 8 Sep 2002 23:59:00 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by il06exr01.mot.com (8.11.6/8.11.6) with ESMTP id g896wtT02244; Mon, 9 Sep 2002 01:58:56 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 39ED12EC86; Mon, 9 Sep 2002 09:00:06 +0200 (CEST) To: Ralph Droms Cc: John Wells, Subject: Re: [dhcwg] Address autoconfiguration and route updates for mobility References: <20020829180950.B8009@io.irean.vt.edu> <20020829112549.A5758@io.irean.vt.edu> <20020829180950.B8009@io.irean.vt.edu> <4.3.2.7.2.20020906110604.02209010@funnel.cisco.com> From: Alexandru Petrescu Date: 09 Sep 2002 00:05:29 +0200 In-Reply-To: <4.3.2.7.2.20020906110604.02209010@funnel.cisco.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 76 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I've mainly looked into DHCP/IPv6, there's the CONFIRM message that has this explicit meaning to the server that the client keeps the address after interface went down/up (presumably because of sleep mode). The same scenario can be designed for IPv4 too. After quickly skimming over RFC2131, I would suppose that the client could use a form of DHCPINFORM to server to let it know that client keeps the same address after client's interface has moved under another Access Router. The overall picture could look like this: a cloud of routers running RIP. One of the routers is the DHCP server and some of the other routers are Access Routers (AR). Each AR is also a DHCP Relay. A mobile host attaches its interface to one AR at a time: interface up, interface down and up again under another AR. Assume the mobile host has already acquired an address from the DHCP server. When the mobile is changing its attachment, all it has to do is to CONFIRM its address to the DHCP server through the AR. When the relay on the AR receives the CONFIRM it normally forwards it to the server and, in addition, broadcasts a RIP Update containing its normal routing table plus an entry corresponding to the address allocated to the host (this is found in the CONFIRM). When the DHCP server generates the DHCPACK for this CONFIRM it also generates a RIP Update containing the route towards the new AR, and removing the route through the old AR. The route towards the Mobile address through the old AR should disappear and the route through new AR should appear, within all the routing cloud. What do you think? Alex Ralph Droms writes: > RFC2131 specifies interface disconnect/reconnect as the trigger for a > DHCP update. Nothing else. > > Initiating changes in routes advertised by RIP is certainly possible, > although I don't know of any DHCP servers that will do it today. > > Are you talking about DHCP/IPv4 or DHCP/IPv6? > > - Ralph > > At 11:11 AM 8/30/2002 +0200, Alexandru Petrescu wrote: > >Hi John, > > > >John Wells writes: > > > Hi Alex, > > > That was precisely the idea I had. It's a good one because it gives > > > optimal routing and sidesteps communicating the home address and care-of > > > address to mobile nodes. > > > >We can discuss about this, but this is only half DHC. It gives > >optimal routing but only within that routing domain. No need of HoA > >and CoA but only if staying in that domain. > > > > > Can any DHCP servers do this now? > > > >I don't know of any DHCP implementation that interacts with routing > >daemons. But enhanching a DHCPv6 implementation to send UDP messages > >to routing daemons, a proof-of-concept like, must not be very > >difficult. > > > >RIP needs some modifications to act well for this. Again, off-topic, > >but links torn down information propagate badly. > > > >Alex > > > >_______________________________________________ > >dhcwg mailing list > >dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 9 14:51:03 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13054; Mon, 9 Sep 2002 14:51:02 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89IpWv24111; Mon, 9 Sep 2002 14:51:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g89IXBv22726 for ; Mon, 9 Sep 2002 14:33:11 -0400 Received: from web13908.mail.yahoo.com (web13908.mail.yahoo.com [216.136.175.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12329 for ; Mon, 9 Sep 2002 14:31:32 -0400 (EDT) Message-ID: <20020909183309.74205.qmail@web13908.mail.yahoo.com> Received: from [207.193.172.226] by web13908.mail.yahoo.com via HTTP; Mon, 09 Sep 2002 11:33:09 PDT Date: Mon, 9 Sep 2002 11:33:09 -0700 (PDT) From: Ryan Scripps Reply-To: RyanScripps@alumni.utexas.net Subject: Re: [dhcwg] Query on DHCP client with multiple host To: dhcwg@ietf.org In-Reply-To: <024f01c25505$f65617f0$7647bf90@engloan2> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , (This is probably beginning to go outside the scope of this discussion group, but...) The details of a VLAN configuration can differ by vendor. Simply stated, each VLAN will need to have a either a DHCP server of DHCP relay on it. I am most familiar with Cisco stuff and have typically seen a router card added to a switch chassis. This router card has "interfaces" (all in software) for each network and can act as router between VLANs and also as a DHCP relay (Cisco calls it a "helper address"). A DHCP broadcast will not be carried across VLANs in any implementation of VLANs that I have seen. I have heard of some (presumably very complex) implementations where switch ports are shunted to a default VLAN with a DHCP server on it. When the DHCP server assigns an address, the DHCP server kicks off a script file which dynamically reconfigures the client's switch port with the correct VLAN assignment. Good luck, Ryan Scripps --- Bhaskar S <Bhaskar.S@motorola.com> wrote: > Hi Ryan, > > Thanks for the info. > > I would like to seek more clarification on using > DHCP along with VLAN. Here > I mean to say that I have to use DHCP to allocate IP > addresses to each of > the VLAN interfaces, assuming that DHCP server is > connected to one of the > VLAN interfaces. Is this possible? > > It seemed difficult to me because the DHCP > requesting IP address for an > interface would be sent only on that interface? > > Thanks in advance. > > Regards, > Bhaskar S. > > Regardomg > ----- Original Message ----- > From: "Ryan Scripps" > To: "Bhaskar S" > Sent: Thursday, September 05, 2002 8:33 AM > Subject: Re: [dhcwg] Query on DHCP client with > multiple host > > > > My interpretation is that a DISCOVER must be sent > from > > each interface since they could each be on a > different > > network. > > > > VLANs do not alter the functionality of DHCP. You > > must ensure that each VLAN has a DHCP server or > relay > > agent in it somewhere, however. Clients on one > VLAN > > typically must route to another VLAN, therefore > DHCP > > DISCOVERs will not be carried across VLANs. Your > > switches may allow a single port to trunk VLANs to > a > > single host which could have interfaces for all > > available VLANs. > > > > Best of luck, > > Ryan Scripps > > > > --- Bhaskar S wrote: > > > Hi, > > > > > > The DHCP RFC says: > > > > > > "A client with multiple network interfaces must > use > > > DHCP through each > > > interface independently to obtain configuration > > > information parameters for > > > these seperate interfaces." > > > > > > Does the above statement mean that DISCOVER > message > > > for getting IP > > > address for a particular interface should be > sent > > > only on that interface or > > > does it mean that the DISCOVER message has to be > > > sent on each of > > > the interfaces available on the node ? > > > > > > Also I would like links which would give how to > > > configure DHCP in a VLAN > > > environment. > > > > > > Thanks in advance. > > > > > > Regards, > > > Bhaskar S. > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Finance - Get real-time stock quotes > > http://finance.yahoo.com > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg __________________________________________________ Do You Yahoo!? Yahoo! Finance - Get real-time stock quotes http://finance.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 9 20:33:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20524; Mon, 9 Sep 2002 20:33:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A0Xcv10714; Mon, 9 Sep 2002 20:33:38 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A0Sav10485 for ; Mon, 9 Sep 2002 20:28:36 -0400 Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA20288 for ; Mon, 9 Sep 2002 20:26:54 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g8A0MSv11007; Mon, 9 Sep 2002 19:22:28 -0500 (CDT) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g8A0SPUa000436; Mon, 9 Sep 2002 20:28:25 -0400 (EDT) Date: Mon, 9 Sep 2002 20:28:24 -0400 Subject: Re: [dhcwg] IPsec for DHCPv6 client ? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: dhcwg@ietf.org To: Jean-Mickael Guerin From: Ted Lemon In-Reply-To: <3D7C9A23.2080701@6wind.com> Message-Id: <37E52D8A-C454-11D6-8C0A-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Why is not proposed using IPsec to secure communications between > clients and servers with the some restrictions, i.e. installation of > static keys as shared secret, in intra-domain ? Because in general we don't expect that such a security association would exist. In general, you are plugging a device into the network, and you want it to work - you don't want to have to configure it before you plug it in. If you wanted that, you wouldn't be using DHCP, right? The only plausible exception I can come up with is a cell phone, where perhaps the provider would install an IPsec key in the phone. But even then, I'm skeptical that it could be made to work the way you describe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 10 03:39:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06599; Tue, 10 Sep 2002 03:39:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A7eVv07479; Tue, 10 Sep 2002 03:40:31 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A7dmv07428 for ; Tue, 10 Sep 2002 03:39:48 -0400 Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA06579 for ; Tue, 10 Sep 2002 03:38:01 -0400 (EDT) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 40B523E2 for ; Tue, 10 Sep 2002 09:44:24 +0200 (CEST) Received: from 6wind.com (unknown [10.16.0.134]) by intranet.6wind.com (Postfix) with ESMTP id 47B85B4FA for ; Tue, 10 Sep 2002 09:37:33 +0200 (CEST) Message-ID: <3D7DA193.8030906@6wind.com> Date: Tue, 10 Sep 2002 09:38:59 +0200 From: Jean-Mickael Guerin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: fr-fr MIME-Version: 1.0 To: dhcwg@ietf.org Subject: Re: [dhcwg] IPsec for DHCPv6 client ? References: <37E52D8A-C454-11D6-8C0A-00039367340A@nominum.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ted Lemon wrote: >> Why is not proposed using IPsec to secure communications between >> clients and servers with the some restrictions, i.e. installation of >> static keys as shared secret, in intra-domain ? > > > Because in general we don't expect that such a security association > would exist. In general, you are plugging a device into the network, > and you want it to work - you don't want to have to configure it > before you plug it in. If you wanted that, you wouldn't be using > DHCP, right? The only plausible exception I can come up with is a > cell phone, where perhaps the provider would install an IPsec key in > the phone. But even then, I'm skeptical that it could be made to > work the way you describe. > My point concerns the possibility of using IPsec in scenario where DHCP Authentication is proposed. Because DHCP Authentication relies on shared secret, I think the draft should have a section about this, even if it would be limited to client and relays or client and server on same link. Jean-Mickael _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 10 04:22:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07161; Tue, 10 Sep 2002 04:22:24 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A8N6v09559; Tue, 10 Sep 2002 04:23:06 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8A8LCv09486 for ; Tue, 10 Sep 2002 04:21:12 -0400 Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07135 for ; Tue, 10 Sep 2002 04:19:26 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id g8A8Evv13061; Tue, 10 Sep 2002 03:14:57 -0500 (CDT) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.12.2/8.6.11) with ESMTP id g8A8KwUa000788; Tue, 10 Sep 2002 03:20:58 -0500 (CDT) Date: Tue, 10 Sep 2002 04:20:57 -0400 Subject: Re: [dhcwg] IPsec for DHCPv6 client ? Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: dhcwg@ietf.org To: Jean-Mickael Guerin From: Ted Lemon In-Reply-To: <3D7DA193.8030906@6wind.com> Message-Id: <3B493994-C496-11D6-8C0A-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > My point concerns the possibility of using IPsec in scenario where > DHCP Authentication is proposed. Because DHCP Authentication relies on > shared secret, I think the draft should have a section about this, > even if it would be limited to client and relays or client and server > on same link. Your reasoning is flawed. IPsec is not shared-secret authentication. It is an entire security infrastructure, carefully designed to solve a certain class of problems. It happens to support the use of shared-secret authentication, among other authentication schemes. The DHCP security option also supports shared-secret authentication. This is nothing more than a coincidence - it does not mean that DHCP security can work with IPsec. The DHCP server and clients need to see packets with "bad" authentication keys in order for DHCP authentication to work, because they can't really prepare in advance for all the possible uses of keys by roaming clients and servers in locations to which they may roam. If the packet is signed with the wrong key with IPsec, it will simply be dropped by the DHCP agent's IP stack. This is not what we want. Intuitively it seems obvious that one should use IPsec for DHCP authentication. Personally, I'd *love* to be able to claim that IPsec was a solution to securing DHCP transactions. But this working group has a long history of trying to solve this problem with IPsec. Every time we've tried to figure out a good way to do it, we've come up either with nothing, or with an unworkable kludge. So there's a good reason why we didn't do it - it's not an oversight. If you think that there is a way to make IPsec work with DHCP authentication, please take the extra time to actually sit down and reason it through before insisting that we make changes. What happens when a server sees a new client for the first time? What happens when a client that's got a security association with a server at one site roams to a different site? Does the server at the other site even see packets from that client? How does it get them? How does all this work with relay agents? Like it or not, DHCP *requires* relay agents, so the protocol has to work when the DHCP client is talking to a relay agent rather than a server. If you put the signature in the payload, all these problems go away. That's why we've put the signature in the payload. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 10 18:02:34 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27678; Tue, 10 Sep 2002 18:02:34 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8AM39v26660; Tue, 10 Sep 2002 18:03:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8AM18v26607 for ; Tue, 10 Sep 2002 18:01:08 -0400 Received: from fep02-svc.swip.net (fep02.swip.net [130.244.199.130]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA27602 for ; Tue, 10 Sep 2002 17:59:20 -0400 (EDT) Received: from there ([193.12.201.10]) by fep02-svc.swip.net with SMTP id <20020910220031.GDGN16163.fep02-svc.swip.net@there> for ; Wed, 11 Sep 2002 00:00:31 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Date: Wed, 11 Sep 2002 00:00:58 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Message-Id: <20020910220031.GDGN16163.fep02-svc.swip.net@there> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8AM18v26608 Subject: [dhcwg] Windows 2k and user class id Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Can anyone tell me under what circumstance a Windows 2k machine would give up its pre-configured user class identifier? These machines have been running fine with their configured ucid, and now none of them are identifying themselves with this setting. I was under the impression that setting a user class identifier in this client was a permanent change, but it's not looking like it is. Regards, Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 10 18:26:26 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28151; Tue, 10 Sep 2002 18:26:26 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8AMR7v27896; Tue, 10 Sep 2002 18:27:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8AMQxv27872 for ; Tue, 10 Sep 2002 18:26:59 -0400 Received: from mail.wm.edu (mail1.wm.edu [128.239.10.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28140 for ; Tue, 10 Sep 2002 18:25:13 -0400 (EDT) Received: from ares (wm19-210.resnet.wm.edu [128.239.210.19]) by mail.wm.edu (8.12.5/8.12.1) with ESMTP id g8AMQnEt022913 for ; Tue, 10 Sep 2002 18:26:52 -0400 (EDT) From: "Luke Stratman" To: Date: Tue, 10 Sep 2002 18:26:49 -0400 Message-ID: <000101c25919$27bf0600$0101a8c0@campus.wm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2616 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Classless static route? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I apologize in advance for the ignorance of my request, but here goes: I recently submitted a question to the dhcp-server mailing list on ISC involving the need to send clients subnet routes through DHCP. I ran across the draft for the classless static route option for the DHCP server that would do exactly what I need. I realize that it is, in fact, only a draft but was wondering if it had worked its way into the ISC's dev builds for DHCP. Again, I apologize for the ignorance of my request, but if anyone could confirm or deny this, I would greatly appreciate it. Thanks in advance for your time, -Luke Stratman _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 00:14:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04398; Wed, 11 Sep 2002 00:14:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8B4DRv10657; Wed, 11 Sep 2002 00:13:27 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8B4CZv10622 for ; Wed, 11 Sep 2002 00:12:35 -0400 Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04382 for ; Wed, 11 Sep 2002 00:10:45 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 5F45765B4; Wed, 11 Sep 2002 00:12:26 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 11 Sep 2002 00:12:26 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] IPsec for DHCPv6 client ? Date: Wed, 11 Sep 2002 00:12:25 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE91AE@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] IPsec for DHCPv6 client ? Thread-Index: AcJYpKAF53UIPaDxQrumD+/v84XIFwApLyMQ From: "Bound, Jim" To: "Ted Lemon" , "Jean-Mickael Guerin" Cc: X-OriginalArrivalTime: 11 Sep 2002 04:12:26.0043 (UTC) FILETIME=[6FA600B0:01C25949] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8B4Cav10623 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit To add to this dhcpv6 is multicast based. That don't work to well with IPsec. We still have not figured that out. /jim > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Tuesday, September 10, 2002 4:21 AM > To: Jean-Mickael Guerin > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] IPsec for DHCPv6 client ? > > > > My point concerns the possibility of using IPsec in scenario where > > DHCP Authentication is proposed. Because DHCP > Authentication relies on > > shared secret, I think the draft should have a section about this, > > even if it would be limited to client and relays or client > and server > > on same link. > > Your reasoning is flawed. IPsec is not shared-secret > authentication. > It is an entire security infrastructure, carefully designed > to solve a > certain class of problems. It happens to support the use of > shared-secret authentication, among other authentication > schemes. The > DHCP security option also supports shared-secret > authentication. This > is nothing more than a coincidence - it does not mean that DHCP > security can work with IPsec. > > The DHCP server and clients need to see packets with "bad" > authentication keys in order for DHCP authentication to work, because > they can't really prepare in advance for all the possible > uses of keys > by roaming clients and servers in locations to which they may roam. > If the packet is signed with the wrong key with IPsec, it will simply > be dropped by the DHCP agent's IP stack. This is not what we want. > > Intuitively it seems obvious that one should use IPsec for DHCP > authentication. Personally, I'd *love* to be able to claim > that IPsec > was a solution to securing DHCP transactions. But this > working group > has a long history of trying to solve this problem with > IPsec. Every > time we've tried to figure out a good way to do it, we've come up > either with nothing, or with an unworkable kludge. So > there's a good > reason why we didn't do it - it's not an oversight. > > If you think that there is a way to make IPsec work with DHCP > authentication, please take the extra time to actually sit down and > reason it through before insisting that we make changes. > What happens > when a server sees a new client for the first time? What > happens when > a client that's got a security association with a server at one site > roams to a different site? Does the server at the other > site even see > packets from that client? How does it get them? How does all this > work with relay agents? Like it or not, DHCP *requires* > relay agents, > so the protocol has to work when the DHCP client is talking > to a relay > agent rather than a server. If you put the signature in the > payload, > all these problems go away. That's why we've put the > signature in the > payload. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 02:58:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29931; Wed, 11 Sep 2002 02:58:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8B6vev26416; Wed, 11 Sep 2002 02:57:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8B6uXv26370 for ; Wed, 11 Sep 2002 02:56:34 -0400 Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29857 for ; Wed, 11 Sep 2002 02:54:42 -0400 (EDT) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 11 Sep 2002 08:56:22 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 11 Sep 2002 08:56:22 +0200 Message-ID: Thread-Topic: Items of the new wg charter Thread-Index: AcJZYFZlpNw2QRTDQ3in8INYCct+YA== From: "BINET David FTRD/DMI/CAE" To: X-OriginalArrivalTime: 11 Sep 2002 06:56:23.0085 (UTC) FILETIME=[56FB7DD0:01C25960] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8B6uYv26371 Subject: [dhcwg] Items of the new wg charter Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, There were some internet drafts dealing with the deployment of DHCP protocol in new envrironments, such as roaming/mobile clients and xdsl access. These drafts were, as far as I know, draft-ietf-dhc-aaa-ra-00.txt, draft-ietf-dhc-enhance-requirements-00.txt, draft-ietf-dhc-aaa-requirements-00.txt. All these drafts have expired and it seems that there is no such working item in the next charter of the working group, discussed during the last meeting in Yokohama. Does it mean that the working group considers that it is not an important item even if some ISPs consider DHCP protocol (+ improvements) as an alternative or a complement to PPP for their services ? Or does this work is handled by another working group ? David Binet _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 11:30:51 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13089; Wed, 11 Sep 2002 11:30:51 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BFTev22898; Wed, 11 Sep 2002 11:29:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BFSkv22839 for ; Wed, 11 Sep 2002 11:28:46 -0400 Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12961 for ; Wed, 11 Sep 2002 11:27:01 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id C137A460D; Wed, 11 Sep 2002 11:28:42 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 11 Sep 2002 11:28:42 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] Items of the new wg charter Date: Wed, 11 Sep 2002 11:28:41 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B02BE91C8@tayexc13.americas.cpqcorp.net> Thread-Topic: Items of the new wg charter Thread-Index: AcJZYFZlpNw2QRTDQ3in8INYCct+YAARycgg From: "Bound, Jim" To: "BINET David FTRD/DMI/CAE" , X-OriginalArrivalTime: 11 Sep 2002 15:28:42.0257 (UTC) FILETIME=[E8F4E810:01C259A7] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8BFSkv22840 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit My view is we MUST deal with Mobility in all IETF working groups. For those that write code and build this stuff you know from the initial mobile code we have had to put in for mobile v4/v6, tcp wireless (pilc wg), et al that mobile greatly affects our IP stack, APIs, and ISV applications paradigms. It is now inherent in the infrastructure. Of course it has to be in our vision with the dhc working group. Unfortuneately I as one person appear to be unable to communciate with ADs in the IETF so I suggest others they may respect more go beat on them and work with Ralph to get this included. It is complete error in dhc to not have this in our charter. /jim > -----Original Message----- > From: BINET David FTRD/DMI/CAE > [mailto:david.binet@rd.francetelecom.com] > Sent: Wednesday, September 11, 2002 2:56 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Items of the new wg charter > > > Hi, > > There were some internet drafts dealing with the deployment > of DHCP protocol in new envrironments, such as roaming/mobile > clients and xdsl access. These drafts were, as far as I know, > draft-ietf-dhc-aaa-ra-00.txt, > draft-ietf-dhc-enhance-requirements-00.txt, > draft-ietf-dhc-aaa-requirements-00.txt. All these drafts have > expired and it seems that there is no such working item in > the next charter of the working group, discussed during the > last meeting in Yokohama. > > Does it mean that the working group considers that it is not > an important item even if some ISPs consider DHCP protocol (+ > improvements) as an alternative or a complement to PPP for > their services ? Or does this work is handled by another > working group ? > > David Binet > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 12:08:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14354; Wed, 11 Sep 2002 12:08:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BG77v25211; Wed, 11 Sep 2002 12:07:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BG3rv24772 for ; Wed, 11 Sep 2002 12:03:53 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14240 for ; Wed, 11 Sep 2002 12:02:07 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8BG3JKB007950; Wed, 11 Sep 2002 09:03:19 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8BG3HKZ014421; Wed, 11 Sep 2002 09:03:17 -0700 (PDT) Received: from cisco.com (mbakke@mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id JAA04617; Wed, 11 Sep 2002 09:03:16 -0700 (PDT) Message-ID: <3D7F6DD3.FEC5449F@cisco.com> Date: Wed, 11 Sep 2002 11:22:43 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: dhcwg@ietf.org, mibs@ops.ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP Option for SNMP Notifications Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi- I needed a method to configure a list of SNMP notification (AKA trap) hosts for use by diskless workstations booting from a network device. Since none of the usual SNMP configuration information is available at this time, I would like to use a DHCP option to provide a list of IP addresses to which to send notifications when, for instance, booting from a network device fails for some reason. This could also be used to centrally configure the list of SNMP notification hosts, rather than setting them individually on each machine. Anyway, I've submitted a short draft describing the proposed option as draft-bakke-dhc-snmp-trap-00.txt. I'll forward the message to these two groups when the draft is published. In the mean time, it is available at: ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-trap-00.txt I'm guessing that these two mailing lists (dhcwg and mibs) are the correct places to discuss this (please let me know if there's a more appropriate list). Regards, Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 13:31:56 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17862; Wed, 11 Sep 2002 13:31:55 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BHWSv30796; Wed, 11 Sep 2002 13:32:28 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BHV4v30730 for ; Wed, 11 Sep 2002 13:31:04 -0400 Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17751 for ; Wed, 11 Sep 2002 13:29:19 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g8BHUwj19276; Wed, 11 Sep 2002 12:30:59 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g8BHUwA14756; Wed, 11 Sep 2002 12:30:58 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 11 Sep 2002 12:30:58 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "Bound, Jim" , BINET David FTRD/DMI/CAE , dhcwg@ietf.org Subject: RE: [dhcwg] Items of the new wg charter Date: Wed, 11 Sep 2002 12:30:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C259B8.FC5AAA50" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C259B8.FC5AAA50 Content-Type: text/plain; charset="iso-8859-1" Some of this work likely overlaps the PANA WG and may be more appropriate in there? DHCP is the Dynamic Host Configuration Protocol and has focused on configuration of clients - not authorizing users. (We've viewed the user authorization as happening AFTER the address was assigned.) In light of todays world in which most clients are really associated with a single user, it is likely time for the WG to revisit this? But, this would require discussions within the WG, with the ADs, and with other WGs responsible for authentication issues (AAA, PANA, ...)? We must also remember there are systems that aren't associated with specific users - and they need addresses and configuration information as well. And, this would fundamentally impact when addresses are assigned and released, since a user logout could require an address release. - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Wednesday, September 11, 2002 11:29 AM To: BINET David FTRD/DMI/CAE; dhcwg@ietf.org Subject: RE: [dhcwg] Items of the new wg charter My view is we MUST deal with Mobility in all IETF working groups. For those that write code and build this stuff you know from the initial mobile code we have had to put in for mobile v4/v6, tcp wireless (pilc wg), et al that mobile greatly affects our IP stack, APIs, and ISV applications paradigms. It is now inherent in the infrastructure. Of course it has to be in our vision with the dhc working group. Unfortuneately I as one person appear to be unable to communciate with ADs in the IETF so I suggest others they may respect more go beat on them and work with Ralph to get this included. It is complete error in dhc to not have this in our charter. /jim > -----Original Message----- > From: BINET David FTRD/DMI/CAE > [mailto:david.binet@rd.francetelecom.com] > Sent: Wednesday, September 11, 2002 2:56 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Items of the new wg charter > > > Hi, > > There were some internet drafts dealing with the deployment > of DHCP protocol in new envrironments, such as roaming/mobile > clients and xdsl access. These drafts were, as far as I know, > draft-ietf-dhc-aaa-ra-00.txt, > draft-ietf-dhc-enhance-requirements-00.txt, > draft-ietf-dhc-aaa-requirements-00.txt. All these drafts have > expired and it seems that there is no such working item in > the next charter of the working group, discussed during the > last meeting in Yokohama. > > Does it mean that the working group considers that it is not > an important item even if some ISPs consider DHCP protocol (+ > improvements) as an alternative or a complement to PPP for > their services ? Or does this work is handled by another > working group ? > > David Binet > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C259B8.FC5AAA50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Items of the new wg charter

Some of this work likely overlaps the PANA WG and may = be more appropriate in there?

DHCP is the Dynamic Host Configuration Protocol and = has focused on configuration of clients - not authorizing users. (We've = viewed the user authorization as happening AFTER the address was = assigned.)

In light of todays world in which most clients are = really associated with a single user, it is likely time for the WG to = revisit this? But, this would require discussions within the WG, with = the ADs, and with other WGs responsible for authentication issues (AAA, = PANA, ...)?

We must also remember there are systems that aren't = associated with specific users - and they need addresses and = configuration information as well. And, this would fundamentally impact = when addresses are assigned and released, since a user logout could = require an address release.

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Wednesday, September 11, 2002 11:29 AM
To: BINET David FTRD/DMI/CAE; dhcwg@ietf.org
Subject: RE: [dhcwg] Items of the new wg = charter


My view is we MUST deal with Mobility in all IETF = working groups.  For those that write code and build this stuff = you know from the initial mobile code we have had to put in for mobile = v4/v6, tcp wireless (pilc wg), et al that mobile greatly affects our IP = stack, APIs, and ISV applications paradigms.  It is now inherent = in the infrastructure. Of course it has to be in our vision with the = dhc working group.  Unfortuneately I  as one person appear to = be unable to communciate with ADs in the IETF so I suggest others they = may respect more go beat on them and work with Ralph to get this = included.  It is complete error in dhc to not have this in our = charter.

/jim

> -----Original Message-----
> From: BINET David FTRD/DMI/CAE
> [mailto:david.binet@rd.f= rancetelecom.com]
> Sent: Wednesday, September 11, 2002 2:56 = AM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Items of the new wg = charter
>
>
> Hi,
>
> There were some internet drafts dealing with = the deployment
> of DHCP protocol in new envrironments, such as = roaming/mobile
> clients and xdsl access. These drafts were, as = far as I know,
> draft-ietf-dhc-aaa-ra-00.txt,
> draft-ietf-dhc-enhance-requirements-00.txt, =
> draft-ietf-dhc-aaa-requirements-00.txt. All = these drafts have
> expired and it seems that there is no such = working item in
> the next charter of the working group, = discussed during the
> last meeting in Yokohama.
>
> Does it mean that the working group considers = that it is not
> an important item even if some ISPs consider = DHCP protocol (+
> improvements) as an alternative or a complement = to PPP for
> their services ? Or does this work is handled = by another
> working group ?
>
> David Binet
> 
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C259B8.FC5AAA50-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 16:31:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23738; Wed, 11 Sep 2002 16:31:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BKWKv08466; Wed, 11 Sep 2002 16:32:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BKVKv08390 for ; Wed, 11 Sep 2002 16:31:20 -0400 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23664 for ; Wed, 11 Sep 2002 16:29:33 -0400 (EDT) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g8BKUYlg015922; Wed, 11 Sep 2002 16:30:34 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g8BKUVxR011560; Wed, 11 Sep 2002 16:30:31 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g8BKQIM30743; Wed, 11 Sep 2002 16:26:18 -0400 Message-Id: <200209112026.g8BKQIM30743@rotala.raleigh.ibm.com> To: "Bernie Volz (EUD)" cc: "Bound, Jim" , BINET David FTRD/DMI/CAE , dhcwg@ietf.org Subject: Re: [dhcwg] Items of the new wg charter In-Reply-To: Message from "Wed, 11 Sep 2002 12:30:56 CDT." Date: Wed, 11 Sep 2002 16:26:18 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I agree with Bernie. Some serious thinking needs to take place before deciding if the cited IDs belong in this WG. There are other WGs that might be more appropriate. But as we are in the process of rechartering the WG, now is a good time to bring the topic up. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 17:21:24 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25132; Wed, 11 Sep 2002 17:21:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLM9v11457; Wed, 11 Sep 2002 17:22:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLLev11429 for ; Wed, 11 Sep 2002 17:21:40 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25096 for ; Wed, 11 Sep 2002 17:19:52 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8BLL3KB027500; Wed, 11 Sep 2002 14:21:03 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8BLL2kl029853; Wed, 11 Sep 2002 14:21:03 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA04555; Wed, 11 Sep 2002 14:21:00 -0700 (PDT) Message-ID: <3D7FB84C.849C7C64@cisco.com> Date: Wed, 11 Sep 2002 16:40:28 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "David T. Perkins" CC: dhcwg@ietf.org, mibs@ops.ietf.org References: <5.1.1.6.2.20020911134627.035dd7b0@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: DHCP Option for SNMP Notifications Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi David- My assumption was that in this case, we could get away with using "public" for the community string, and that any defined traps would be enabled (we would only send these when something failed, so we shouldn't have to allow the user to configure which ones to send). That would take care of early boot, unless configuring the community string was important. Perhaps this would be enough. Are there other things that might be important to set for an initial boot implementation that only sends traps? Thanks, Mark "David T. Perkins" wrote: > > HI, > > Mark, > > Having only an IP address of a management target is insufficient for > achieving your objective. What you need to add depends on how many > "stages" that you have for your boot operation, and what you assume > can be configured in persistent storage for the device. > > At 11:22 AM 9/11/2002 -0500, Mark Bakke wrote: > >Hi- > > > >I needed a method to configure a list of SNMP notification (AKA trap) > >hosts for use by diskless workstations booting from a network device. > >Since none of the usual SNMP configuration information is available > >at this time, I would like to use a DHCP option to provide a list of > >IP addresses to which to send notifications when, for instance, booting > >from a network device fails for some reason. This could also be used > >to centrally configure the list of SNMP notification hosts, rather than > >setting them individually on each machine. > > > >Anyway, I've submitted a short draft describing the proposed option > >as draft-bakke-dhc-snmp-trap-00.txt. I'll forward the message to > >these two groups when the draft is published. In the mean time, it > >is available at: > > > >ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-trap-00.txt > > > >I'm guessing that these two mailing lists (dhcwg and mibs) are the > >correct places to discuss this (please let me know if there's a more > >appropriate list). > > > >Regards, > > > >Mark A. Bakke > >Cisco Systems > >mbakke@cisco.com > >763.398.1054 > Regards, > /david t. perkins -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 17:28:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25342; Wed, 11 Sep 2002 17:28:21 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLT7v11778; Wed, 11 Sep 2002 17:29:07 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLT0v11737 for ; Wed, 11 Sep 2002 17:29:00 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25292 for ; Wed, 11 Sep 2002 17:27:12 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8BLSMW4028450; Wed, 11 Sep 2002 14:28:22 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8BLSMJ7004699; Wed, 11 Sep 2002 14:28:22 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA11263; Wed, 11 Sep 2002 14:28:20 -0700 (PDT) Message-ID: <3D7FBA04.CCE73422@cisco.com> Date: Wed, 11 Sep 2002 16:47:48 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "David T. Perkins" , dhcwg@ietf.org, mibs@ops.ietf.org Subject: Re: [dhcwg] Re: DHCP Option for SNMP Notifications References: <5.1.1.6.2.20020911134627.035dd7b0@127.0.0.1> <3D7FB84C.849C7C64@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit On second thought, we would probably also want to configure whether each host was to be sent a V1 or V2 trap. -- Mark Mark Bakke wrote: > > Hi David- > > My assumption was that in this case, we could get away with using > "public" for the community string, and that any defined traps would > be enabled (we would only send these when something failed, so > we shouldn't have to allow the user to configure which ones to > send). That would take care of early boot, unless configuring the > community string was important. Perhaps this would be enough. > > Are there other things that might be important to set for an initial > boot implementation that only sends traps? > > Thanks, > > Mark > > "David T. Perkins" wrote: > > > > HI, > > > > Mark, > > > > Having only an IP address of a management target is insufficient for > > achieving your objective. What you need to add depends on how many > > "stages" that you have for your boot operation, and what you assume > > can be configured in persistent storage for the device. > > > > At 11:22 AM 9/11/2002 -0500, Mark Bakke wrote: > > >Hi- > > > > > >I needed a method to configure a list of SNMP notification (AKA trap) > > >hosts for use by diskless workstations booting from a network device. > > >Since none of the usual SNMP configuration information is available > > >at this time, I would like to use a DHCP option to provide a list of > > >IP addresses to which to send notifications when, for instance, booting > > >from a network device fails for some reason. This could also be used > > >to centrally configure the list of SNMP notification hosts, rather than > > >setting them individually on each machine. > > > > > >Anyway, I've submitted a short draft describing the proposed option > > >as draft-bakke-dhc-snmp-trap-00.txt. I'll forward the message to > > >these two groups when the draft is published. In the mean time, it > > >is available at: > > > > > >ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-trap-00.txt > > > > > >I'm guessing that these two mailing lists (dhcwg and mibs) are the > > >correct places to discuss this (please let me know if there's a more > > >appropriate list). > > > > > >Regards, > > > > > >Mark A. Bakke > > >Cisco Systems > > >mbakke@cisco.com > > >763.398.1054 > > Regards, > > /david t. perkins > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 17:31:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25439; Wed, 11 Sep 2002 17:31:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLW4v11928; Wed, 11 Sep 2002 17:32:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8AEChv26466 for ; Tue, 10 Sep 2002 10:12:43 -0400 Received: from parsmtp1.rd.francetelecom.com (parsmtp1.rd.francetelecom.com [194.167.105.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14943 for ; Tue, 10 Sep 2002 10:11:00 -0400 (EDT) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp1.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 10 Sep 2002 16:12:39 +0200 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Tue, 10 Sep 2002 16:12:38 +0200 Message-ID: Thread-Topic: Items of the new wg charter Thread-Index: AcJY1B5y2cmFStz0TY2ctJlR716xmA== From: "BINET David FTRD/DMI/CAE" To: X-OriginalArrivalTime: 10 Sep 2002 14:12:39.0773 (UTC) FILETIME=[1F1758D0:01C258D4] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8AEChv26467 Subject: [dhcwg] Items of the new wg charter Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, There were some internet drafts dealing with the deployment of DHCP protocol in new envrironments, such as roaming/mobile clients and xdsl access. These drafts were, as far as I know, draft-ietf-dhc-aaa-ra-00.txt, draft-ietf-dhc-enhance-requirements-00.txt, draft-ietf-dhc-aaa-requirements-00.txt. All these drafts have expired and it seems that there is no such working item in the next charter of the working group, discussed during the last meeting in Yokohama. Does it mean that the working group considers that it is not an important item even if some ISPs consider DHCP protocol (+ improvements) as an alternative or a complement to PPP for their services ? Or does this work is handled by another working group ? David Binet _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 17:31:18 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25463; Wed, 11 Sep 2002 17:31:18 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLW5v11944; Wed, 11 Sep 2002 17:32:05 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BKpkv09545 for ; Wed, 11 Sep 2002 16:51:46 -0400 Received: from postman.bayarea.net (postman.BAYAREA.NET [205.219.84.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24322 for ; Wed, 11 Sep 2002 16:49:58 -0400 (EDT) Received: from host.dsperkins.com (shell4.BAYAREA.NET [209.128.82.1]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id NAA34281; Wed, 11 Sep 2002 13:51:25 -0700 (PDT) (envelope-from dperkins@dsperkins.com) Message-Id: <5.1.1.6.2.20020911134627.035dd7b0@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 11 Sep 2002 13:50:04 -0700 To: Mark Bakke , dhcwg@ietf.org, mibs@ops.ietf.org From: "David T. Perkins" In-Reply-To: <3D7F6DD3.FEC5449F@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: DHCP Option for SNMP Notifications Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , HI, Mark, Having only an IP address of a management target is insufficient for achieving your objective. What you need to add depends on how many "stages" that you have for your boot operation, and what you assume can be configured in persistent storage for the device. At 11:22 AM 9/11/2002 -0500, Mark Bakke wrote: >Hi- > >I needed a method to configure a list of SNMP notification (AKA trap) >hosts for use by diskless workstations booting from a network device. >Since none of the usual SNMP configuration information is available >at this time, I would like to use a DHCP option to provide a list of >IP addresses to which to send notifications when, for instance, booting >from a network device fails for some reason. This could also be used >to centrally configure the list of SNMP notification hosts, rather than >setting them individually on each machine. > >Anyway, I've submitted a short draft describing the proposed option >as draft-bakke-dhc-snmp-trap-00.txt. I'll forward the message to >these two groups when the draft is published. In the mean time, it >is available at: > >ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-trap-00.txt > >I'm guessing that these two mailing lists (dhcwg and mibs) are the >correct places to discuss this (please let me know if there's a more >appropriate list). > >Regards, > >Mark A. Bakke >Cisco Systems >mbakke@cisco.com >763.398.1054 Regards, /david t. perkins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 17:34:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25623; Wed, 11 Sep 2002 17:34:28 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLZEv12050; Wed, 11 Sep 2002 17:35:14 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLRwv11694 for ; Wed, 11 Sep 2002 17:27:58 -0400 Received: from hoemail2.firewall.lucent.com ([192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25252 for ; Wed, 11 Sep 2002 17:26:10 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8BLRJI06352 for ; Wed, 11 Sep 2002 17:27:20 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Wed, 11 Sep 2002 23:27:19 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Mark Bakke , dhcwg@ietf.org, mibs@ops.ietf.org Date: Wed, 11 Sep 2002 23:27:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] RE: DHCP Option for SNMP Notifications Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Seems pretty IPv4 specific. Can there be IPv6 addresses? How ould the agent know security parameters and SNMP version to use and such? I assume you would want the paramters to fit into the SNMP architecure (as per RFC2571), and the trap (or better) notification destinations (and other parameters) to be mappable inot the MIBs in RFC2573, 2574 and 2575? Thanks, Bert > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: woensdag 11 september 2002 18:23 > To: dhcwg@ietf.org; mibs@ops.ietf.org > Subject: DHCP Option for SNMP Notifications > > > Hi- > > I needed a method to configure a list of SNMP notification (AKA trap) > hosts for use by diskless workstations booting from a network device. > Since none of the usual SNMP configuration information is available > at this time, I would like to use a DHCP option to provide a list of > IP addresses to which to send notifications when, for > instance, booting > from a network device fails for some reason. This could also be used > to centrally configure the list of SNMP notification hosts, > rather than > setting them individually on each machine. > > Anyway, I've submitted a short draft describing the proposed option > as draft-bakke-dhc-snmp-trap-00.txt. I'll forward the message to > these two groups when the draft is published. In the mean time, it > is available at: > > ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-tr ap-00.txt I'm guessing that these two mailing lists (dhcwg and mibs) are the correct places to discuss this (please let me know if there's a more appropriate list). Regards, Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 17:34:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25648; Wed, 11 Sep 2002 17:34:31 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLZMv12071; Wed, 11 Sep 2002 17:35:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLT5v11753 for ; Wed, 11 Sep 2002 17:29:05 -0400 Received: from postman.bayarea.net (postman.BAYAREA.NET [205.219.84.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25295 for ; Wed, 11 Sep 2002 17:27:16 -0400 (EDT) Received: from host.dsperkins.com (shell4.BAYAREA.NET [209.128.82.1]) by postman.bayarea.net (8.9.3/8.9.3) with ESMTP id OAA48352; Wed, 11 Sep 2002 14:28:52 -0700 (PDT) (envelope-from dperkins@dsperkins.com) Message-Id: <5.1.1.6.2.20020911142157.035df060@127.0.0.1> X-Sender: dperkins@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Version 5.1.1 Date: Wed, 11 Sep 2002 14:27:14 -0700 To: Mark Bakke From: "David T. Perkins" Cc: dhcwg@ietf.org, mibs@ops.ietf.org In-Reply-To: <3D7FB84C.849C7C64@cisco.com> References: <5.1.1.6.2.20020911134627.035dd7b0@127.0.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: DHCP Option for SNMP Notifications Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , HI, So, you are developing a mechanism that works only for SNMPv1 with no proxy or security. Note that SNMPv1 is a "not recommended" protocol. It would be much more valuable to create an approach that worked for SNMPv1, SNMPv2, and SNMPv3 protocols, that supported security parameters from the DHCP server and from local persistent storage, and that allowed a multi-stage boot. There are security trade-offs that need to be covered. At 04:40 PM 9/11/2002 -0500, Mark Bakke wrote: >Hi David- > >My assumption was that in this case, we could get away with using >"public" for the community string, and that any defined traps would >be enabled (we would only send these when something failed, so >we shouldn't have to allow the user to configure which ones to >send). That would take care of early boot, unless configuring the >community string was important. Perhaps this would be enough. > >Are there other things that might be important to set for an initial >boot implementation that only sends traps? > >Thanks, > >Mark > >"David T. Perkins" wrote: >> >> HI, >> >> Mark, >> >> Having only an IP address of a management target is insufficient for >> achieving your objective. What you need to add depends on how many >> "stages" that you have for your boot operation, and what you assume >> can be configured in persistent storage for the device. >> >> At 11:22 AM 9/11/2002 -0500, Mark Bakke wrote: >> >Hi- >> > >> >I needed a method to configure a list of SNMP notification (AKA trap) >> >hosts for use by diskless workstations booting from a network device. >> >Since none of the usual SNMP configuration information is available >> >at this time, I would like to use a DHCP option to provide a list of >> >IP addresses to which to send notifications when, for instance, booting >> >from a network device fails for some reason. This could also be used >> >to centrally configure the list of SNMP notification hosts, rather than >> >setting them individually on each machine. >> > >> >Anyway, I've submitted a short draft describing the proposed option >> >as draft-bakke-dhc-snmp-trap-00.txt. I'll forward the message to >> >these two groups when the draft is published. In the mean time, it >> >is available at: >> > >> >ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-trap-00.txt >> > >> >I'm guessing that these two mailing lists (dhcwg and mibs) are the >> >correct places to discuss this (please let me know if there's a more >> >appropriate list). >> > >> >Regards, >> > >> >Mark A. Bakke >> >Cisco Systems >> >mbakke@cisco.com >> >763.398.1054 >> Regards, >> /david t. perkins > >-- >Mark A. Bakke >Cisco Systems >mbakke@cisco.com >763.398.1054 Regards, /david t. perkins _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 17:43:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26011; Wed, 11 Sep 2002 17:43:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLiAv13195; Wed, 11 Sep 2002 17:44:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLh9v13155 for ; Wed, 11 Sep 2002 17:43:09 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25966 for ; Wed, 11 Sep 2002 17:41:21 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8BLgWW4005312; Wed, 11 Sep 2002 14:42:32 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8BLgUHY009266; Wed, 11 Sep 2002 14:42:30 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA24308; Wed, 11 Sep 2002 14:42:28 -0700 (PDT) Message-ID: <3D7FBD54.C6EC2E2D@cisco.com> Date: Wed, 11 Sep 2002 17:01:56 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "David T. Perkins" CC: dhcwg@ietf.org, mibs@ops.ietf.org References: <5.1.1.6.2.20020911134627.035dd7b0@127.0.0.1> <5.1.1.6.2.20020911142157.035df060@127.0.0.1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: DHCP Option for SNMP Notifications Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit True; that's what I had in mind, although we would definitely need to say which version was needed for each host. I hadn't taken proxies or security into account, since I have not thought beyond version 2. Anyway, we should do this right. I assume that we need to have a set of parameters that are global to the entity being configured, as well as a set of parameters for each trap or notification host. Any pointers to what should be configured for security? Thanks, Mark "David T. Perkins" wrote: > > HI, > > So, you are developing a mechanism that works only for > SNMPv1 with no proxy or security. Note that SNMPv1 is > a "not recommended" protocol. It would be much more > valuable to create an approach that worked for SNMPv1, > SNMPv2, and SNMPv3 protocols, that supported security > parameters from the DHCP server and from local persistent > storage, and that allowed a multi-stage boot. > > There are security trade-offs that need to be covered. > > At 04:40 PM 9/11/2002 -0500, Mark Bakke wrote: > >Hi David- > > > >My assumption was that in this case, we could get away with using > >"public" for the community string, and that any defined traps would > >be enabled (we would only send these when something failed, so > >we shouldn't have to allow the user to configure which ones to > >send). That would take care of early boot, unless configuring the > >community string was important. Perhaps this would be enough. > > > >Are there other things that might be important to set for an initial > >boot implementation that only sends traps? > > > >Thanks, > > > >Mark > > > >"David T. Perkins" wrote: > >> > >> HI, > >> > >> Mark, > >> > >> Having only an IP address of a management target is insufficient for > >> achieving your objective. What you need to add depends on how many > >> "stages" that you have for your boot operation, and what you assume > >> can be configured in persistent storage for the device. > >> > >> At 11:22 AM 9/11/2002 -0500, Mark Bakke wrote: > >> >Hi- > >> > > >> >I needed a method to configure a list of SNMP notification (AKA trap) > >> >hosts for use by diskless workstations booting from a network device. > >> >Since none of the usual SNMP configuration information is available > >> >at this time, I would like to use a DHCP option to provide a list of > >> >IP addresses to which to send notifications when, for instance, booting > >> >from a network device fails for some reason. This could also be used > >> >to centrally configure the list of SNMP notification hosts, rather than > >> >setting them individually on each machine. > >> > > >> >Anyway, I've submitted a short draft describing the proposed option > >> >as draft-bakke-dhc-snmp-trap-00.txt. I'll forward the message to > >> >these two groups when the draft is published. In the mean time, it > >> >is available at: > >> > > >> >ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-trap-00.txt > >> > > >> >I'm guessing that these two mailing lists (dhcwg and mibs) are the > >> >correct places to discuss this (please let me know if there's a more > >> >appropriate list). > >> > > >> >Regards, > >> > > >> >Mark A. Bakke > >> >Cisco Systems > >> >mbakke@cisco.com > >> >763.398.1054 > >> Regards, > >> /david t. perkins > > > >-- > >Mark A. Bakke > >Cisco Systems > >mbakke@cisco.com > >763.398.1054 > Regards, > /david t. perkins -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 11 17:47:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26139; Wed, 11 Sep 2002 17:47:13 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLm4v13397; Wed, 11 Sep 2002 17:48:04 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8BLl9v13352 for ; Wed, 11 Sep 2002 17:47:09 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26088 for ; Wed, 11 Sep 2002 17:45:21 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8BLkS3x022204; Wed, 11 Sep 2002 14:46:28 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8BLkVh6016938; Wed, 11 Sep 2002 14:46:31 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA27818; Wed, 11 Sep 2002 14:46:28 -0700 (PDT) Message-ID: <3D7FBE44.487A0EDB@cisco.com> Date: Wed, 11 Sep 2002 17:05:56 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: dhcwg@ietf.org, mibs@ops.ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: DHCP Option for SNMP Notifications Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I had figured IPv6 addresses would be handled along with DHCPv6, but that's mainly because we worried about v6 a whole lot yet. I also noticed that all of the previously-specified "list of IP address" options only mentioned v4. Is there a standard method used in DHCP to specify whether an address that follows is an IPv4 or v6 address? I hadn't given security any thought. I assume that I need to look at the notification MIB module in RFC2573. Where should I look for these in the others? Anyway, I'll be out for a few days, and will try to read the four RFCs you mentioned in the meantime. I'd prefer to do this the right way, rather than limit it to v1. Thanks, Mark "Wijnen, Bert (Bert)" wrote: > > Seems pretty IPv4 specific. Can there be IPv6 addresses? > > How ould the agent know security parameters and SNMP version > to use and such? > > I assume you would want the paramters to fit into the > SNMP architecure (as per RFC2571), and the trap (or > better) notification destinations (and other parameters) > to be mappable inot the MIBs in RFC2573, 2574 and 2575? > > Thanks, > Bert > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: woensdag 11 september 2002 18:23 > > To: dhcwg@ietf.org; mibs@ops.ietf.org > > Subject: DHCP Option for SNMP Notifications > > > > > > Hi- > > > > I needed a method to configure a list of SNMP notification (AKA trap) > > hosts for use by diskless workstations booting from a network device. > > Since none of the usual SNMP configuration information is available > > at this time, I would like to use a DHCP option to provide a list of > > IP addresses to which to send notifications when, for > > instance, booting > > from a network device fails for some reason. This could also be used > > to centrally configure the list of SNMP notification hosts, > > rather than > > setting them individually on each machine. > > > > Anyway, I've submitted a short draft describing the proposed option > > as draft-bakke-dhc-snmp-trap-00.txt. I'll forward the message to > > these two groups when the draft is published. In the mean time, it > > is available at: > > > > ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-tr > ap-00.txt > > I'm guessing that these two mailing lists (dhcwg and mibs) are the > correct places to discuss this (please let me know if there's a more > appropriate list). > > Regards, > > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 12 04:52:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16791; Thu, 12 Sep 2002 04:52:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8C8ouv23359; Thu, 12 Sep 2002 04:51:00 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8C8n8v23288 for ; Thu, 12 Sep 2002 04:49:08 -0400 Received: from parsmtp2.rd.francetelecom.com (parsmtp2.rd.francetelecom.com [194.167.105.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16711 for ; Thu, 12 Sep 2002 04:47:15 -0400 (EDT) Received: from lanmhs50.rd.francetelecom.fr ([10.193.21.52]) by parsmtp2.rd.francetelecom.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 12 Sep 2002 10:48:55 +0200 Subject: RE: [dhcwg] Items of the new wg charter MIME-Version: 1.0 Date: Thu, 12 Sep 2002 10:48:54 +0200 Content-Type: text/plain; charset="us-ascii" Message-ID: X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message Thread-Topic: [dhcwg] Items of the new wg charter Thread-Index: AcJZ0i3F+DpqHuogQQO98WQTlGWNMQAYpbTA From: "BINET David FTRD/DMI/CAE" To: "Thomas Narten" , "Bernie Volz (EUD)" Cc: "Bound, Jim" , X-OriginalArrivalTime: 12 Sep 2002 08:48:55.0725 (UTC) FILETIME=[3A4855D0:01C25A39] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g8C8n8v23289 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi, The topic "new environments where DHCP can be deployed" has to be discussed in a wg at the IETF. I do not know if it should be discussed in PANA, DHCP or other working group. When I read the PANA wg charter, I do not see any relationship between PANA activities and DHCP activities except that PANA protocol must not interfere with DHCP. Moreover, I believe that PANA working group asserts that host must have an IP address before using PANA protocol (please, tell me if I am wrong). In some contexts, for example xDSL access, I do not think that DHCP clients will have an IP address before connecting but there is a strong need for authentication before the client will receive configuration parameters from the server. Even if PANA working group deals with this issue, DHCP working group has to take this need into consideration in order to make the new PANA protocol compliant with DHCP protocol. David _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 12 07:51:32 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19570; Thu, 12 Sep 2002 07:51:32 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8CBoPv32508; Thu, 12 Sep 2002 07:50:25 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8CBnWv32466 for ; Thu, 12 Sep 2002 07:49:32 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19499 for ; Thu, 12 Sep 2002 07:47:48 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8CBmxW4015443; Thu, 12 Sep 2002 04:49:00 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8CBmxRL018681; Thu, 12 Sep 2002 04:48:59 -0700 (PDT) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn2-261.cisco.com [10.82.241.5]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id EAA04031; Thu, 12 Sep 2002 04:48:55 -0700 (PDT) Message-Id: <4.3.2.7.2.20020912073056.01950440@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 12 Sep 2002 07:48:54 -0400 To: "BINET David FTRD/DMI/CAE" From: John Schnizlein Subject: RE: [dhcwg] Items of the new wg charter Cc: In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At 04:48 AM 9/12/2002, BINET David FTRD/DMI/CAE wrote: >The topic "new environments where DHCP can be deployed" has to be >discussed in a wg at the IETF. This seems appropriate to include in the Charter discussion. My view is just a little different: the DHC WG need not go looking for new environments for DHCP, but any new technology that expects to become Internet-Standard should consider using it as part of the normal environment. >I do not know if it should be discussed in PANA, DHCP or other working >group. When I read the PANA wg charter, I do not see any relationship >between PANA activities and DHCP activities except that PANA protocol >must not interfere with DHCP. Moreover, I believe that PANA working >group asserts that host must have an IP address before using PANA >protocol (please, tell me if I am wrong). You are not wrong. The scope for PANA is authentication after IP access is established. There are other mechanisms, such as EAP, that operate over layer-2 prior to dynamic configuration of hosts (IP addr). The EAP WG is revising its definition to cover much more than PPP. >In some contexts, for example xDSL access, I do not think that DHCP >clients will have an IP address before connecting but there is a strong >need for authentication before the client will receive configuration >parameters from the server. >Even if PANA working group deals with this issue, DHCP working group has >to take this need into consideration in order to make the new PANA >protocol compliant with DHCP protocol. This really should work the other way, the DHC WG is not supposed to enforce compliance (or even compatibility - which is what I suspect you intended) of new protocols with its specifications. New protocols should avoid breaking operations that use standards-track protocols like DHCP. Some degree of coordination between layer-2 authentication (prior to IP address assignment) and DHCP is provided by mechanisms like the relay of RADIUS attributes from layer-2 authenticators into DHCP. http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-00.txt The DHC WG has been receptive to proposals for specific forms of coordination, as indicated by its adoption of this effort. It is reasonable to expect that it would be as receptive to specific proposals for any "new environments where DHCP can be deployed". John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 12 08:00:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20072; Thu, 12 Sep 2002 08:00:08 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8CBx3v00302; Thu, 12 Sep 2002 07:59:03 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8CBw4v32712 for ; Thu, 12 Sep 2002 07:58:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19709; Thu, 12 Sep 2002 07:56:20 -0400 (EDT) Message-Id: <200209121156.HAA19709@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 12 Sep 2002 07:56:20 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-concat-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Encoding Long Options in DHCPv4 Author(s) : T. Lemon, S. Cheshire Filename : draft-ietf-dhc-concat-05.txt Pages : 0 Date : 2002-9-11 This document specifies the processing rules for DHCPv4 options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-concat-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-concat-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-concat-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-11142216.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-concat-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-concat-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-11142216.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 12 08:02:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20163; Thu, 12 Sep 2002 08:02:00 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8CC0tv00411; Thu, 12 Sep 2002 08:00:55 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8CBwEv32743 for ; Thu, 12 Sep 2002 07:58:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19749; Thu, 12 Sep 2002 07:56:30 -0400 (EDT) Message-Id: <200209121156.HAA19749@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; CC: dhcwg@ietf.org, snmpv3@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 12 Sep 2002 07:56:30 -0400 Subject: [dhcwg] I-D ACTION:draft-bakke-dhc-snmp-trap-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Option for SNMP Notifications Author(s) : M. Bakke Filename : draft-bakke-dhc-snmp-trap-00.txt Pages : 4 Date : 2002-9-11 The Dynamic Host Configuration Protocol [RFC1531] provides a method for a host to retrieve common configuration parameters at boot time. These include the host's IP address, default gateway, subnet mask, DNS server, and other useful things. When a host is booted from the network, it does not have access to these configuration parameters from its local or network disk right away; it relies instead on DHCP to provide them. One such parameter that is not yet provided is a list of IP hosts to which to send SNMP notifications [RFC1448] during the boot process, particularly if the boot fails. As the host is already gleaning similar information from DHCP, a new option to specify these SNMP 'trap' hosts appears to be the simplest method to gain this information. Hosts not booting from the network benefit as well, since SNMP notification hosts can now be configured centrally through DHCP. This document describes a proposed DHCP option that specifies a list of SNMP notification hosts to which SNMP notifications should be sent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bakke-dhc-snmp-trap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bakke-dhc-snmp-trap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bakke-dhc-snmp-trap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-11142235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bakke-dhc-snmp-trap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bakke-dhc-snmp-trap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-11142235.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 12 11:01:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25857; Thu, 12 Sep 2002 11:01:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8CF0av10639; Thu, 12 Sep 2002 11:00:36 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8CExWv10582 for ; Thu, 12 Sep 2002 10:59:32 -0400 Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25725 for ; Thu, 12 Sep 2002 10:57:47 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g8CEuav01916 for ; Thu, 12 Sep 2002 10:56:36 -0400 Message-Id: <200209121456.g8CEuav01916@cichlid.adsl.duke.edu> To: dhcwg@ietf.org Subject: Re: [dhcwg] I-D ACTION:draft-ietf-dhc-concat-05.txt In-Reply-To: Message from Internet-Drafts@ietf.org of "Thu, 12 Sep 2002 07:56:20 EDT." <200209121156.HAA19709@ietf.org> Date: Thu, 12 Sep 2002 10:56:36 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Title : Encoding Long Options in DHCPv4 > Author(s) : T. Lemon, S. Cheshire > Filename : draft-ietf-dhc-concat-05.txt FYI, this version (as was the case with some other recent versions) incorporates some editorial clarifications that came out of IESG review. At this point, all known issues with this document have been resolved AFAIK, and I expect the IESG to approve it shortly. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 13 16:26:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17806; Fri, 13 Sep 2002 16:26:15 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DKOxv14512; Fri, 13 Sep 2002 16:24:59 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DKNev14458 for ; Fri, 13 Sep 2002 16:23:40 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17655 for ; Fri, 13 Sep 2002 16:21:52 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8DKMwds006281; Fri, 13 Sep 2002 13:22:58 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8DKMv27027862; Fri, 13 Sep 2002 13:22:57 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA25793; Fri, 13 Sep 2002 13:22:55 -0700 (PDT) Message-ID: <3D824DA5.8039B55A@cisco.com> Date: Fri, 13 Sep 2002 15:42:13 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "Harrington, David" CC: "'dhcwg@ietf.org'" References: <6D745637A7E0F94DA070743C55CDA9BA0757E1@NHROCMBX1.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: draft-bakke-dhc-snmp-trap-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David- Thanks for the advice. I just had a chance to go over 2571, 73, and 74, and I think I can take a better shot at this (at least the notification part). I'll post to both dhcwg and the snmpv3 lists. As far as the scope for this, I was initially just setting out to do enough for notifications. Do you think that there is interest in configuring other agent parameters as well? - Mark > "Harrington, David" wrote: > > Hi Mark, > > RFC1448 is a remnant of the obsolete SNMPv2 specs. Nobody supports the old RFC144x specifications. > You should be using SNMPv3 specifications. The most current RFCs are 2570-2580, and approved > updates are in the editor's RFC queue. > > RFC2573 defines a number of mibs that can be configured to identify notification targets. If you > examine those mibs, you will find that there is more information needed than just an address. > Therefore, your proposed message would need to contain more to centrally configure SNMP targets > properly. > > dbh > > David Harrington > co-chair SNMPv2 WG > Network Management Architect > Office of the CTO > Enterasys Networks > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 14 07:49:23 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09533; Sat, 14 Sep 2002 07:49:23 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8EBmJv27632; Sat, 14 Sep 2002 07:48:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DDUuv23150 for ; Fri, 13 Sep 2002 09:30:56 -0400 Received: from ctron-dnm.enterasys.com (firewall-user@[12.25.1.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04766 for ; Fri, 13 Sep 2002 09:29:12 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id JAA28346; Fri, 13 Sep 2002 09:37:11 -0400 (EDT) Received: from unknown(134.141.77.96) by ctron-dnm.enterasys.com via smap (4.1) id xma028326; Fri, 13 Sep 02 09:36:29 -0400 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Sep 2002 09:20:05 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA0757E1@NHROCMBX1.ets.enterasys.com> From: "Harrington, David" To: "'mbakke@cisco.com'" , "'dhcwg@ietf.org'" Date: Fri, 13 Sep 2002 09:24:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25B28.F47590FF" Subject: [dhcwg] draft-bakke-dhc-snmp-trap-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C25B28.F47590FF Content-Type: text/plain; charset="iso-8859-1" Hi Mark, RFC1448 is a remnant of the obsolete SNMPv2 specs. Nobody supports the old RFC144x specifications. You should be using SNMPv3 specifications. The most current RFCs are 2570-2580, and approved updates are in the editor's RFC queue. RFC2573 defines a number of mibs that can be configured to identify notification targets. If you examine those mibs, you will find that there is more information needed than just an address. Therefore, your proposed message would need to contain more to centrally configure SNMP targets properly. dbh David Harrington co-chair SNMPv2 WG Network Management Architect Office of the CTO Enterasys Networks ------_=_NextPart_001_01C25B28.F47590FF Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-bakke-dhc-snmp-trap-00.txt

Hi Mark,

RFC1448 is a remnant of the obsolete SNMPv2 specs. = Nobody supports the old RFC144x specifications. You should be using = SNMPv3 specifications. The most current RFCs are 2570-2580, and = approved updates are in the editor's RFC queue.

RFC2573 defines a number of mibs that can be = configured to identify notification targets. If you examine those mibs, = you will find that there is more information needed than just an = address. Therefore, your proposed message would need to contain more to = centrally configure SNMP targets properly.

dbh

David Harrington
co-chair SNMPv2 WG
Network Management Architect
Office of the CTO
Enterasys Networks
 

------_=_NextPart_001_01C25B28.F47590FF-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 14 07:55:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09607; Sat, 14 Sep 2002 07:55:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8EBsgv27711; Sat, 14 Sep 2002 07:54:42 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DFW0v29896 for ; Fri, 13 Sep 2002 11:32:00 -0400 Received: from albatross.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [193.180.251.49]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09143 for ; Fri, 13 Sep 2002 11:30:12 -0400 (EDT) Received: from esealnt613.al.sw.ericsson.se (esealnt613.al.sw.ericsson.se [153.88.254.72]) by albatross.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id g8DFVprU022905 for ; Fri, 13 Sep 2002 17:31:51 +0200 (MEST) Received: from ESEALNT744.al.sw.ericsson.se ([153.88.251.4]) by esealnt613.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id S4XVW3V7; Fri, 13 Sep 2002 17:31:51 +0200 Received: by ESEALNT744.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 13 Sep 2002 17:31:51 +0200 Message-ID: X-Sybari-Trust: 8a9aaf67 85462f84 76188661 00000138 From: "Rudra Mehta-Desai (EAS)" To: "'dhcwg@ietf.org'" Date: Fri, 13 Sep 2002 17:31:50 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] master / slave configuration on Solaris 8 DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hi, How can I set up master-slave configuration fpr 2 servers on the smae network to act as master and slave DHCP servers ?. Thanks and regards, __________________________________________________ ERICSSON Rudra Mehta Senior Systems Engineer Customer Support Services Market Unit DACH Ericsson AG Lagerhausweg 10 CH-3018 Bern Switzerland __________________________________________________ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 14 07:59:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09682; Sat, 14 Sep 2002 07:59:49 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8EBwpv27828; Sat, 14 Sep 2002 07:58:51 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8DM47v20744 for ; Fri, 13 Sep 2002 18:04:07 -0400 Received: from babbler.bmc.com (firebird.bmc.com [198.207.223.228]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA20151 for ; Fri, 13 Sep 2002 18:02:18 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8DM8cI05679; Fri, 13 Sep 2002 17:08:38 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id PAA02039; Fri, 13 Sep 2002 15:01:31 -0700 (PDT) Date: Fri, 13 Sep 2002 15:01:31 -0700 (PDT) From: Randy Presuhn Message-Id: <200209132201.PAA02039@dorothy.bmc.com> To: mibs@ops.ietf.org Cc: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: DHCP Option for SNMP Notifications Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi - > Message-ID: <3D7FBD54.C6EC2E2D@cisco.com> > Date: Wed, 11 Sep 2002 17:01:56 -0500 > From: Mark Bakke > To: "David T. Perkins" > Cc: dhcwg@ietf.org, mibs@ops.ietf.org > Subject: Re: DHCP Option for SNMP Notifications > References: <5.1.1.6.2.20020911134627.035dd7b0@127.0.0.1> <5.1.1.6.2.20020911142157.035df060@127.0.0.1> ... > Any pointers to what should be configured for security? ... See RFC 2574, especially section A.1, RFC 2575, especially section A.1, RFC 2786, "kick-starting" key distribution Note that there are current internet drafts with updates to all of these. As Bert has already pointed out, the notification destination stuff is in 2573, which also has an update "in the queue". draft-ietf-snmpv3-vacm-v2-01.txt draft-ietf-snmpv3-usm-v2-rfc2574bis-01.txt draft-ietf-ops-rfc2786std-00.txt draft-ietf-snmpv3-appl-v3-01.txt ------------------------------------------------------ Randy Presuhn BMC Software, Inc. SJC-1.3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Sep 15 14:54:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08822; Sun, 15 Sep 2002 14:54:33 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8FIrMv07901; Sun, 15 Sep 2002 14:53:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8FImDv07810 for ; Sun, 15 Sep 2002 14:48:13 -0400 Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08675 for ; Sun, 15 Sep 2002 14:46:24 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8FIlMds014604; Sun, 15 Sep 2002 11:47:22 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8FIlHQk011914; Sun, 15 Sep 2002 11:47:17 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA22483; Sun, 15 Sep 2002 11:47:16 -0700 (PDT) Message-ID: <3D84DA39.46533B3@cisco.com> Date: Sun, 15 Sep 2002 14:06:33 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: Randy Presuhn CC: mibs@ops.ietf.org, dhcwg@ietf.org References: <200209132201.PAA02039@dorothy.bmc.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [dhcwg] Re: DHCP Option for SNMP Notifications Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Randy- Thans for the additional pointers; I was unaware of the drafts. I'll try to propose something new in the next few days. -- Mark Randy Presuhn wrote: > > Hi - > > > Message-ID: <3D7FBD54.C6EC2E2D@cisco.com> > > Date: Wed, 11 Sep 2002 17:01:56 -0500 > > From: Mark Bakke > > To: "David T. Perkins" > > Cc: dhcwg@ietf.org, mibs@ops.ietf.org > > Subject: Re: DHCP Option for SNMP Notifications > > References: <5.1.1.6.2.20020911134627.035dd7b0@127.0.0.1> <5.1.1.6.2.20020911142157.035df060@127.0.0.1> > ... > > Any pointers to what should be configured for security? > ... > > See RFC 2574, especially section A.1, > RFC 2575, especially section A.1, > RFC 2786, "kick-starting" key distribution > > Note that there are current internet drafts with updates to all of these. > > As Bert has already pointed out, the notification destination > stuff is in 2573, which also has an update "in the queue". > > draft-ietf-snmpv3-vacm-v2-01.txt > draft-ietf-snmpv3-usm-v2-rfc2574bis-01.txt > draft-ietf-ops-rfc2786std-00.txt > draft-ietf-snmpv3-appl-v3-01.txt > > ------------------------------------------------------ > Randy Presuhn BMC Software, Inc. SJC-1.3141 > randy_presuhn@bmc.com 2141 North First Street > Tel: +1 408 546-1006 San José, California 95131 USA > ------------------------------------------------------ > My opinions and BMC's are independent variables. > ------------------------------------------------------ -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 16 04:04:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28112; Mon, 16 Sep 2002 04:04:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8G83iv15032; Mon, 16 Sep 2002 04:03:44 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8G82Fv14972 for ; Mon, 16 Sep 2002 04:02:15 -0400 Received: from proxy.6wind.com (proxy.6wind.com [194.250.197.211]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28085 for ; Mon, 16 Sep 2002 04:00:19 -0400 (EDT) Received: from intranet.6wind.com (intranet [10.0.0.113]) by proxy.6wind.com (Postfix) with ESMTP id 4C404D2 for ; Mon, 16 Sep 2002 10:07:03 +0200 (CEST) Received: from 6wind.com (unknown [10.16.0.134]) by intranet.6wind.com (Postfix) with ESMTP id D07CEB4FA for ; Mon, 16 Sep 2002 09:59:23 +0200 (CEST) Message-ID: <3D858FCC.7000800@6wind.com> Date: Mon, 16 Sep 2002 10:01:16 +0200 From: Jean-Mickael Guerin User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 X-Accept-Language: fr-fr MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Question about draft-troan-dhcpv6-opt-prefix-delegation-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The draft gives an example of network architecture which involves a AAA server. In this case, what information the delegating router can give to identify the subscriber, in order that AAA server selects the right subscriber's prefix ? -- Jean-Mickael GUERIN Tel : +33 1 39 30 92 33 Web site : www.6wind.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 16 04:44:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28599; Mon, 16 Sep 2002 04:44:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8G8hDv17044; Mon, 16 Sep 2002 04:43:13 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8G8gZv17029 for ; Mon, 16 Sep 2002 04:42:35 -0400 Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA28504 for ; Mon, 16 Sep 2002 04:40:37 -0400 (EDT) Received: from btmail.net.cn([202.106.196.71]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm43d859b23; Mon, 16 Sep 2002 08:41:33 -0000 Received: from lists.tislabs.com([192.94.214.101]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm3d3d80f499; Thu, 12 Sep 2002 14:40:49 -0000 Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA20925 Thu, 12 Sep 2002 08:59:58 -0400 (EDT) Message-Id: <200209121156.HAA19749@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce:;;;;;;;@tislabs.com;;;;;;;;;;;;;;; CC: dhcwg@ietf.org, snmpv3@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 12 Sep 2002 07:56:30 -0400 Precedence: bulk Subject: [dhcwg] I-D ACTION:draft-bakke-dhc-snmp-trap-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Option for SNMP Notifications Author(s) : M. Bakke Filename : draft-bakke-dhc-snmp-trap-00.txt Pages : 4 Date : 2002-9-11 The Dynamic Host Configuration Protocol [RFC1531] provides a method for a host to retrieve common configuration parameters at boot time. These include the host's IP address, default gateway, subnet mask, DNS server, and other useful things. When a host is booted from the network, it does not have access to these configuration parameters from its local or network disk right away; it relies instead on DHCP to provide them. One such parameter that is not yet provided is a list of IP hosts to which to send SNMP notifications [RFC1448] during the boot process, particularly if the boot fails. As the host is already gleaning similar information from DHCP, a new option to specify these SNMP 'trap' hosts appears to be the simplest method to gain this information. Hosts not booting from the network benefit as well, since SNMP notification hosts can now be configured centrally through DHCP. This document describes a proposed DHCP option that specifies a list of SNMP notification hosts to which SNMP notifications should be sent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bakke-dhc-snmp-trap-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-bakke-dhc-snmp-trap-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-bakke-dhc-snmp-trap-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-11142235.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-bakke-dhc-snmp-trap-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-bakke-dhc-snmp-trap-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-11142235.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 16 10:22:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06179; Mon, 16 Sep 2002 10:22:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GEM9v01831; Mon, 16 Sep 2002 10:22:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GEJfv01719 for ; Mon, 16 Sep 2002 10:19:41 -0400 Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06057 for ; Mon, 16 Sep 2002 10:17:52 -0400 (EDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id PAA15543; Mon, 16 Sep 2002 15:19:06 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Jean-Mickael Guerin Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Question about draft-troan-dhcpv6-opt-prefix-delegation-01.txt References: <3D858FCC.7000800@6wind.com> From: Ole Troan Date: Mon, 16 Sep 2002 15:19:06 +0100 In-Reply-To: <3D858FCC.7000800@6wind.com> (Jean-Mickael Guerin's message of "Mon, 16 Sep 2002 10:01:16 +0200") Message-ID: <7t5wupmaug5.fsf@mrwint.cisco.com> Lines: 12 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > The draft gives an example of network architecture which involves a > AAA server. In this case, what information the delegating router can > give to identify the subscriber, in order that AAA server selects the > right subscriber's prefix ? if the customer is connected to the delegating router via a link which already uses authentication, then that "identity" can also be used for PD. e.g point to point links with PPP authentication. I suppose you could also use a DHCP clientid. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 16 15:07:17 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14461; Mon, 16 Sep 2002 15:07:17 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GJ79v17988; Mon, 16 Sep 2002 15:07:09 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8GJ3rv17612 for ; Mon, 16 Sep 2002 15:03:53 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14378 for ; Mon, 16 Sep 2002 15:02:03 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8GJ3IKB008588; Mon, 16 Sep 2002 12:03:18 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8GJ3Hwt024281; Mon, 16 Sep 2002 12:03:17 -0700 (PDT) Received: from cisco.com (mbakke-lnx.cisco.com [64.101.211.87]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id MAA25980; Mon, 16 Sep 2002 12:03:15 -0700 (PDT) Message-ID: <3D862F76.CAA63701@cisco.com> Date: Mon, 16 Sep 2002 14:22:30 -0500 From: Mark Bakke X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.16-3.uid32 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "'dhcwg@ietf.org'" , "snmpv3@lists. tislabs. com (E-mail)" , mibs@ops.ietf.org References: <6D745637A7E0F94DA070743C55CDA9BA0757E3@NHROCMBX1.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: draft-bakke-dhc-snmp-trap-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Here's another try at the snmp notification option for DHCP. It's not a formal draft; just a rough idea of what it might look like. If this seems to be the right approach, I'll issue another revision of the draft. I also changed this from a binary structure to a text format, since it needed to be fairly flexible. -- Mark DHCP snmp-trap-host option Here's a quick sketch of what the new trap-host option could look like. I realize I need to add better detail in the final draft. This list of configuration attributes is from RFC 2573 appendix A, which lists trap configuration examples. I'm assuming that in a DHCP environment, that the only address domain supported is UDP. I've also assumed that some other configuration info must exist to make the security name meaningful, but that this information does not belong directly in a list of notification hosts, and might be placed in some other, more general SNMP configuration option. snmp-notification-list option is a UTF-8 string consisting of a comma-separated list of notification targets. Each notification target is a colon-separated list of parameters in the following order: :[:] is a decimal field which must match one of the message processing model values defined in RFC 2571 in the SnmpMessageProcessingModel TC: 0 - SNMPv1 1 - SNMPv2c 2 - SNMPv2u and SNMPv2* (I'm not sure what this is for) 3 - SNMPv3 This is the IP address and UDP port number of the target. I wouldn't expect anyone to set up SNMP notifications over a non-IP protocol such as OSI or DDP using DHCP, so I didn't include a domain. We could add it back in if there's good reason. IPv4 addresses are specified as dotted decimal with optional port: nn.nn.nn.nn/port Example: 10.1.50.100/162 with the "/port" optional. IPv6 addresses are specified as a bracketed hexadecimal address, as specified in RFC2732, followed by the optional "/port". Example: [1080:0:0:0:8:800:200C:417A]/162. is optional and depends on the processing model used. For v1 and v2c, this consists of a community string - The community string to use when sending notifications to this target. If not specified, the default is "public". For v3, this specifies the security model and its paramters, and consists of: :: This is the security model number from the RFC 2571 SnmpSecurityModel TC. The current (decimal) values are: 1 - SNMPv1 2 - SNMPv2c 3 - User-Based Security Model (USM) This is the decimal security level number as specified in the RFC 2571 SnmpSecurityLevel TC: 1 - noAuthNoPriv 2 - authNoPriv 3 - authPriv This is the UTF-8 security name to be used with notifications to this target. Examples: A group of two v3 targets, both using USM with authentication but no privacy: 3:128.1.2.3/162:3:2:joe,3:128.2.4.6/162:3:2:joe A single v3 target, using USM with both authentication and privacy: 3:128.1.5.9/162:3:3:bob A single address that wants both v1 and v2c notifications with the default community string and UDP port: 0:10.1.1.1,1:10.1.1.1 An SNMPv2 address that uses a different community string: 1:10.50.2.100:my-community BTW, using 0 for v1, 1 for v2c, and 3 for v3 is confusing, and these strings have to be typed in by DHCP adminstrators. We could go with text tags "v1", "v2c", and "v3" instead for message processing models, and allow "usm" for the security model as well: v3:128.1.2.3/162:usm:authNoPriv:joe,3:128.2.4.6/162:usm:authNoPriv:joe v3:128.1.5.9/162:usm:authPriv:bob v1:10.1.1.1,v2c:10.1.1.1 v2c:10.50.2.100:my-community Any preferences? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 17 12:49:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21372; Tue, 17 Sep 2002 12:49:50 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HGmkv26334; Tue, 17 Sep 2002 12:48:47 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HGl2v26042 for ; Tue, 17 Sep 2002 12:47:02 -0400 Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21273 for ; Tue, 17 Sep 2002 12:45:11 -0400 (EDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id RAA27561; Tue, 17 Sep 2002 17:46:27 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: dhcwg@ietf.org From: Ole Troan Date: Tue, 17 Sep 2002 17:46:27 +0100 Message-ID: <7t5fzw8k1i4.fsf@mrwint.cisco.com> Lines: 51 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I'm working on the next draft of DHCPv6 Prefix Delegation. I'm trying to avoid having to specify client/server behaviour for each type of message exchange in the PD document. Unfortunately the base DHCPv6 specification is very IA centric with regards to all statefull message exchanges. It would been a lot easier to add new "statefull" options if the base spec specified the message exchange in a generic way, and specified the IA option only in the options section. well, well, I guess it is a bit late now. a question on Confirm behaviour. draft-ietf-dhc-dhcpv6-26.txt says: «18.2.2. Receipt of Confirm messages When the server receives a Confirm message, the server determines if the addresses in the Confirm message are appropriate to the link to which the client is attached. The server ignores the T1 and T2 fields in the IA options and the preferred-lifetime and valid-lifetime fields in the IA Address options. If all of the addresses in the Confirm message pass this test, the server returns a status of Success. If any of the addresses do not pass this test, the server returns a status of NotOnLink. If the server does not find any addresses that are not appropriate to the link to which the client is connected, but cannot determine if some of the addresses are appropriate to the link or not appropriate to the link, the server MUST NOT send a reply to the client. For example, if the server does not have information about prefixes on the link to which the client is connected, the server does not reply.» from my understanding of the above, a server is allowed to reply to a confirm even if it does not have a binding for the client. what is the reason for not requiring that only the server with the binding can reply to the Confirm message? in the case of Prefix Delegation, I'm not sure it makes sense to have servers without the binding replying. if a client has a binding including both IA and PD options. there are two DHCP servers, one which doesn't support PD. how should the client behave when sending a Confirm, as it could get a reply from the non-PD server. as far as I can tell there is no way for the client to identify which options the server has confirmed(?). the client can ignore all replies from servers which do not match the server-ID of course. I would really like to avoid different behaviour for the basic message exchanges, dependent on IA or PD. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 17 14:01:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24041; Tue, 17 Sep 2002 14:01:44 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HI0Xv30717; Tue, 17 Sep 2002 14:00:35 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HHxvv30640 for ; Tue, 17 Sep 2002 13:59:57 -0400 Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23874 for ; Tue, 17 Sep 2002 13:58:02 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g8HHxlj20951; Tue, 17 Sep 2002 12:59:47 -0500 (CDT) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g8HHxlG29549; Tue, 17 Sep 2002 12:59:47 -0500 (CDT) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Tue, 17 Sep 2002 12:59:47 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Ole Troan'" , dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation Date: Tue, 17 Sep 2002 12:59:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25E74.01D641D2" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C25E74.01D641D2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ole: There are actually three "responses" from a server: - Respond with a Reply indicating success. - Respond with a Reply indicating failure. - Don't respond (if the data can not be confirmed). Now, if a CONFIRM includes options a server does not know about = (because they are new since the server was implemented), it will ignore these new options. = And it would then base its action on the remaining options. In the case where there are no remaining IA options that clearly define = whether the client is on the correct link, the server should NOT = respond. Otherwise, the server should be able to respond. Please note that the CONFIRM is not "confirm all configuration = parameters" ... it is confirm that the link is still valid. It is there = only to help the client figure out if it can continue to use the = configuration parameters it has (because it is still on the same link). Should CONFIRM be used to with prefixes? I guess they could be since = they define the link. But if only prefixes are present, any server that hasn't = implemented prefix delegation would not be able to respond. BTW, the above description is also why ANY server *can* respond if the = IA information available is unique enough. - Bernie -----Original Message----- From: Ole Troan [mailto:ot@cisco.com] Sent: Tuesday, September 17, 2002 12:46 PM To: dhcwg@ietf.org Subject: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation I'm working on the next draft of DHCPv6 Prefix Delegation. I'm trying to avoid having to specify client/server behaviour for each type of message exchange in the PD document. Unfortunately the base DHCPv6 specification is very IA centric with regards to all statefull message exchanges. It would been a lot easier to add new "statefull" options if the base spec specified the message exchange in a generic way, and specified the IA option only in the options section. well, well, I guess it is a bit late now. a question on Confirm behaviour. draft-ietf-dhc-dhcpv6-26.txt says: =AB18.2.2. Receipt of Confirm messages When the server receives a Confirm message, the server determines if the addresses in the Confirm message are appropriate to the link to which the client is attached. The server ignores the T1 and T2 fields in the IA options and the preferred-lifetime and valid-lifetime fields in the IA Address options. If all of the addresses in the Confirm message pass this test, the server returns a status of Success. If any of the addresses do not pass this test, the server returns a status of NotOnLink. If the server does not find any addresses that are not appropriate = to the link to which the client is connected, but cannot determine if some of the addresses are appropriate to the link or not appropriate to the link, the server MUST NOT send a reply to the client. For example, if the server does not have information about prefixes on the link to which the client is connected, the server does not = reply.=BB from my understanding of the above, a server is allowed to reply to a confirm even if it does not have a binding for the client. what is the reason for not requiring that only the server with the binding can reply to the Confirm message? in the case of Prefix Delegation, I'm not sure it makes sense to have servers without the binding replying. if a client has a binding including both IA and PD options. there are two DHCP servers, one which doesn't support PD. how should the client behave when sending a Confirm, as it could get a reply from the non-PD server. as far as I can tell there is no way for the client to identify which options the server has confirmed(?). the client can ignore all replies from servers which do not match the server-ID of course. I would really like to avoid different behaviour for the basic message exchanges, dependent on IA or PD. /ot _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C25E74.01D641D2 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCPv6 Confirm behaviour & Prefix = Delegation

Ole:

There are actually three "responses" from a = server:
- Respond with a Reply indicating success.
- Respond with a Reply indicating failure.
- Don't respond (if the data can not be = confirmed).

Now, if a CONFIRM includes options a server does not = know about (because they are new
since the server was implemented), it will ignore = these new options. And it would
then base its action on the remaining = options.

In the case where there are no remaining IA options = that clearly define whether the client is on the correct link, the = server should NOT respond.

Otherwise, the server should be able to = respond.

Please note that the CONFIRM is not "confirm all = configuration parameters" ... it is confirm that the link is still = valid. It is there only to help the client figure out if it can = continue to use the configuration parameters it has (because it is = still on the same link).

Should CONFIRM be used to with prefixes? I guess they = could be since they define the
link. But if only prefixes are present, any server = that hasn't implemented prefix
delegation would not be able to respond.

BTW, the above description is also why ANY server = *can* respond if the IA information
available is unique enough.

- Bernie

-----Original Message-----
From: Ole Troan [mailto:ot@cisco.com]
Sent: Tuesday, September 17, 2002 12:46 PM
To: dhcwg@ietf.org
Subject: [dhcwg] DHCPv6 Confirm behaviour & = Prefix Delegation


I'm working on the next draft of DHCPv6 Prefix = Delegation. I'm trying
to avoid having to specify client/server behaviour = for each type of
message exchange in the PD document. Unfortunately = the base DHCPv6
specification is very IA centric with regards to all = statefull message
exchanges. It would been a lot easier to add new = "statefull" options
if the base spec specified the message exchange in a = generic way, and
specified the IA option only in the options section. = well, well, I
guess it is a bit late now.

a question on Confirm behaviour.

draft-ietf-dhc-dhcpv6-26.txt says:
=AB18.2.2. Receipt of Confirm messages

   When the server receives a Confirm = message, the server determines
   if the addresses in the Confirm message = are appropriate to the
   link to which the client is = attached.  The server ignores the T1
   and T2 fields in the IA options and the = preferred-lifetime and
   valid-lifetime fields in the IA Address = options.

   If all of the addresses in the Confirm = message pass this test, the
   server returns a status of = Success.  If any of the addresses do not
   pass this test, the server returns a = status of NotOnLink.

   If the server does not find any = addresses that are not appropriate to
   the link to which the client is = connected, but cannot determine if
   some of the addresses are appropriate = to the link or not appropriate
   to the link, the server MUST NOT send a = reply to the client.  For
   example, if the server does not have = information about prefixes on
   the link to which the client is = connected, the server does not reply.=BB



from my understanding of the above, a server is = allowed to reply to a
confirm even if it does not have a binding for the = client.
what is the reason for not requiring that only the = server with the
binding can reply to the Confirm message?

in the case of Prefix Delegation, I'm not sure it = makes sense to have
servers without the binding replying. if a client = has a binding
including both IA and PD options. there are two DHCP = servers, one
which doesn't support PD. how should the client = behave when sending a
Confirm, as it could get a reply from the non-PD = server. as far as I
can tell there is no way for the client to identify = which options the
server has confirmed(?). the client can ignore all = replies from
servers which do not match the server-ID of = course.

I would really like to avoid different behaviour for = the basic message
exchanges, dependent on IA or PD.

/ot
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C25E74.01D641D2-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 17 18:12:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02330; Tue, 17 Sep 2002 18:12:30 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HMBAv13241; Tue, 17 Sep 2002 18:11:10 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8G3Gxv27306 for ; Sun, 15 Sep 2002 23:16:59 -0400 Received: from ctron-dnm.enterasys.com (firewall-user@[12.25.1.120]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA15472 for ; Sun, 15 Sep 2002 23:15:06 -0400 (EDT) Received: (from uucp@localhost) by ctron-dnm.enterasys.com (8.8.7/8.8.7) id XAA09837; Sun, 15 Sep 2002 23:24:45 -0400 (EDT) Received: from unknown(134.141.77.96) by ctron-dnm.enterasys.com via smap (4.1) id xma009835; Sun, 15 Sep 02 23:24:04 -0400 Received: by cnc-exc1.enterasys.com with Internet Mail Service (5.5.2653.19) id ; Sun, 15 Sep 2002 23:07:36 -0400 Message-ID: <6D745637A7E0F94DA070743C55CDA9BA0757E3@NHROCMBX1.ets.enterasys.com> From: "Harrington, David" To: "'Mark Bakke'" Cc: "'dhcwg@ietf.org'" , "snmpv3@lists. tislabs. com (E-mail)" Date: Sun, 15 Sep 2002 23:12:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25D2E.E1E1D826" Subject: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C25D2E.E1E1D826 Content-Type: text/plain Hi Mark, The bulk of the current usage of SNMP is for monitoring, not configuring. There are few mib objects that would require dynamic configuration. However, it could be a very interesting discussion to start with the SNMP community via the SNMPv3 list. We're trying to wrap up and close the SNMPv3 WG. I think the discussion would need to move to a different forum, but which forum depends to a large degree on nature of the proposals that might come out of the discussion. dbh > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: Friday, September 13, 2002 4:42 PM > To: Harrington, David > Cc: 'dhcwg@ietf.org' > Subject: Re: draft-bakke-dhc-snmp-trap-00.txt > > > David- > > Thanks for the advice. I just had a chance to go over 2571, > 73, and 74, and > I think I can take a better shot at this (at least the > notification part). I'll > post to both dhcwg and the snmpv3 lists. > > As far as the scope for this, I was initially just setting out to do > enough for notifications. Do you think that there is interest in > configuring other agent parameters as well? > > - > Mark > > > "Harrington, David" wrote: > > > > Hi Mark, > > > > RFC1448 is a remnant of the obsolete SNMPv2 specs. Nobody > supports the old RFC144x specifications. > > You should be using SNMPv3 specifications. The most current > RFCs are 2570-2580, and approved > > updates are in the editor's RFC queue. > > > > RFC2573 defines a number of mibs that can be configured to > identify notification targets. If you > > examine those mibs, you will find that there is more > information needed than just an address. > > Therefore, your proposed message would need to contain more > to centrally configure SNMP targets > > properly. > > > > dbh > > > > David Harrington > > co-chair SNMPv2 WG > > Network Management Architect > > Office of the CTO > > Enterasys Networks > > > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > ------_=_NextPart_001_01C25D2E.E1E1D826 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: draft-bakke-dhc-snmp-trap-00.txt

Hi Mark,

The bulk of the current usage of SNMP is for = monitoring, not configuring. There are few mib objects that would = require dynamic configuration. However, it could be a very interesting = discussion to start with the SNMP community via the SNMPv3 = list.

We're trying to wrap up and close the SNMPv3 WG. I = think the discussion would need to move to a different forum, but which = forum depends to a large degree on nature of the proposals that might = come out of the discussion.

dbh

> -----Original Message-----
> From: Mark Bakke [mailto:mbakke@cisco.com]
> Sent: Friday, September 13, 2002 4:42 PM
> To: Harrington, David
> Cc: 'dhcwg@ietf.org'
> Subject: Re: = draft-bakke-dhc-snmp-trap-00.txt
>
>
> David-
>
> Thanks for the advice.  I just had a = chance to go over 2571,
> 73, and 74, and
> I think I can take a better shot at this (at = least the
> notification part).  I'll
> post to both dhcwg and the snmpv3 lists.
>
> As far as the scope for this, I was initially = just setting out to do
> enough for notifications.  Do you think = that there is interest in
> configuring other agent parameters as = well?
>
> -
> Mark
>
> > "Harrington, David" = wrote:
> >
> > Hi Mark,
> >
> > RFC1448 is a remnant of the obsolete = SNMPv2 specs. Nobody
> supports the old RFC144x specifications.
> > You should be using SNMPv3 specifications. = The most current
> RFCs are 2570-2580, and approved
> > updates are in the editor's RFC = queue.
> >
> > RFC2573 defines a number of mibs that can = be configured to
> identify notification targets. If you
> > examine those mibs, you will find that = there is more
> information needed than just an address.
> > Therefore, your proposed message would = need to contain more
> to centrally configure SNMP targets
> > properly.
> >
> > dbh
> >
> > David Harrington
> > co-chair SNMPv2 WG
> > Network Management Architect
> > Office of the CTO
> > Enterasys Networks
> >
>
> --
> Mark A. Bakke
> Cisco Systems
> mbakke@cisco.com
> 763.398.1054
>

------_=_NextPart_001_01C25D2E.E1E1D826-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 17 18:14:53 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02389; Tue, 17 Sep 2002 18:14:53 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8HMDnv13309; Tue, 17 Sep 2002 18:13:49 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8H0gFv01202 for ; Mon, 16 Sep 2002 20:42:15 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21036 for ; Mon, 16 Sep 2002 20:40:22 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8H0fao24863 for ; Mon, 16 Sep 2002 20:41:36 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 17 Sep 2002 02:41:35 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Mark Bakke , "'dhcwg@ietf.org'" , "snmpv3@lists. tislabs. com (E-mail)" , mibs@ops.ietf.org Date: Tue, 17 Sep 2002 02:41:34 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , So in your new proposal, how did/do users Joe and Bob get defined with their secret keys etc at the agent side? Thanks, Bert _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 18 20:07:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04269; Wed, 18 Sep 2002 20:07:35 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8J08Jv20516; Wed, 18 Sep 2002 20:08:19 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8J04Nv19894 for ; Wed, 18 Sep 2002 20:04:23 -0400 Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04185 for ; Wed, 18 Sep 2002 20:02:28 -0400 (EDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id BAA18142; Thu, 19 Sep 2002 01:03:44 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation References: From: Ole Troan Date: Thu, 19 Sep 2002 01:03:43 +0100 In-Reply-To: ("Bernie Volz's message of "Tue, 17 Sep 2002 12:59:46 -0500") Message-ID: <7t57khi3kww.fsf@mrwint.cisco.com> Lines: 51 User-Agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Bernie, > There are actually three "responses" from a server: > - Respond with a Reply indicating success. > - Respond with a Reply indicating failure. > - Don't respond (if the data can not be confirmed). > > Now, if a CONFIRM includes options a server does not know about > (because they are new since the server was implemented), it will > ignore these new options. And it would then base its action on the > remaining options. > > In the case where there are no remaining IA options that clearly define whether the client is on the correct link, the server should NOT respond. > > Otherwise, the server should be able to respond. will the server include the options it confirms in the REPLY? this is not clear to me from reading the spec. for both PD and IA to be confirmed independently it must. > Please note that the CONFIRM is not "confirm all configuration > parameters" ... it is confirm that the link is still valid. It is > there only to help the client figure out if it can continue to use > the configuration parameters it has (because it is still on the same > link). I think CONFIRM is specified in a too restrictive way. I would like it to be useful for any statefull option. > Should CONFIRM be used to with prefixes? I guess they could be since > they define the link. But if only prefixes are present, any server > that hasn't implemented prefix delegation would not be able to > respond. I don't think it can be used as it currently stands. a DHCP server has no notion of a "onlink" property of a delegated prefix. prefixes are typically delegated to a site, not to a link. > BTW, the above description is also why ANY server *can* respond if > the IA information available is unique enough. right. if the REPLY to the CONFIRM includes which options are confirmed, and the client side text also states that the options have to be parsed in addition to checking the status code, it should work. then we can add additional text in the PD document to make the client retry CONFIRMs until all options are accounted for. cheers, Ole _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 18 21:44:28 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06772; Wed, 18 Sep 2002 21:44:27 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8J1jMv24940; Wed, 18 Sep 2002 21:45:22 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8J1gqv24863 for ; Wed, 18 Sep 2002 21:42:52 -0400 Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06733 for ; Wed, 18 Sep 2002 21:40:58 -0400 (EDT) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g8J1gij04236; Wed, 18 Sep 2002 20:42:44 -0500 (CDT) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id g8J1ghK29240; Wed, 18 Sep 2002 20:42:44 -0500 (CDT) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 18 Sep 2002 20:42:43 -0500 Message-ID: From: "Bernie Volz (EUD)" To: "'Ole Troan'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation Date: Wed, 18 Sep 2002 20:42:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25F7D.D855EEBA" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C25F7D.D855EEBA Content-Type: text/plain; charset="iso-8859-1" Ole: CONFIRM is to confirm that the link is valid (or more clearly that the client is very likely still connected (or not connected) to the same link it was on when it obtained the address). Not that the entire configuration is valid. The assumption though is that the configuration is valid as the client is still located where it was and the previous lifetimes and renewal times can thus still apply. Why do you need this to do more? If the addresses in the CONFIRM are valid, why would the prefixes not be? We're not validating the lifetimes - just the prefixes for the addresses. If prefix delegations are included (and the server supports prefixes), it may be able to determine that these prefixes are valid "down the link" from which the CONFIRM came. Probably more importantly, it can confirm if those are NOT valid. I assume that CONFIRMs would always come from downstream routers? If a server receives the Confirm that doesn't understand the prefix delegations, than it should only respond if it can Confirm the prefixes for the addresses. I do think we should add something to the CONFIRM text that says that if the server has no options on which to base the confirmation, it must NOT reply. This case would handle the situation where a server receives a CONFIRM but there are no options on which it can base the decision. I think the existing text already accommodates this: If the server is unable to perform this test (for example, the server does not have information about prefixes on the link to which the client is connected), the server MUST NOT send a reply to the client. However, it would be better to explain this just in case. Perhaps by replacing the above text with: If the server is unable to perform this test (for example, the server does not have information about prefixes on the link to which the client is connected or there are no options in the CONFIRM for the server to test), the server MUST NOT send a reply to the client. We've discussed what CONFIRM is for many times and I'd hate to reopen that discussion. By adding the options, I fear that it will quickly be used to confirm more than whether the client is on the correct link or not. For example, if the client sent a Domain Name option but the Reply doesn't list that option, should the client consider the Confirm to have failed to fully confirm its configuration. That is NOT what we wanted CONFIRM to do! - Bernie -----Original Message----- From: Ole Troan [mailto:ot@cisco.com] Sent: Wednesday, September 18, 2002 8:04 PM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation Bernie, > There are actually three "responses" from a server: > - Respond with a Reply indicating success. > - Respond with a Reply indicating failure. > - Don't respond (if the data can not be confirmed). > > Now, if a CONFIRM includes options a server does not know about > (because they are new since the server was implemented), it will > ignore these new options. And it would then base its action on the > remaining options. > > In the case where there are no remaining IA options that clearly define whether the client is on the correct link, the server should NOT respond. > > Otherwise, the server should be able to respond. will the server include the options it confirms in the REPLY? this is not clear to me from reading the spec. for both PD and IA to be confirmed independently it must. > Please note that the CONFIRM is not "confirm all configuration > parameters" ... it is confirm that the link is still valid. It is > there only to help the client figure out if it can continue to use > the configuration parameters it has (because it is still on the same > link). I think CONFIRM is specified in a too restrictive way. I would like it to be useful for any statefull option. > Should CONFIRM be used to with prefixes? I guess they could be since > they define the link. But if only prefixes are present, any server > that hasn't implemented prefix delegation would not be able to > respond. I don't think it can be used as it currently stands. a DHCP server has no notion of a "onlink" property of a delegated prefix. prefixes are typically delegated to a site, not to a link. > BTW, the above description is also why ANY server *can* respond if > the IA information available is unique enough. right. if the REPLY to the CONFIRM includes which options are confirmed, and the client side text also states that the options have to be parsed in addition to checking the status code, it should work. then we can add additional text in the PD document to make the client retry CONFIRMs until all options are accounted for. cheers, Ole ------_=_NextPart_001_01C25F7D.D855EEBA Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation

Ole:

CONFIRM is to confirm that the link is valid (or more clearly that the client is very
likely still connected (or not connected) to the same link it was on when it obtained
the address). Not that the entire configuration is valid. The assumption though is that
the configuration is valid as the client is still located where it was and the previous
lifetimes and renewal times can thus still apply.

Why do you need this to do more? If the addresses in the CONFIRM are valid, why would the
prefixes not be? We're not validating the lifetimes - just the prefixes for the addresses.

If prefix delegations are included (and the server supports prefixes), it may be able to
determine that these prefixes are valid "down the link" from which the CONFIRM came.
Probably more importantly, it can confirm if those are NOT valid. I assume that CONFIRMs
would always come from downstream routers? If a server receives the Confirm that doesn't
understand the prefix delegations, than it should only respond if it can Confirm the
prefixes for the addresses.

I do think we should add something to the CONFIRM text that says that if the server has no
options on which to base the confirmation, it must NOT reply. This case would handle the
situation where a server receives a CONFIRM but there are no options on which it can base
the decision. I think the existing text already accommodates this:
   If the server is unable to perform this test
   (for example, the server does not have information about prefixes on
   the link to which the client is connected), the server MUST NOT send
   a reply to the client.
However, it would be better to explain this just in case. Perhaps by replacing the above
text with:
   If the server is unable to perform this test
   (for example, the server does not have information about prefixes on
   the link to which the client is connected or there are no options in
   the CONFIRM for the server to test), the server MUST NOT send
   a reply to the client.

We've discussed what CONFIRM is for many times and I'd hate to reopen that discussion. By
adding the options, I fear that it will quickly be used to confirm more than whether the
client is on the correct link or not. For example, if the client sent a Domain Name option
but the Reply doesn't list that option, should the client consider the Confirm to have failed
to fully confirm its configuration. That is NOT what we wanted CONFIRM to do!

- Bernie

-----Original Message-----
From: Ole Troan [mailto:ot@cisco.com]
Sent: Wednesday, September 18, 2002 8:04 PM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] DHCPv6 Confirm behaviour & Prefix Delegation


Bernie,

> There are actually three "responses" from a server:
> - Respond with a Reply indicating success.
> - Respond with a Reply indicating failure.
> - Don't respond (if the data can not be confirmed).
>
> Now, if a CONFIRM includes options a server does not know about
> (because they are new since the server was implemented), it will
> ignore these new options. And it would then base its action on the
> remaining options.
>
> In the case where there are no remaining IA options that clearly define whether the client is on the correct link, the server should NOT respond.

>
> Otherwise, the server should be able to respond.

will the server include the options it confirms in the REPLY? this is
not clear to me from reading the spec. for both PD and IA to be
confirmed independently it must.

> Please note that the CONFIRM is not "confirm all configuration
> parameters" ... it is confirm that the link is still valid. It is
> there only to help the client figure out if it can continue to use
> the configuration parameters it has (because it is still on the same
> link).

I think CONFIRM is specified in a too restrictive way. I would like it
to be useful for any statefull option.

> Should CONFIRM be used to with prefixes? I guess they could be since
> they define the link. But if only prefixes are present, any server
> that hasn't implemented prefix delegation would not be able to
> respond.

I don't think it can be used as it currently stands. a DHCP server has
no notion of a "onlink" property of a delegated prefix. prefixes are
typically delegated to a site, not to a link.

> BTW, the above description is also why ANY server *can* respond if
> the IA information available is unique enough.

right. if the REPLY to the CONFIRM includes which options are
confirmed, and the client side text also states that the options have
to be parsed in addition to checking the status code, it should
work.

then we can add additional text in the PD document to make the client
retry CONFIRMs until all options are accounted for.

cheers,
Ole

------_=_NextPart_001_01C25F7D.D855EEBA-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 19 16:49:40 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22797; Thu, 19 Sep 2002 16:49:40 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8JKmbv05153; Thu, 19 Sep 2002 16:48:40 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8ILWFv12857 for ; Wed, 18 Sep 2002 17:32:15 -0400 Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00739 for ; Wed, 18 Sep 2002 17:30:22 -0400 (EDT) Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8ILVWR11529 for ; Wed, 18 Sep 2002 14:31:32 -0700 (PDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g8ILVia27233 for ; Wed, 18 Sep 2002 16:31:44 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Wed, 18 Sep 2002 16:31:31 -0500 Message-ID: From: "Afshan Mahmood" To: "'dhcwg@ietf.org'" Date: Wed, 18 Sep 2002 16:31:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C25F5A.BFB37620" Subject: [dhcwg] DHCP - Server Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C25F5A.BFB37620 Content-Type: text/plain Has anyone tried a DHCP server with capacity using adtech. I need a DHCP server which can keep up with the traffic that I am creating with Adtech. DHCP server requirement I need a DHCP server, with DHCP client and DHCP relay option. Which can assign ip addresses with a rate of 250/sec. Let me know Thanks Afshan Mahmood ------_=_NextPart_001_01C25F5A.BFB37620 Content-Type: text/html Content-Transfer-Encoding: quoted-printable DHCP - Server

Has anyone tried a DHCP = server with capacity using adtech. I need a DHCP server which can keep = up with the traffic that I am creating with Adtech.

DHCP server requirement =

I  need a DHCP server, = with DHCP client and DHCP relay option. Which can assign ip addresses = with a rate of 250/sec.

Let me know
Thanks

Afshan = Mahmood

------_=_NextPart_001_01C25F5A.BFB37620-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 20 14:16:04 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02934; Fri, 20 Sep 2002 14:16:04 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KIGSv15295; Fri, 20 Sep 2002 14:16:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8KICev15186 for ; Fri, 20 Sep 2002 14:12:40 -0400 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02765 for ; Fri, 20 Sep 2002 14:10:47 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8KIBr1X017931; Fri, 20 Sep 2002 11:11:53 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8KIBqed006409; Fri, 20 Sep 2002 11:11:53 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA25408; Fri, 20 Sep 2002 11:11:46 -0700 (PDT) Message-ID: <3D8B64E2.78634E28@cisco.com> Date: Fri, 20 Sep 2002 13:11:46 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "Harrington, David" CC: "'dhcwg@ietf.org'" , "snmpv3@lists. tislabs. com (E-mail)" Subject: Re: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt References: <6D745637A7E0F94DA070743C55CDA9BA0757E3@NHROCMBX1.ets.enterasys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit David- I'm copying the mibs@ops.ietf.org list on this as well; is it sufficient? Should I not send this to snmpv3? Thanks, Mark > "Harrington, David" wrote: > > Hi Mark, > > The bulk of the current usage of SNMP is for monitoring, not configuring. There are few mib > objects that would require dynamic configuration. However, it could be a very interesting > discussion to start with the SNMP community via the SNMPv3 list. > > We're trying to wrap up and close the SNMPv3 WG. I think the discussion would need to move to a > different forum, but which forum depends to a large degree on nature of the proposals that might > come out of the discussion. > > dbh > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: Friday, September 13, 2002 4:42 PM > > To: Harrington, David > > Cc: 'dhcwg@ietf.org' > > Subject: Re: draft-bakke-dhc-snmp-trap-00.txt > > > > > > David- > > > > Thanks for the advice. I just had a chance to go over 2571, > > 73, and 74, and > > I think I can take a better shot at this (at least the > > notification part). I'll > > post to both dhcwg and the snmpv3 lists. > > > > As far as the scope for this, I was initially just setting out to do > > enough for notifications. Do you think that there is interest in > > configuring other agent parameters as well? > > > > - > > Mark > > > > > "Harrington, David" wrote: > > > > > > Hi Mark, > > > > > > RFC1448 is a remnant of the obsolete SNMPv2 specs. Nobody > > supports the old RFC144x specifications. > > > You should be using SNMPv3 specifications. The most current > > RFCs are 2570-2580, and approved > > > updates are in the editor's RFC queue. > > > > > > RFC2573 defines a number of mibs that can be configured to > > identify notification targets. If you > > > examine those mibs, you will find that there is more > > information needed than just an address. > > > Therefore, your proposed message would need to contain more > > to centrally configure SNMP targets > > > properly. > > > > > > dbh > > > > > > David Harrington > > > co-chair SNMPv2 WG > > > Network Management Architect > > > Office of the CTO > > > Enterasys Networks > > > > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 23 09:58:43 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09260; Mon, 23 Sep 2002 09:58:43 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8NDxBv12246; Mon, 23 Sep 2002 09:59:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8NDu0v12127 for ; Mon, 23 Sep 2002 09:56:00 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09093 for ; Mon, 23 Sep 2002 09:54:08 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8NDtM3x029616; Mon, 23 Sep 2002 06:55:22 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id g8NDtRlY021489; Mon, 23 Sep 2002 06:55:27 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id GAA15349; Mon, 23 Sep 2002 06:55:26 -0700 (PDT) Message-ID: <3D8F1D4E.B670EAE@cisco.com> Date: Mon, 23 Sep 2002 08:55:26 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "'dhcwg@ietf.org'" , "snmpv3@lists. tislabs. com (E-mail)" , mibs@ops.ietf.org References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: draft-bakke-dhc-snmp-trap-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit I assumed that, when we get to configuring SNMPv3 security, that the names "joe" and "bob" would be separately associated with their keys. I wanted to keep this particular DHCP option scope to include the notification list, and the names would reference keys configured somewhere else (perhaps another DHCP option, but since I haven't seen encrypted DHCP, this might not work). In other words, I don't know, but I think that if it was DHCP, it would be better as a separate option. Any ideas? "Wijnen, Bert (Bert)" wrote: > > So in your new proposal, how did/do users Joe and Bob get > defined with their secret keys etc at the agent side? > > Thanks, > Bert -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 23 14:50:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20476; Mon, 23 Sep 2002 14:50:39 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8NIpTv30137; Mon, 23 Sep 2002 14:51:29 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8NHluv26339 for ; Mon, 23 Sep 2002 13:47:56 -0400 Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18301 for ; Mon, 23 Sep 2002 13:46:00 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail1.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8NHlG827059 for ; Mon, 23 Sep 2002 13:47:16 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Mon, 23 Sep 2002 19:47:15 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Mark Bakke , "Wijnen, Bert (Bert)" Cc: "'dhcwg@ietf.org'" , "snmpv3@lists. tislabs. com (E-mail)" , mibs@ops.ietf.org Date: Mon, 23 Sep 2002 19:47:12 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , So it seems you did not think about it in detail. What I hate to see is a partial solution to jsut the trap handling. That is what the IPCDN (cable modem folk) seemed to be doing too... and I pushed back on that (partial) solution too. I do not have a answer ready... First question would be: is it a generic problem that people face? Second question: what is the complete scope of the problem? Third question: what would be a good/feasable/workable solution? Thanks, Bert > -----Original Message----- > From: Mark Bakke [mailto:mbakke@cisco.com] > Sent: maandag 23 september 2002 15:55 > To: Wijnen, Bert (Bert) > Cc: 'dhcwg@ietf.org'; snmpv3@lists. tislabs. com (E-mail); > mibs@ops.ietf.org > Subject: Re: draft-bakke-dhc-snmp-trap-00.txt > > > I assumed that, when we get to configuring SNMPv3 security, > that the names "joe" and "bob" would be separately associated > with their keys. I wanted to keep this particular DHCP > option scope to include the notification list, and the names > would reference keys configured somewhere else (perhaps another > DHCP option, but since I haven't seen encrypted DHCP, this > might not work). In other words, I don't know, but I think > that if it was DHCP, it would be better as a separate option. > > Any ideas? > > "Wijnen, Bert (Bert)" wrote: > > > > So in your new proposal, how did/do users Joe and Bob get > > defined with their secret keys etc at the agent side? > > > > Thanks, > > Bert > > -- > Mark A. Bakke > Cisco Systems > mbakke@cisco.com > 763.398.1054 > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 23 17:19:46 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25473; Mon, 23 Sep 2002 17:19:46 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8NLKXv06919; Mon, 23 Sep 2002 17:20:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8NLJ5v06859 for ; Mon, 23 Sep 2002 17:19:05 -0400 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25370 for ; Mon, 23 Sep 2002 17:17:08 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g8NLIN3x028404; Mon, 23 Sep 2002 14:18:23 -0700 (PDT) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id g8NLISc8000718; Mon, 23 Sep 2002 14:18:28 -0700 (PDT) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id OAA23285; Mon, 23 Sep 2002 14:18:16 -0700 (PDT) Message-ID: <3D8F8518.ACAF702C@cisco.com> Date: Mon, 23 Sep 2002 16:18:16 -0500 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: "Wijnen, Bert (Bert)" CC: "'dhcwg@ietf.org'" , "snmpv3@lists. tislabs. com (E-mail)" , mibs@ops.ietf.org Subject: Re: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit "Wijnen, Bert (Bert)" wrote: > > So it seems you did not think about it in detail. > What I hate to see is a partial solution to jsut the trap > handling. That is what the IPCDN (cable modem folk) seemed > to be doing too... and I pushed back on that (partial) > solution too. I do not have a answer ready... > > First question would be: is it a generic problem that people face? Yes. There are increasingly more solutions that allow hosts, racks of servers, embedded devices, etc. to be booted from the network. When this fails, the host's normal configuration info (particularly the SNMP notification list) is not available, so there's no good way to tell a management station about it. I assume that most networks would want to use SNMP for this, but syslog would work as well. > > Second question: what is the complete scope of the problem? My personal complete scope is to set a notification list for SNMPv1 and v2c hosts, with v3 a possibility in the future. Since this is used only for notifications, I assume that supporting v3 authentication would be a good idea (so notifications are not spoofed) but that privacy is probably not that much of an issue (but again, may need to be there for completeness). > Third question: what would be a good/feasable/workable solution? However, it may not be possible to configure enough of the security stuff securely (did I say that right) using DHCP to actually make use of v3 security. If that's the case, there could be a compromise: - Configure the list of v1, v2c, and v3 notification targets as I had proposed, with only the security name (and not the keys) in the v3 target strings. - During boot, if a notification needs to be sent, and the v3 security parameters are not yet known for a target, skip that target, but still send to the others in the list (such as the v1 and v2c targets). - Once the host has booted far enough so the security parameters are known (through its normal configuration), include the v3 targets in any notifications. This means two scenarios can happen: 1. A host, during boot, only sends v1 and/or v2c notifications without security. Once it's up and running, notifications include v3 targets, too. 2. A host has v3 username-to-security-parameter settings in its non-volatile configuration. These are available during boot, and can be associated with a notification target from DHCP by its security-name. This might be the best direction to go for the future; have security keys in the machines, and the actual targets for notification controlled centrally via DHCP. I think this would be a reasonable solution, given that it's probably not practical to configure the security keys for a host using DHCP. Does this help? -- Mark > > Thanks, > Bert > > > -----Original Message----- > > From: Mark Bakke [mailto:mbakke@cisco.com] > > Sent: maandag 23 september 2002 15:55 > > To: Wijnen, Bert (Bert) > > Cc: 'dhcwg@ietf.org'; snmpv3@lists. tislabs. com (E-mail); > > mibs@ops.ietf.org > > Subject: Re: draft-bakke-dhc-snmp-trap-00.txt > > > > > > I assumed that, when we get to configuring SNMPv3 security, > > that the names "joe" and "bob" would be separately associated > > with their keys. I wanted to keep this particular DHCP > > option scope to include the notification list, and the names > > would reference keys configured somewhere else (perhaps another > > DHCP option, but since I haven't seen encrypted DHCP, this > > might not work). In other words, I don't know, but I think > > that if it was DHCP, it would be better as a separate option. > > > > Any ideas? > > > > "Wijnen, Bert (Bert)" wrote: > > > > > > So in your new proposal, how did/do users Joe and Bob get > > > defined with their secret keys etc at the agent side? > > > > > > Thanks, > > > Bert > > > > -- > > Mark A. Bakke > > Cisco Systems > > mbakke@cisco.com > > 763.398.1054 > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 24 07:20:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22679; Tue, 24 Sep 2002 07:20:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OBKsv25350; Tue, 24 Sep 2002 07:20:54 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OBJVv25290 for ; Tue, 24 Sep 2002 07:19:31 -0400 Received: from web20901.mail.yahoo.com (web20901.mail.yahoo.com [216.136.226.223]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA22641 for ; Tue, 24 Sep 2002 07:17:40 -0400 (EDT) Message-ID: <20020924111929.55038.qmail@web20901.mail.yahoo.com> Received: from [193.231.255.202] by web20901.mail.yahoo.com via HTTP; Tue, 24 Sep 2002 04:19:29 PDT Date: Tue, 24 Sep 2002 04:19:29 -0700 (PDT) From: mitu mihaela To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] helo Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , helooooooo __________________________________________________ Do you Yahoo!? New DSL Internet Access from SBC & Yahoo! http://sbc.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 25 21:45:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15289; Wed, 25 Sep 2002 21:45:45 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8Q1kdv27220; Wed, 25 Sep 2002 21:46:39 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8O9Gsv19228 for ; Tue, 24 Sep 2002 05:16:54 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com [192.11.226.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA20696 for ; Tue, 24 Sep 2002 05:15:02 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by hoemail2.firewall.lucent.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g8O9GME21146 for ; Tue, 24 Sep 2002 05:16:22 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2653.19) id ; Tue, 24 Sep 2002 11:16:21 +0200 Message-ID: From: "Wijnen, Bert (Bert)" To: Mark Bakke Cc: "'dhcwg@ietf.org'" , "snmpv3@lists. tislabs. com (E-mail)" , mibs@ops.ietf.org Subject: RE: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt Date: Tue, 24 Sep 2002 11:16:07 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Mark, thanks for the details. Now... I have seen some discussion as to possible issues and such (I guess I am to blame for some of that). What I have not yet seen is any supportive statements from people that they indeed need this functionality. Best would be if operators of course tell us they need it. But in general, we'd like to hear statements about the need for this functionality. So an answer to this question: > > First question would be: is it a generic problem that people face? > Yes. There are increasingly more solutions that allow hosts, > racks of servers, embedded devices, etc. to be booted from > the network. When this fails, the host's normal configuration > info (particularly the SNMP notification list) is not available, > so there's no good way to tell a management station about it. > > I assume that most networks would want to use SNMP for this, > but syslog would work as well. > Mark's answer is just one answer that seem to support a YES answer Any others? Thanks, Bert _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 25 21:46:06 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15324; Wed, 25 Sep 2002 21:46:06 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8Q1l1v27275; Wed, 25 Sep 2002 21:47:01 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8OInfv19976 for ; Tue, 24 Sep 2002 14:49:41 -0400 Received: from babbler.bmc.com (camaro.bmc.com [198.207.223.231]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08790 for ; Tue, 24 Sep 2002 14:47:45 -0400 (EDT) Received: from dorothy.bmc.com (localhost [127.0.0.1]) by babbler.bmc.com (8.10.2/8.10.2) with ESMTP id g8OIpxm22257; Tue, 24 Sep 2002 13:51:59 -0500 (CDT) Received: (from rpresuhn@localhost) by dorothy.bmc.com (8.8.6 (PHNE_12836)/8.8.6) id LAA20555; Tue, 24 Sep 2002 11:44:45 -0700 (PDT) Date: Tue, 24 Sep 2002 11:44:45 -0700 (PDT) From: Randy Presuhn Message-Id: <200209241844.LAA20555@dorothy.bmc.com> To: dhcwg@ietf.org, mibs@ops.ietf.org, snmpv3@lists.tislabs.com Subject: RE: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi - > Message-ID: > From: "Wijnen, Bert (Bert)" > To: Mark Bakke > Cc: "'dhcwg@ietf.org'" , > "snmpv3@lists. tislabs. com (E-mail)" , > mibs@ops.ietf.org > Subject: RE: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt > Date: Tue, 24 Sep 2002 11:16:07 +0200 ... > > > First question would be: is it a generic problem that people face? > > Yes. There are increasingly more solutions that allow hosts, > > racks of servers, embedded devices, etc. to be booted from > > the network. When this fails, the host's normal configuration > > info (particularly the SNMP notification list) is not available, > > so there's no good way to tell a management station about it. > > > > I assume that most networks would want to use SNMP for this, > > but syslog would work as well. > > > > Mark's answer is just one answer that seem to support a YES answer > Any others? ... There has been some other work in the area of getting out notifications of "pre-OS" systems, e.g., http://www.dmtf.org/standards/documents/ASF/DSP0114.pdf However, this work does *not* address security, other than to discourage implementors from providing protocol-level security and to instead rely on "deployment schemes and firewalls" (!). Could information delivered via DHCP be used to accomplish a "kick start" of the secrets, similar to that in RFC 2786? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. SJC-1.3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San José, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 26 02:57:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29216; Thu, 26 Sep 2002 02:57:10 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8Q6wBv17728; Thu, 26 Sep 2002 02:58:11 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8Q6u7v17692 for ; Thu, 26 Sep 2002 02:56:07 -0400 Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA29188 for ; Thu, 26 Sep 2002 02:54:03 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (IDENT:mirapoint@mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g8Q6tKW4015988; Wed, 25 Sep 2002 23:55:20 -0700 (PDT) Received: from ANDREAWW2K (sjc-vpn1-827.cisco.com [10.21.99.59]) by mira-sjcm-2.cisco.com (Mirapoint Messaging Server MOS 3.1.0.66-GA) with SMTP id AAG66347; Wed, 25 Sep 2002 23:55:16 -0700 (PDT) From: "Andrea Westerinen" To: "Randy Presuhn" , , , Subject: RE: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt Date: Wed, 25 Sep 2002 23:55:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200209241844.LAA20555@dorothy.bmc.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit An updated version of ASF (2.0) is currently in DMTF company review that "adds security protocols to RMCP messages." So, the message below is not totally correct. This version of the spec will be available shortly after company review ends (Oct 15th). Andrea -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Randy Presuhn Sent: Tuesday, September 24, 2002 11:45 AM To: dhcwg@ietf.org; mibs@ops.ietf.org; snmpv3@lists.tislabs.com Subject: RE: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt Hi - > Message-ID: > From: "Wijnen, Bert (Bert)" > To: Mark Bakke > Cc: "'dhcwg@ietf.org'" , > "snmpv3@lists. tislabs. com (E-mail)" , > mibs@ops.ietf.org > Subject: RE: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt > Date: Tue, 24 Sep 2002 11:16:07 +0200 ... > > > First question would be: is it a generic problem that people face? > > Yes. There are increasingly more solutions that allow hosts, > > racks of servers, embedded devices, etc. to be booted from > > the network. When this fails, the host's normal configuration > > info (particularly the SNMP notification list) is not available, > > so there's no good way to tell a management station about it. > > > > I assume that most networks would want to use SNMP for this, > > but syslog would work as well. > > > > Mark's answer is just one answer that seem to support a YES answer > Any others? ... There has been some other work in the area of getting out notifications of "pre-OS" systems, e.g., http://www.dmtf.org/standards/documents/ASF/DSP0114.pdf However, this work does *not* address security, other than to discourage implementors from providing protocol-level security and to instead rely on "deployment schemes and firewalls" (!). Could information delivered via DHCP be used to accomplish a "kick start" of the secrets, similar to that in RFC 2786? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. SJC-1.3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San Josi, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 26 08:36:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04582; Thu, 26 Sep 2002 08:36:05 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8QCaqv02487; Thu, 26 Sep 2002 08:36:53 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8QCZfv02457 for ; Thu, 26 Sep 2002 08:35:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04233; Thu, 26 Sep 2002 08:33:44 -0400 (EDT) Message-Id: <200209261233.IAA04233@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org, ips@ece.cmu.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 26 Sep 2002 08:33:44 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-03.txt,.pdf Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Options for Internet Storage Name Service Author(s) : J. Tseng et al. Filename : draft-ietf-dhc-isnsoption-03.txt,.pdf Pages : 13 Date : 2002-9-25 This document describes the DHCP option to allow iSNS clients using DHCP to automatically discover the location of the iSNS server. iSNS provides discovery and management capabilities for iSCSI and Fibre Channel (FCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-isnsoption-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-isnsoption-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-25142204.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-25142204.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 26 09:40:47 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07315; Thu, 26 Sep 2002 09:40:47 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8QDfXv06647; Thu, 26 Sep 2002 09:41:33 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8QDWpv05591 for ; Thu, 26 Sep 2002 09:32:51 -0400 Received: from virtual4.dsldesigns.com (IDENT:root@78.40.83.216.dsldesigns.com [216.83.40.78]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06853 for ; Thu, 26 Sep 2002 09:30:55 -0400 (EDT) Received: from vanb.com (64.59.83.216.dsldesigns.com [216.83.59.64] (may be forged)) by virtual4.dsldesigns.com (8.11.1/8.11.1) with ESMTP id g8QDBgo06276 for ; Thu, 26 Sep 2002 06:11:42 -0700 Message-ID: <3D930C1D.D2F9CAB3@vanb.com> Date: Thu, 26 Sep 2002 06:31:10 -0700 From: Audrey Van Belleghem Reply-To: audrey@vanb.com Organization: Van Belleghem Corporation X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCPv6 for IPv6 interop testing Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit The Connectathon 2003 team is interested in learning how many companies would like to test DHCPv6 at the next interoperability testing event, Feb. 27-March 6, 2003 in San Jose, California. If you are interested in seeing this protocol added to the agenda, please send email to audrey@vanb.com. Thank you. Audrey Van Belleghem Connectathon Manager _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 30 06:54:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28198; Mon, 30 Sep 2002 06:54:36 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UAtLv29212; Mon, 30 Sep 2002 06:55:21 -0400 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g8UArov29165 for ; Mon, 30 Sep 2002 06:53:50 -0400 Received: from btmail.net.cn (host1.btamail.net.cn [202.106.196.71]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28171 for ; Mon, 30 Sep 2002 06:51:50 -0400 (EDT) Received: from btmail.net.cn([202.106.196.71]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jmc3d98609b; Mon, 30 Sep 2002 10:52:43 -0000 Received: from lists.tislabs.com([192.94.214.101]) by btamail.net.cn(JetMail 2.5.3.0) with SMTP id jm2f3d935ad2; Thu, 26 Sep 2002 16:52:07 -0000 Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA23836 Thu, 26 Sep 2002 09:04:49 -0400 (EDT) From: "Andrea Westerinen" To: "Randy Presuhn" , , , Subject: RE: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt Date: Wed, 25 Sep 2002 23:55:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <200209241844.LAA20555@dorothy.bmc.com> Precedence: bulk Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit An updated version of ASF (2.0) is currently in DMTF company review that "adds security protocols to RMCP messages." So, the message below is not totally correct. This version of the spec will be available shortly after company review ends (Oct 15th). Andrea -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Randy Presuhn Sent: Tuesday, September 24, 2002 11:45 AM To: dhcwg@ietf.org; mibs@ops.ietf.org; snmpv3@lists.tislabs.com Subject: RE: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt Hi - > Message-ID: > From: "Wijnen, Bert (Bert)" > To: Mark Bakke > Cc: "'dhcwg@ietf.org'" , > "snmpv3@lists. tislabs. com (E-mail)" , > mibs@ops.ietf.org > Subject: RE: [dhcwg] RE: draft-bakke-dhc-snmp-trap-00.txt > Date: Tue, 24 Sep 2002 11:16:07 +0200 ... > > > First question would be: is it a generic problem that people face? > > Yes. There are increasingly more solutions that allow hosts, > > racks of servers, embedded devices, etc. to be booted from > > the network. When this fails, the host's normal configuration > > info (particularly the SNMP notification list) is not available, > > so there's no good way to tell a management station about it. > > > > I assume that most networks would want to use SNMP for this, > > but syslog would work as well. > > > > Mark's answer is just one answer that seem to support a YES answer > Any others? ... There has been some other work in the area of getting out notifications of "pre-OS" systems, e.g., http://www.dmtf.org/standards/documents/ASF/DSP0114.pdf However, this work does *not* address security, other than to discourage implementors from providing protocol-level security and to instead rely on "deployment schemes and firewalls" (!). Could information delivered via DHCP be used to accomplish a "kick start" of the secrets, similar to that in RFC 2786? ------------------------------------------------------ Randy Presuhn BMC Software, Inc. SJC-1.3141 randy_presuhn@bmc.com 2141 North First Street Tel: +1 408 546-1006 San Josi, California 95131 USA ------------------------------------------------------ My opinions and BMC's are independent variables. ------------------------------------------------------ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg