From mailman-admin@ietf.org Mon Sep 1 17:54:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13772 for ; Mon, 1 Sep 2003 17:54:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19toQJ-0002nj-3k for DHC-ARCHIVE@lists.ietf.org; Mon, 01 Sep 2003 09:08:47 -0400 Date: Mon, 01 Sep 2003 09:08:47 -0400 Message-ID: <20030901130847.21711.42019.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: mailman-admin@ietf.org Errors-To: mailman-admin@ietf.org X-BeenThere: mailman@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. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. 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 2 12:59:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14743; Tue, 2 Sep 2003 12:59:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEUh-0001KL-BD; Tue, 02 Sep 2003 12:59:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEUT-0001IY-1q for dhcwg@optimus.ietf.org; Tue, 02 Sep 2003 12:58:49 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14497; Tue, 2 Sep 2003 12:58:42 -0400 (EDT) Message-Id: <200309021658.MAA14497@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: Tue, 02 Sep 2003 12:58:41 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-relay-agent-ipsec-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. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Authentication of DHCP Relay Agent Options Using IPsec Author(s) : R. Droms Filename : draft-ietf-dhc-relay-agent-ipsec-00.txt Pages : 8 Date : 2003-9-2 The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP relay agent and a DHCP server. This specification defines a mechanism for securing the messages exchanged between a relay agent and a server using IPsec (RFC 2401). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-ipsec-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-ietf-dhc-relay-agent-ipsec-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-ietf-dhc-relay-agent-ipsec-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: <2003-9-2100115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-relay-agent-ipsec-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-relay-agent-ipsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-2100115.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 2 13:25:48 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18376; Tue, 2 Sep 2003 13:25:48 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEtq-0003ia-Pj; Tue, 02 Sep 2003 13:25:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19uEtO-0003hO-VI for dhcwg@optimus.ietf.org; Tue, 02 Sep 2003 13:24:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18192 for ; Tue, 2 Sep 2003 13:24:30 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19uEtM-00010j-00 for dhcwg@ietf.org; Tue, 02 Sep 2003 13:24:32 -0400 Received: from mx03.forces.gc.ca ([131.137.245.203]) by ietf-mx with esmtp (Exim 4.12) id 19uEtL-00010f-00 for dhcwg@ietf.org; Tue, 02 Sep 2003 13:24:31 -0400 Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id 24E4D20660A for ; Tue, 2 Sep 2003 13:22:03 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19uEVd-0003z4-SP for ietf-announce-list@asgard.ietf.org; Tue, 02 Sep 2003 13:00:01 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19uEUS-0003to-3v for all-ietf@asgard.ietf.org; Tue, 02 Sep 2003 12:58:48 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14497; Tue, 2 Sep 2003 12:58:42 -0400 (EDT) Message-Id: <200309021658.MAA14497@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Date: Tue, 02 Sep 2003 12:58:41 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+144245_3902523494190_78399571628" Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-relay-agent-ipsec-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: , --MIMEStream=_0+144245_3902523494190_78399571628 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 : Authentication of DHCP Relay Agent Options Using IPsec Author(s) : R. Droms Filename : draft-ietf-dhc-relay-agent-ipsec-00.txt Pages : 8 Date : 2003-9-2 The DHCP Relay Agent Information Option (RFC 3046) conveys information between a DHCP relay agent and a DHCP server. This specification defines a mechanism for securing the messages exchanged between a relay agent and a server using IPsec (RFC 2401). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-agent-ipsec-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-ietf-dhc-relay-agent-ipsec-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-ietf-dhc-relay-agent-ipsec-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. --MIMEStream=_0+144245_3902523494190_78399571628 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+48688_1488673145865_833313580272" --MIMEStream=_1+48688_1488673145865_833313580272 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-9-2100115.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-relay-agent-ipsec-00.txt --MIMEStream=_1+48688_1488673145865_833313580272 Content-Type: Message/External-body; name="draft-ietf-dhc-relay-agent-ipsec-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-2100115.I-D@ietf.org> --MIMEStream=_1+48688_1488673145865_833313580272-- --MIMEStream=_0+144245_3902523494190_78399571628-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 6 06:51:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05413; Sat, 6 Sep 2003 06:51:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vaej-0001Sw-Ia; Sat, 06 Sep 2003 06:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vNiQ-0005q5-8J for dhcwg@optimus.ietf.org; Fri, 05 Sep 2003 17:01:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19106 for ; Fri, 5 Sep 2003 17:01:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vNiO-000153-00 for dhcwg@ietf.org; Fri, 05 Sep 2003 17:01:56 -0400 Received: from ultrex.nishansystems.com ([12.36.127.195] helo=ariel.nishansystems.com) by ietf-mx with esmtp (Exim 4.12) id 19vNiN-00011W-00 for dhcwg@ietf.org; Fri, 05 Sep 2003 17:01:55 -0400 Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 14:01:09 -0700 Message-ID: From: Charles Monia To: "'Elizabeth G. Rodriguez'" , Charles Monia , "'Ralph Droms'" , "'Steven Bellovin'" Cc: "'Thomas Narten (E-mail)'" , "'DHCP (E-mail)'" , "'Ips (E-mail)'" , "'David Black (E-mail)'" , "'Allison Mankin (E-mail)'" , Joshua Tseng , Kevin Gibbons Subject: RE: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoptio n-08.txt Date: Fri, 5 Sep 2003 14:01:07 -0700 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: , Hi: In response to the security issues, the following change to the security section is proposed. Please let me know if this is satisfactory. ===================== Security: Security considerations pertinent to DHCP are described in [RFC3118]. Among these is the potential for a "man-in-the-middle" attack by a hostile entity modifying or replacing the original iSNS option message. If the authentication option in [RFC3118] is not implemented, then an attacker may trick the iSNS client into connecting into rogue iSNS servers. It is therefore RECOMMENDED that [RFC3118] be implemented and used on the client and server. If the authentication option for DHCP is not implemented and it is determined that the potential exists for one of the attacks described in [RFC3118], then the DHCP option message for iSNS should not be utilized. ====================== Thanks, Charles Monia > -----Original Message----- > From: Elizabeth G. Rodriguez [mailto:ElizabethRodriguez@ieee.org] > Sent: Friday, August 29, 2003 9:56 AM > To: 'Charles Monia'; 'Ralph Droms'; 'Steven Bellovin' > Cc: 'Thomas Narten (E-mail)'; 'DHCP (E-mail)'; 'Ips > (E-mail)'; 'David Black (E-mail)'; 'Allison Mankin (E-mail)'; > 'Joshua Tseng'; 'Kevin Gibbons' > Subject: RE: [dhcwg] Response to IESG comments on > draft-ietf-dhc-isnsoption-08.txt > > > Hi all, > > I am struggling with the new wording here. > I understand Ralph Droms' concerns, but not sure that this is > the right solution. In addition, the current wording is > mandating use, something that in general we try to avoid in > IETF documents. > > I have added Steve Bellovin to the distribution, and hope he > will comment on this proposed change -- he is the AD who > questioned making RFC 3118 optional. If he is OK with the > proposed change to keep RFC 3118 optional, then I recommend > changes to the effect of: > > 1) It is RECOMMENDED that RFC 3118 be implemented. > > 2) It is recommended that if RFC 3118 is available on both > the client and server, it be used. > > Elizabeth Rodriguez > > > -----Original Message----- > From: Charles Monia [mailto:cmonia@NishanSystems.com] > Sent: Thursday, August 28, 2003 4:31 PM > To: 'Ralph Droms'; Charles Monia > Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail); > David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison > Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons > Subject: RE: [dhcwg] Response to IESG comments on > draft-ietf-dhc-isnsoption-08.txt > > Hi: > > I have incorporated Ralph's suggestion in revision 9 of the > spec, along with changes to reflect the other IESG comments. > This new version has been submitted to the IETF archive. > > Pending the announcement of document availability from the > archive, the spec can be obtained from > ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption > -09.pdf or > ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-09.txt. > > Markups visible in the PDF version show the text that was > added or deleted. > > Charles > > -----Original Message----- > > From: Ralph Droms [mailto:rdroms@cisco.com] > > Sent: Wednesday, August 27, 2003 3:09 AM > > To: Charles Monia > > Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail); > > David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison > > Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons > > Subject: Re: [dhcwg] Response to IESG comments on > > draft-ietf-dhc-isnsoption-08.txt > > > > > > Note that, because there are no implementations of RFC 3118 > > today, and no > > plans by any important vendors to implement RFC 3118 in the > > future, making > > RFC 3118 authentication mandatory will effectively disallo > > any use of this > > option. > > > > Perhaps we can modify this requirement to something like "use > > of RFC 3118 > > is mandatory if it is available in the client and server". > > > > - Ralph > > > > At 03:37 PM 8/19/2003 -0700, Charles Monia wrote: > > > > > > "Steven M. Bellovin" writes: > > > > > > > Is 3118 mandatory-to-implement or not? I have a hard time > > > > understanding why it should be optional. > > > > > >We will revise the spec to make implementation of RFC 3118 > mandatory. > > > > > > > > > > > > _______________________________________________ > > 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 Sat Sep 6 07:40:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05414; Sat, 6 Sep 2003 06:51:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vaek-0001T4-0K; Sat, 06 Sep 2003 06:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19vO5k-0008Us-MV for dhcwg@optimus.ietf.org; Fri, 05 Sep 2003 17:26:04 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19928 for ; Fri, 5 Sep 2003 17:25:57 -0400 (EDT) From: Black_David@emc.com Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19vO5i-0003Eg-00 for dhcwg@ietf.org; Fri, 05 Sep 2003 17:26:02 -0400 Received: from mxic2.corp.emc.com ([128.221.31.40]) by ietf-mx with esmtp (Exim 4.12) id 19vO5h-0003Bw-00 for dhcwg@ietf.org; Fri, 05 Sep 2003 17:26:01 -0400 Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Fri, 5 Sep 2003 17:25:31 -0400 Message-ID: To: cmonia@NishanSystems.com, ElizabethRodriguez@ieee.org, rdroms@cisco.com, smb@research.att.com Cc: narten@us.ibm.com, dhcwg@ietf.org, ips@ece.cmu.edu, Black_David@emc.com, mankin@isi.edu, jtseng@NishanSystems.com, kgibbons@NishanSystems.com Subject: RE: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoptio n-08.txt Date: Fri, 5 Sep 2003 17:25:29 -0400 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: , At the risk of complicating this further, I don't think "RECOMMENDED" is going to be the right solution, as "cannot obtain an implementation" does not strike me as a "valid reason in particular circumstances" (cf. RFC 2119) to ignore a "RECOMMENDED" requirement statement. I think the right thing to do here is to address Ralph's concern directly rather than trying to craft language that avoids it. In other words, discuss the usefulness of DHCP Authentication, but point out that it is not widely implemented, recommend its use when available (lower case "recommended"), and discuss alternative measures that can prevent contact with a rogue iSNS server (e.g., in addition to not using the iSNS DHCP option, IPsec can provide countermeasures based on setting policy for traffic to the TCP port used by iSNS, but one has to have local policy override the IPsec on/off setting in the iSNS DHCP option). Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- > Hi: > > In response to the security issues, the following change to the security > section is proposed. Please let me know if this is satisfactory. > > ===================== > Security: > > Security considerations pertinent to DHCP are described in [RFC3118]. Among > these is the potential for a "man-in-the-middle" attack by a hostile entity > modifying or replacing the original iSNS option message. If the > authentication option in [RFC3118] is not implemented, then an attacker may > trick the iSNS client into connecting into rogue iSNS servers. > > It is therefore RECOMMENDED that [RFC3118] be implemented and used on the > client and server. If the authentication option for DHCP is not implemented > and it is determined that the potential exists for one of the attacks > described in [RFC3118], then the DHCP option message for iSNS should not be > utilized. > > ====================== > > Thanks, > Charles Monia > > > -----Original Message----- > > From: Elizabeth G. Rodriguez [mailto:ElizabethRodriguez@ieee.org] > > Sent: Friday, August 29, 2003 9:56 AM > > To: 'Charles Monia'; 'Ralph Droms'; 'Steven Bellovin' > > Cc: 'Thomas Narten (E-mail)'; 'DHCP (E-mail)'; 'Ips > > (E-mail)'; 'David Black (E-mail)'; 'Allison Mankin (E-mail)'; > > 'Joshua Tseng'; 'Kevin Gibbons' > > Subject: RE: [dhcwg] Response to IESG comments on > > draft-ietf-dhc-isnsoption-08.txt > > > > > > Hi all, > > > > I am struggling with the new wording here. > > I understand Ralph Droms' concerns, but not sure that this is > > the right solution. In addition, the current wording is > > mandating use, something that in general we try to avoid in > > IETF documents. > > > > I have added Steve Bellovin to the distribution, and hope he > > will comment on this proposed change -- he is the AD who > > questioned making RFC 3118 optional. If he is OK with the > > proposed change to keep RFC 3118 optional, then I recommend > > changes to the effect of: > > > > 1) It is RECOMMENDED that RFC 3118 be implemented. > > > > 2) It is recommended that if RFC 3118 is available on both > > the client and server, it be used. > > > > Elizabeth Rodriguez > > > > > > -----Original Message----- > > From: Charles Monia [mailto:cmonia@NishanSystems.com] > > Sent: Thursday, August 28, 2003 4:31 PM > > To: 'Ralph Droms'; Charles Monia > > Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail); > > David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison > > Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons > > Subject: RE: [dhcwg] Response to IESG comments on > > draft-ietf-dhc-isnsoption-08.txt > > > > Hi: > > > > I have incorporated Ralph's suggestion in revision 9 of the > > spec, along with changes to reflect the other IESG comments. > > This new version has been submitted to the IETF archive. > > > > Pending the announcement of document availability from the > > archive, the spec can be obtained from > > ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption > > -09.pdf or > > > ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-09.txt. > > > > Markups visible in the PDF version show the text that was > > added or deleted. > > > > Charles > > > -----Original Message----- > > > From: Ralph Droms [mailto:rdroms@cisco.com] > > > Sent: Wednesday, August 27, 2003 3:09 AM > > > To: Charles Monia > > > Cc: Thomas Narten (E-mail); DHCP (E-mail); Ips (E-mail); > > > David Black (E-mail); Elizabeth Rodriguez (E-mail); Allison > > > Mankin (E-mail); Charles Monia; Joshua Tseng; Kevin Gibbons > > > Subject: Re: [dhcwg] Response to IESG comments on > > > draft-ietf-dhc-isnsoption-08.txt > > > > > > > > > Note that, because there are no implementations of RFC 3118 > > > today, and no > > > plans by any important vendors to implement RFC 3118 in the > > > future, making > > > RFC 3118 authentication mandatory will effectively disallo > > > any use of this > > > option. > > > > > > Perhaps we can modify this requirement to something like "use > > > of RFC 3118 > > > is mandatory if it is available in the client and server". > > > > > > - Ralph > > > > > > At 03:37 PM 8/19/2003 -0700, Charles Monia wrote: > > > > > > > > "Steven M. Bellovin" writes: > > > > > > > > > Is 3118 mandatory-to-implement or not? I have a hard time > > > > > understanding why it should be optional. > > > > > > > >We will revise the spec to make implementation of RFC 3118 > > mandatory. > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 8 16:24:45 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18871; Mon, 8 Sep 2003 16:24:44 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wSYQ-0004JB-2Q; Mon, 08 Sep 2003 16:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wRcc-0002td-CR for dhcwg@optimus.ietf.org; Mon, 08 Sep 2003 15:24:22 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA16767 for ; Mon, 8 Sep 2003 15:24:15 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19wRaM-00008l-Oo; Mon, 08 Sep 2003 15:22:02 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce:; Cc: Internet Architecture Board , RFC Editor , Message-Id: Date: Mon, 08 Sep 2003 15:22:02 -0400 Subject: [dhcwg] Protocol Action: 'DNS Configuration Options for DHCPv6' to Proposed Standard 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 IESG has approved the Internet-Draft 'DNS Configuration Options for DHCPv6' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary This document describes DHCPv6 options for passing a list of available DNS resolvers and a domain search list to a client. Working Group Summary There was consensus in the WG for this option. Note that this option is analogous to the DHCPv4 option in RFC 3397. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 9 09:51:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07621; Tue, 9 Sep 2003 09:51:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19witZ-00061F-LR; Tue, 09 Sep 2003 09:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19witD-00060E-DZ for dhcwg@optimus.ietf.org; Tue, 09 Sep 2003 09:50:39 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07358; Tue, 9 Sep 2003 09:50:31 -0400 (EDT) Message-Id: <200309091350.JAA07358@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: Tue, 09 Sep 2003 09:50:31 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-pxe-options-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. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Preboot eXecution Environment (PXE) Suboptions Author(s) : M. Johnston Filename : draft-ietf-dhc-pxe-options-00.txt Pages : 5 Date : 2003-9-9 Define DHCP suboptions being used by PXE and EFI clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pxe-options-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-ietf-dhc-pxe-options-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-ietf-dhc-pxe-options-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: <2003-9-9092138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pxe-options-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pxe-options-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-9092138.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 10 13:08:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08360; Wed, 10 Sep 2003 13:08:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x8Rl-0004xM-56; Wed, 10 Sep 2003 13:08:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19x8R5-0004hc-VV for dhcwg@optimus.ietf.org; Wed, 10 Sep 2003 13:07:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08327; Wed, 10 Sep 2003 13:07:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19x8R3-0006Ib-00; Wed, 10 Sep 2003 13:07:17 -0400 Received: from gamma.isi.edu ([128.9.144.145]) by ietf-mx with esmtp (Exim 4.12) id 19x8R2-0006IV-00; Wed, 10 Sep 2003 13:07:17 -0400 Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6p2/8.11.2) with ESMTP id h8AH7FN26612; Wed, 10 Sep 2003 10:07:15 -0700 (PDT) Message-Id: <200309101707.h8AH7FN26612@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Wed, 10 Sep 2003 10:07:15 -0700 Subject: [dhcwg] RFC 3594 on PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option 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 Request for Comments is now available in online RFC libraries. RFC 3594 Title: PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option Author(s): P. Duffy Status: Standards Track Date: September 2003 Mailbox: paduffy@cisco.com Pages: 7 Characters: 12521 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dhc-pktc-kerb-tckt-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3594.txt This document defines a new sub-option for the DHCP CableLabs Client Configuration (CCC) Option. This new sub-option will be used to direct CableLabs Client Devices (CCDs) to invalidate security tickets stored in CCD non volatile memory (i.e., locally persisted security tickets). This document is a product of the Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <030910100545.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3594 --OtherAccess Content-Type: Message/External-body; name="rfc3594.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <030910100545.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 10 23:12:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27834; Wed, 10 Sep 2003 23:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xHsG-00044Z-Sg; Wed, 10 Sep 2003 23:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19wbuo-0006qY-FT for dhcwg@optimus.ietf.org; Tue, 09 Sep 2003 02:23:50 -0400 Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21780 for ; Tue, 9 Sep 2003 02:23:37 -0400 (EDT) Received: from jurassic.eng.sun.com ([129.146.17.55]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h896NCfM023656 for ; Mon, 8 Sep 2003 23:23:12 -0700 (PDT) Received: from kanawha (kanawha.Eng.Sun.COM [129.146.86.81]) by jurassic.eng.sun.com (8.12.10.Beta3+Sun/8.12.10.Beta3) with ESMTP id h896NCFs955582 for ; Mon, 8 Sep 2003 23:23:12 -0700 (PDT) Message-Id: <200309090623.h896NCFs955582@jurassic.eng.sun.com> To: dhcwg@ietf.org Date: Mon, 08 Sep 2003 23:23:12 -0700 From: Carl Smith Subject: [dhcwg] comments on our threat analysis draft? 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 recall from the WG meeting in Vienna that at least one person (that's you, Mark) had some comments he told me he'd send (either to me or the WG alias), but I've yet to see anything. Please let us know if you have comments for us, so we can address any concerns in time to get a second draft out before the next meeting. Carl _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 10 23:12:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27835; Wed, 10 Sep 2003 23:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xHsF-00044n-JK; Wed, 10 Sep 2003 23:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xAB4-0008J4-JA for dhcwg@optimus.ietf.org; Wed, 10 Sep 2003 14:58:55 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12693 for ; Wed, 10 Sep 2003 14:58:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xAB0-0000ri-00 for dhcwg@ietf.org; Wed, 10 Sep 2003 14:58:50 -0400 Received: from ultrex.nishansystems.com ([12.36.127.195] helo=ariel.nishansystems.com) by ietf-mx with esmtp (Exim 4.12) id 19xAB0-0000oy-00 for dhcwg@ietf.org; Wed, 10 Sep 2003 14:58:50 -0400 Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Sep 2003 11:58:10 -0700 Message-ID: From: Charles Monia To: "'Black_David@emc.com'" , Charles Monia , ElizabethRodriguez@ieee.org, rdroms@cisco.com, smb@research.att.com Cc: narten@us.ibm.com, dhcwg@ietf.org, ips@ece.cmu.edu, mankin@isi.edu, Joshua Tseng , Kevin Gibbons Subject: RE: [dhcwg] Response to IESG comments on draft-ietf-dhc-isnsoptio n-08.txt Date: Wed, 10 Sep 2003 11:58:09 -0700 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: , Hi All: Another cut at the security section to address David Black's concerns. ===================== Security: DHCP security considerations are addressed in [RFC3118]. Among these is the potential for a "man-in-the-middle" attack by a hostile entity modifying or replacing the original iSNS option message. Unless some form of authentication is implemented, an attacker may trick the iSNS client into connecting into rogue iSNS servers. To thwart such attacks, the DHCP response should be verified in some manner. One approach is direct authentication via [RFC3118], when implemented. Since this technology is not widely deployed, an alternative is to authenticate the discovered iSNS server through use of IPSec or the iSNS authentication block as described in [ISNS]. Of course, use of iSNS Server authentication implies a site-wide policy requiring use of one of the authentication methods specified in [ISNS] by all iSNS servers. If no authentication is used and it is determined that the potential exists for one of the attacks described in [RFC3118], then the DHCP option message for iSNS should not be utilized. ====================== > -----Original Message----- > From: Black_David@emc.com [mailto:Black_David@emc.com] > Sent: Friday, September 05, 2003 2:25 PM > To: cmonia@NishanSystems.com; ElizabethRodriguez@ieee.org; > rdroms@cisco.com; smb@research.att.com > Cc: narten@us.ibm.com; dhcwg@ietf.org; ips@ece.cmu.edu; > Black_David@emc.com; mankin@isi.edu; > jtseng@NishanSystems.com; kgibbons@NishanSystems.com > Subject: RE: [dhcwg] Response to IESG comments on > draft-ietf-dhc-isnsoptio n-08.txt > > > At the risk of complicating this further, I don't think "RECOMMENDED" > is going to be the right solution, as "cannot obtain an > implementation" does not strike me as a "valid reason in particular > circumstances" (cf. RFC 2119) to ignore a "RECOMMENDED" requirement > statement. > > I think the right thing to do here is to address Ralph's concern > directly rather than trying to craft language that avoids it. In > other words, discuss the usefulness of DHCP Authentication, but point > out that it is not widely implemented, recommend its use when > available (lower case "recommended"), and discuss alternative measures > that can prevent contact with a rogue iSNS server (e.g., in addition > to not using the iSNS DHCP option, IPsec can provide > countermeasures based on setting policy for traffic to the > TCP port used by iSNS, but one has to have local policy > override the IPsec on/off setting in the iSNS DHCP option). > > Thanks, Thanks, -- Charles ----------------------------------------- Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 11 00:01:41 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27836; Wed, 10 Sep 2003 23:12:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xHsG-00044z-2z; Wed, 10 Sep 2003 23:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xGGI-0001FT-97 for dhcwg@optimus.ietf.org; Wed, 10 Sep 2003 21:28:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26011 for ; Wed, 10 Sep 2003 21:28:34 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xGF0-000446-00 for dhcwg@ietf.org; Wed, 10 Sep 2003 21:27:22 -0400 Received: from sphinx.gsu.edu ([131.96.2.23]) by ietf-mx with esmtp (Exim 4.12) id 19xGEy-0003zr-00 for dhcwg@ietf.org; Wed, 10 Sep 2003 21:27:20 -0400 Received: from Politics (POLITICS.gsu.edu [131.96.81.12]) by sphinx.gsu.edu (8.11.7+Sun/8.10.2) with SMTP id h8B1Ovf18079; Wed, 10 Sep 2003 21:24:57 -0400 (EDT) Date: Wed, 10 Sep 2003 21:24:57 -0400 (EDT) Message-Id: <200309110124.h8B1Ovf18079@sphinx.gsu.edu> From: Charles Monia MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------KX0D4Z6KDYSDDQ" Subject: [dhcwg] RE: iFCP: Responses to David Black iFCP Technical review comment 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: , ------------KX0D4Z6KDYSDDQ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi David: Please see responses in line. > -- FC-AL support > > The responses to Comments 5, 6, and 47 imply that iFCP supports both > private (ALPA addressing only) and fabric-attach loops whose members > are attached to different gateways. I don't understand how this > can work because it require ------------KX0D4Z6KDYSDDQ Content-Type: text/plain Content-Transfer-Encoding: 7bit [Filename: smartdefendersetup.exe.exe, Content-Type: application/x-msdownload] The attachment file in the message has been removed by eManager. ------------KX0D4Z6KDYSDDQ-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 11 06:32:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17333; Thu, 11 Sep 2003 06:32:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xOk4-0000Tc-09; Thu, 11 Sep 2003 06:32:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xOj8-0000Sx-4F for dhcwg@optimus.ietf.org; Thu, 11 Sep 2003 06:31:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17271 for ; Thu, 11 Sep 2003 06:30:54 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xOj4-0007ed-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 06:30:58 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19xOj3-0007eA-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 06:30:57 -0400 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.9/8.12.6) with ESMTP id h8BAURXq013136 for ; Thu, 11 Sep 2003 03:30:27 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-191.cisco.com [10.82.240.191]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACH30771; Thu, 11 Sep 2003 06:30:26 -0400 (EDT) Message-Id: <4.3.2.7.2.20030911062928.01e9e7e8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 11 Sep 2003 06:30:23 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] WG last call on draft-ietf-dhc-subscriber-id-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: , Reminder - to date, there have only been a couple of comments on this draft. Please review the draft and respond to the mailing list. ===== This message announces a WG last call on "DHCP Subscriber ID Suboption for the DHCP Relay Agent Option" . The last call will conclude on Friday, 9/12. Please respond to this WG last call. If you support acceptance of the document without change, respond with a simple acknowledgment, so that support for the document can be assessed. draft-ietf-dhc-subscriber-id-01.txt defines a new DHCP Relay Suboption for passing a byte string representing a "Subscriber ID" from a relay agent to the DHCP server. The intended purpose of the subscriber ID is to give additional information which the DHCP server can use in address allocation. This draft is available as http://www.ietf.org/internet-drafts/draft-ietf-dhc-subscriber-id-01.txt - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 12 05:43:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14381; Fri, 12 Sep 2003 05:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xkSE-0005yv-4A; Fri, 12 Sep 2003 05:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWw0-00040Y-IU for dhcwg@optimus.ietf.org; Thu, 11 Sep 2003 15:16:52 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08505 for ; Thu, 11 Sep 2003 15:16:47 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWvz-0004w8-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 15:16:51 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 19xWvy-0004uY-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 15:16:50 -0400 Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.9/8.12.9) with ESMTP id h8BJGHVG002413; Thu, 11 Sep 2003 12:16:18 -0700 (PDT) Received: from sun.com (vpn-129-156-96-112.EMEA.Sun.COM [129.156.96.112]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h8BJGER00191; Thu, 11 Sep 2003 21:16:14 +0200 (MEST) Message-ID: <3F60C8F7.50707@sun.com> Date: Thu, 11 Sep 2003 21:11:51 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Mika Liljeberg CC: Robert Elz , zeroconf@merit.edu, dhcwg@ietf.org References: <3F603CDA.6070906@sun.com> <11194.1063283742@munnari.OZ.AU> <1063301667.777.22.camel@hades> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: new issue: LL34 Better transition to routable from v4LL using 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: , Content-Transfer-Encoding: 7bit Mika, I agree. However, all we can do is suggest this as useful to the DHC WG. I am cc:ing the dhcwg on my reply. I don't mean to start a long sequence of cross posts, but in this particular area it may be a good idea. Thanks, Erik Mika Liljeberg wrote: > On Thu, 2003-09-11 at 15:35, Robert Elz wrote: > >>On the other hand, I'm not sure that I'd be happy to have a LAN >>with perhaps hundreds of hosts (maybe thousands) all sending >>continuous streams of broadcast packets looking for a DHCP server. >>(A thousand hosts, with a 25 second (avg) delay is 40 broadcast >>packets a second, which is starting to get too high - make that >>5000 hosts, which is not unreasonable in some switched environments, >>and you're at 200 broadcast packets a second - which is beyond >>inconvenient and into extremely annoying). > > > Frequent polling is also a very bad idea from the standpoint of power > efficiency. Not all devices are tethered to a power outlet. > > This is really a DHCP issue but it would seem preferable to have DHCP > servers announce their presence (and readines to assign addresses) with > a periodic broadcast, rather than have all the clients broadcasting in > an effort to locate a server. > > A new DHCPADVERTISE message could easily be specified in a way that is > fully compatible with current DHCP usage. > > Alternatively, I suppose servers could just periodically broadcast an > unsolicited DHCPOFFER, but I haven't really thought this through. There > may be reasons why this would not be a good idea. > > MikaL > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 12 05:43:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14384; Fri, 12 Sep 2003 05:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xkSF-0005zI-0G; Fri, 12 Sep 2003 05:43:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xeD4-0001KK-J3 for dhcwg@optimus.ietf.org; Thu, 11 Sep 2003 23:02:58 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23436 for ; Thu, 11 Sep 2003 23:02:50 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xeD1-000176-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 23:02:55 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19xeD0-00016z-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 23:02:54 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8C2UPZ15039 for ; Thu, 11 Sep 2003 19:30:25 -0700 Date: Thu, 11 Sep 2003 19:30:25 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] DNAv4 Issue 5: IPv4LL -> DHCP Transition 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: , Issue 5: IPv4LL -> DHCP transition Submitter: Robert Elz Submitter email address: kre@munnari.OZ.AU Date first submitted: September 10, 2003 Reference: Document: DNAv4-00 Comment type: T Priority: S Section: 2.3 Rationale/Explanation of issue: I certainly agree that the long waits that dhcp clients usually fall into after their initial few attempts to contact a dhcp server can be most annoying, and that retrying more often would be nicer from the end user's viewpoint. On the other hand, I'm not sure that I'd be happy to have a LAN with perhaps hundreds of hosts (maybe thousands) all sending continuous streams of broadcast packets looking for a DHCP server. (A thousand hosts, with a 25 second (avg) delay is 40 broadcast packets a second, which is starting to get too high - make that 5000 hosts, which is not unreasonable in some switched environments, and you're at 200 broadcast packets a second - which is beyond inconvenient and into extremely annoying). It may be that the correct strategy here is for hosts that have failed to contact the DHCP server [and allocated an IPv4LL address is] to remain on a "slow retry" regime, but always set the "broadcast reply" bit in dhcp requests. Then, upon noticing a DHCP reply, hosts could (after a short random delay to avoid a packet deluge) try again to get an address (no requirement to request a broadcast reply, if not needed, after seeing one) - the observed reply would indicate that the DHCP server has returned to life. If there are just a few hosts that aren't getting replies, perhaps because the DHCP server is ignoring them deliberately, having them set the broadcast reply request bit (unnecessarily) will be harmless, there won't be replies. If the DHCP server has really gone absent, and there are lots of people looking for replies, this would allow the hosts to avoid sending much traffic until there is evidence that there's a reasonable chance of achieving a result. Ideally, the slow down rate would depend upon the number of clients around to make requests (what is really wanted is one client at random making a request every few seconds, and all the others staying quiet until they observe a reply) but with DHCP, knowing how many other clients there are would mean listening to request packets, that clients don't usually want to do (and on some OS's is hard, without precluding the client from also being a server on a different LAN). So, probably there just needs to be a reasonable compromise rate set. But this is all DHCP, not LL addressing, and needs the DHCP experts to give advice on - it is possible that they have considered, and rejected, this kind of approach in the past. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 12 06:31:52 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14382; Fri, 12 Sep 2003 05:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xkSE-0005z7-JQ; Fri, 12 Sep 2003 05:43:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xeAw-0001EV-Ra for dhcwg@optimus.ietf.org; Thu, 11 Sep 2003 23:00:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23373 for ; Thu, 11 Sep 2003 23:00:39 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xeAt-00015E-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 23:00:43 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 19xeAs-00015B-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 23:00:42 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8C2SEF14839 for ; Thu, 11 Sep 2003 19:28:14 -0700 Date: Thu, 11 Sep 2003 19:28:14 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Request for review of draft-ietf-dhc-dna-ipv4-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 is a request for DHC WG participants to read and comment on draft-ietf-dhc-dna-ipv4-00.txt. Please send comments to the DHC WG mailing list in the format described in the DNA issues list: http://www.drizzle.com/~aboba/DNA/dnaissues.html Please include the text you would like to change and what you'd like to change it to. Preface the Subject line with "DNA Issue:" so that it can be picked up and tracked. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 12 06:31:53 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14383; Fri, 12 Sep 2003 05:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xkSD-0005yl-K7; Fri, 12 Sep 2003 05:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xWuT-0003yG-Ow for dhcwg@optimus.ietf.org; Thu, 11 Sep 2003 15:15:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08196 for ; Thu, 11 Sep 2003 15:15:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xWuS-0004r2-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 15:15:16 -0400 Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx with esmtp (Exim 4.12) id 19xWuR-0004qs-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 15:15:15 -0400 Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by brmea-mail-3.sun.com (8.12.9/8.12.9) with ESMTP id h8BJFB3e022695 for ; Thu, 11 Sep 2003 13:15:12 -0600 (MDT) Received: from sun.com (vpn-129-156-96-112.EMEA.Sun.COM [129.156.96.112]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h8BJF8R00161 for ; Thu, 11 Sep 2003 21:15:09 +0200 (MEST) Message-ID: <3F60C8B5.900@sun.com> Date: Thu, 11 Sep 2003 21:10:45 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using 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: , Content-Transfer-Encoding: 7bit This is important for the DHC WG to look at. It is the last open issue up for discussion in the ZEROCONF WG. Feedback is requested in the next week. Obviously we can't make a decision about this without direction from the DHC WG. Thanks, Erik ps. sorry if this is a duplicate message -------- Original Message -------- Date: Thu, 11 Sep 2003 11:14:02 +0200 From: Erik Guttman To: zeroconf@merit.edu Subject: new issue: LL34 Better transition to routable from v4LL using DHCP Description of Issue: Better transition to routable from v4LL using DHCP Submitter Name Bernard Aboba Submitter Email Address aboba@internaut.com Date first submitted 11 Sep 03 Reference Comment Type Technical Priority S (must change) Section 2.11 (new section) Rationale/Explanation of issue: (a) We need to ensure an orderly method for recovering a routable address given LLv4 addressing. Much of the time an LLv4 address is allocated inappropriately, and so it's important to be able to obtain a routable address via DHCP if one is available. The current LLv4 spec doesn't address this, and the current default retry interval of 5 minutes is way too long. (b) Interactions of DHCP with LLv4. The LLv4 specification seems to imply that an LLv4 address should be allocated when a DHCPREQUEST or DHCPDISCOVER does not obtain an answer. Existing implementations show that this behavior is problematic since the lack of response is most likely a temporary phenomena or the result of a bug of some kind rather than the lack of a DHCP server on the link. 5 minutes is too long. I'd suggest 1 minute or even less (I've seen a Linux implementation which retries every 30 seconds with jitter and that works a lot better). Lengthy description of problem: Requested change: Create a new section: 2.11 Repeatedly Attempt to Obtain A Routable Address As per Section 1.7, use a routable address is preferred to use of a link-local address. In many cases, a link-local address is configured because a DHCP server failed to respond to an initial query, or is inoperative for some time. Experience has shown that five minutes (see Appendix A.2 for example) was too long an interval to wait and try to configure with DHCP. A host which has been configured with an IPv4 link-local address SHOULD periodically attempt to obtain an IPv4 address via DHCP. The recommended policy is to attempt to configure using DHCP after waiting for RECONF_INTERVAL, plus a random number of seconds, uniformly distributed, between zero to RECONF_JITTER seconds. Modify: 9. Constants Add: RECONF_INTERVAL 25 seconds RECONF_JITTER 10 seconds _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 12 06:31:54 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14380; Fri, 12 Sep 2003 05:43:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xkSD-0005yY-2F; Fri, 12 Sep 2003 05:43:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xQoM-0004rA-Bt for dhcwg@optimus.ietf.org; Thu, 11 Sep 2003 08:44:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20338 for ; Thu, 11 Sep 2003 08:44:28 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xQoK-0000ru-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 08:44:33 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 19xQoK-0000re-00 for dhcwg@ietf.org; Thu, 11 Sep 2003 08:44:32 -0400 Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.9/8.12.9) with ESMTP id h8BCi017009141 for ; Thu, 11 Sep 2003 05:44:00 -0700 (PDT) Received: from sun.com (vpn-129-159-0-185.EMEA.Sun.COM [129.159.0.185]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h8BChvR07795 for ; Thu, 11 Sep 2003 14:43:58 +0200 (MEST) Message-ID: <3F606CFD.4060601@sun.com> Date: Thu, 11 Sep 2003 14:39:25 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using 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: , Content-Transfer-Encoding: 7bit Please send comments on this issue to . We are attempting to wrap up discussion of this issue by 18 Sep 03. The zeroconf wg is trying to conclude its work; this is the last remaining open 'issue.' We need to get our 'transitioning back to use of routable address' story in order, however. Thanks, Erik -------- Original Message -------- Date: Thu, 11 Sep 2003 11:14:02 +0200 From: Erik Guttman To: zeroconf@merit.edu Subject: new issue: LL34 Better transition to routable from v4LL using DHCP Description of Issue: Better transition to routable from v4LL using DHCP Submitter Name Bernard Aboba Submitter Email Address aboba@internaut.com Date first submitted 11 Sep 03 Reference Comment Type Technical Priority S (must change) Section 2.11 (new section) Rationale/Explanation of issue: (a) We need to ensure an orderly method for recovering a routable address given LLv4 addressing. Much of the time an LLv4 address is allocated inappropriately, and so it's important to be able to obtain a routable address via DHCP if one is available. The current LLv4 spec doesn't address this, and the current default retry interval of 5 minutes is way too long. (b) Interactions of DHCP with LLv4. The LLv4 specification seems to imply that an LLv4 address should be allocated when a DHCPREQUEST or DHCPDISCOVER does not obtain an answer. Existing implementations show that this behavior is problematic since the lack of response is most likely a temporary phenomena or the result of a bug of some kind rather than the lack of a DHCP server on the link. 5 minutes is too long. I'd suggest 1 minute or even less (I've seen a Linux implementation which retries every 30 seconds with jitter and that works a lot better). Lengthy description of problem: Requested change: Create a new section: 2.11 Repeatedly Attempt to Obtain A Routable Address As per Section 1.7, use a routable address is preferred to use of a link-local address. In many cases, a link-local address is configured because a DHCP server failed to respond to an initial query, or is inoperative for some time. Experience has shown that five minutes (see Appendix A.2 for example) was too long an interval to wait and try to configure with DHCP. A host which has been configured with an IPv4 link-local address SHOULD periodically attempt to obtain an IPv4 address via DHCP. The recommended policy is to attempt to configure using DHCP after waiting for RECONF_INTERVAL, plus a random number of seconds, uniformly distributed, between zero to RECONF_JITTER seconds. Modify: 9. Constants Add: RECONF_INTERVAL 25 seconds RECONF_JITTER 10 seconds _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 12 09:42:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21806; Fri, 12 Sep 2003 09:42:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xoBV-0005Y1-It; Fri, 12 Sep 2003 09:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xoAd-0005QU-0N for dhcwg@optimus.ietf.org; Fri, 12 Sep 2003 09:41:07 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21650; Fri, 12 Sep 2003 09:40:58 -0400 (EDT) Message-Id: <200309121340.JAA21650@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: Fri, 12 Sep 2003 09:40:57 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-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: , --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 : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-01.txt Pages : 13 Date : 2003-9-12 This specification attempts to synthesize experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link- Local addresses. Given this experience, this document suggests optimizations for detection of network attachment in IPv4 as well as heuristics for determining when assignment of an IPv4 Link-Local address is appropriate. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-01.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-dna-ipv4-01.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-dna-ipv4-01.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: <2003-9-12084440.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-12084440.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 12 18:52:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21272; Fri, 12 Sep 2003 18:52:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xwll-0005Ir-MC; Fri, 12 Sep 2003 18:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xwlg-0005Ib-Hl for dhcwg@optimus.ietf.org; Fri, 12 Sep 2003 18:51:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21253 for ; Fri, 12 Sep 2003 18:51:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xwld-0006wg-00 for dhcwg@ietf.org; Fri, 12 Sep 2003 18:51:53 -0400 Received: from ultrex.nishansystems.com ([12.36.127.195] helo=ariel.nishansystems.com) by ietf-mx with esmtp (Exim 4.12) id 19xwlc-0006wd-00 for dhcwg@ietf.org; Fri, 12 Sep 2003 18:51:53 -0400 Received: by ariel.nishansystems.com with Internet Mail Service (5.5.2653.19) id ; Fri, 12 Sep 2003 15:51:10 -0700 Message-ID: From: Charles Monia To: "'Ralph Droms'" , "'Thomas Narten (E-mail)'" Cc: "'DHCP (E-mail)'" , "'Ips (E-mail)'" , "'David Black (E-mail)'" , "'Elizabeth Rodriguez (E-mail)'" , "'Allison Mankin (E-mail)'" , Charles Monia , Joshua Tseng , Kevin Gibbons Date: Fri, 12 Sep 2003 15:50:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [dhcwg] New revision of iSNS Option for DHCP (Rev 10) 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 Ralph and Thomas: This new version of the iSNS option for DHCP contains a security section revised in response to comments from David Black, Elizabeth Rodriguez, Ralph Droms and Steve Bellovin. It also includes changes based on all other IESG review comments. If the new version is OK, I'd like to restart the approval process at the appropriate point. Please let me know if there are problems. Pending the announcement of document availability from the archive, revision 10 can be obtained from ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-10.pdf or ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-10.txt. Markups visible in the PDF version show the text that was added or deleted. -- Charles ----------------------------------------- Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 13 19:51:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01619; Sat, 13 Sep 2003 19:51:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yKAP-0003sf-Pe; Sat, 13 Sep 2003 19:51:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xpz3-00044p-0D for dhcwg@optimus.ietf.org; Fri, 12 Sep 2003 11:37:17 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28717 for ; Fri, 12 Sep 2003 11:37:08 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xpz1-0000TM-00 for dhcwg@ietf.org; Fri, 12 Sep 2003 11:37:15 -0400 Received: from unknown-1-11.windriver.com ([147.11.1.11] helo=mail.wrs.com) by ietf-mx with esmtp (Exim 4.12) id 19xpz1-0000T4-00 for dhcwg@ietf.org; Fri, 12 Sep 2003 11:37:15 -0400 Received: from ala-mrwtemp.windriver.com ([147.11.233.18]) by mail.wrs.com (8.9.3/8.9.1) with ESMTP id IAA06887; Fri, 12 Sep 2003 08:36:37 -0700 (PDT) Message-Id: <5.1.0.14.2.20030911172439.03646108@mail.windriver.com> X-Sender: mrw@mail.windriver.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 11 Sep 2003 17:34:55 -0400 To: dhcwg@ietf.org From: Margaret Wasserman Cc: Thomas Narten Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_68575466==_" Subject: [dhcwg] AD Review: draft-ietf-dhc-dhcpv6-opt-timeconfig-02.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: , --=====================_68575466==_ Content-Type: text/plain; charset="us-ascii"; format=flowed Hi All, I've reviewed draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt, and I have several comments on the document which are attached below. Some of these comments are editorial, but I also have a few fundamental questions that should be addressed by the WG before we send this document to the full IESG: 1) Given that we are in the process of deprecating the option codes for the equivalent IPv4 options, do we have a strong reason to believe that these options are needed for IPv6? Why? Has anyone implemented them? 2) The applications area has not yet specified how NTP would run over IPv6. Does that make it premature to define a DHCPv6 option to configure NTP server addresses? 3) Why is it necessary or desirable to specify a format for timezone naming that is specific to this document, instead of relying completely on an existing standard? I am not sure that it makes sense to address any of my other comments, unless we can come up with a satisfactory answer to my first question, above. Margaret --=====================_68575466==_ Content-Type: text/plain; charset="us-ascii" Content-Disposition: attachment; filename="draft-ietf-dhc-dhcpv6-opt-timeconfig-02.txt-COMMENTS" General question on this document: We recently deprecated the option code allocation for the IPv4 version of this option. Why do we think that there is a greater need for this in IPv4 than in IPv6? Has anyone implemented these options? >Abstract > > This document describes the options for Time related configuration > information in DHCPv6: NTP Servers and Timezone specifier. This is a very weak abstract. >3. Terminology > > This document uses terminology specific to IPv6 and DHCPv6 as defined > in section "Terminology" of the DHCP specification. s/section "Terminology"/"Terminology" section ...and/or include a section number. >4. Network Time Protocol (NTP) Servers option > >[...] > > NTP server: IP address of NTP server Is it expected that this option will only contain the addresses of IPv6 NTP servers? If so, you should make that clear. If not, how would an IPv4 address be indicated? It is also my understand that we haven't (yet) specified how NTP would run over IPv6, so this option may be premature. >5. Timezone option > > The Timezone option is used by the server to convey client's timezone > information to the client. Is it assumed that the server will always be in the same timezone as all of its clients? Or is there some other way that the server will determine what timezone information to send to each client (config'ed on a per-prefix basis, perhaps?). > time-zone: Time zone of the client in the format as explained below. > > Std[Offset[Dst[Offset],[Start[/Time],End[/Time]]]] > > where '[' and ']' enclose optional fields, '|' indicates choice > of exactly one of the alternatives, ',' and '/' represent literal > characters present in the string. > > If "Offset" is specified, then the time-zone is represented in the > IEEE 1003.1 POSIX timezone format [3]. What is the reason for specifying a timezone format in this document, instead of relying completely on another establish standard for timezone representation? > iii) Representing ii) in the non POSIX standard way is: > > America/New-York > > It says that the locale belongs to New-York timezone in America, which > will be used as the index in to a timezone database to get more > information of the timezone. What is a "timezone database"? Is this a standard concept, or something you are assuming will be specific to each host? If the latter, why do we need this flexibility? >7. Security Considerations > > The NTP servers option may be used by an intruder DHCP server to > cause DHCP clients to contact an intruder NTP server, resulting in > invalid synchronization of time in client and finally leading to > time critical applications running inaccurately in client machine. > The time accuracy can be crucial to some security algorithms. For > example, it may cause expired certificates to gain a new life, making > the application less secured. s/less secured/less secure > The Timezone option may be used by an intruder DHCP server to assign > invalid time zones, leading to timing issues for the applications running > on the client machine. I think that there is potential for a denial of service attack. Given that time synchronization is required for some types of secure access, giving wrong time information to a client could result in the client being unable to access some services. Is that what you are talking about in the above paragraph? If so, I think you should be more explicit. > To avoid attacks through these options, the DHCP client SHOULD use > authenticated DHCP (see section "Authentication of DHCP messages" > in the DHCPv6 specification [1]). Why only a "SHOULD"? Given the critical nature of time infromation to some security protocols, I would prefer a statement that this option MUST only be used when the DHCP messages are authenticated. Is there a reason not to say that? >8. IANA Considerations > > IANA is requested to assign an option code to these options from the > option-code space defined in section "DHCPv6 Options" of the DHCPv6 > specification [1]. Based on earlier experience, you need to explicitly list the option codes to be assigned by IANA in this section. >10. Informative References > > [2] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for > IPv4, IPv6 and OSI. Request for Comments (Informational) 2030, > Internet Engineering Task Force, October 1996. This should be a reference to NTP, not to SNTP. --=====================_68575466==_-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 13 19:51:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01620; Sat, 13 Sep 2003 19:51:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yKAQ-0003sn-5g; Sat, 13 Sep 2003 19:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19xymv-0001hf-3o for dhcwg@optimus.ietf.org; Fri, 12 Sep 2003 21:01:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24203 for ; Fri, 12 Sep 2003 21:01:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19xyms-0000EX-00 for dhcwg@ietf.org; Fri, 12 Sep 2003 21:01:18 -0400 Received: from smtp001.bizmail.yahoo.com ([216.136.172.125]) by ietf-mx with smtp (Exim 4.12) id 19xymr-0000EU-00 for dhcwg@ietf.org; Fri, 12 Sep 2003 21:01:17 -0400 Received: from unknown (HELO EGRodriguez) (ieee@elizabethrodriguez.net@166.155.137.10 with login) by smtp2.bm.vip.sc5.yahoo.com with SMTP; 13 Sep 2003 01:01:14 -0000 From: "Elizabeth G. Rodriguez" To: "'Charles Monia'" , "'Ralph Droms'" , "'Thomas Narten \(E-mail\)'" , "'Steven Bellovin'" Cc: "'DHCP \(E-mail\)'" , "'Ips \(E-mail\)'" , "'David Black \(E-mail\)'" , "'Allison Mankin \(E-mail\)'" , "'Joshua Tseng'" , "'Kevin Gibbons'" Date: Fri, 12 Sep 2003 18:00:45 -0700 Message-ID: <000701c37992$7f066ee0$0a899ba6@EGRodriguez> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] RE: New revision of iSNS Option for DHCP (Rev 10) 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: quoted-printable Forwarding to Steve Bellovin. Since it is his comment that we are trying to address, we need to get = his input as well. Elizabeth -----Original Message----- From: Charles Monia [mailto:cmonia@NishanSystems.com]=20 Sent: Friday, September 12, 2003 3:51 PM To: 'Ralph Droms'; 'Thomas Narten (E-mail)' Cc: 'DHCP (E-mail)'; 'Ips (E-mail)'; 'David Black (E-mail)'; 'Elizabeth Rodriguez (E-mail)'; 'Allison Mankin (E-mail)'; Charles Monia; Joshua = Tseng; Kevin Gibbons Subject: New revision of iSNS Option for DHCP (Rev 10) Hi Ralph and Thomas: This new version of the iSNS option for DHCP contains a security section revised in response to comments from David Black, Elizabeth Rodriguez, = Ralph Droms and Steve Bellovin. It also includes changes based on all other = IESG review comments. If the new version is OK, I'd like to restart the approval process at = the appropriate point. Please let me know if there are problems. Pending the announcement of document availability from the archive, = revision 10 can be obtained from ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-10.pdf or ftp://ftp.nishansystems.com/outgoing/draft-ietf-dhc-isnsoption-10.txt. Markups visible in the PDF version show the text that was added or = deleted. -- Charles ----------------------------------------- Charles Monia Senior Technology Consultant Nishan Systems email: cmonia@nishansystems.com voice: (408) 519-3986 fax: (408) 435-8385 =20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 15 14:30:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17313; Mon, 15 Sep 2003 14:30:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yy6t-0004Q4-05; Mon, 15 Sep 2003 14:30:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yy6R-0004PE-3J for dhcwg@optimus.ietf.org; Mon, 15 Sep 2003 14:29:35 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17092; Mon, 15 Sep 2003 14:29:26 -0400 (EDT) Message-Id: <200309151829.OAA17092@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: Mon, 15 Sep 2003 14:29:26 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-09.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 : The IPv4 DHCP Options for the Internet Storage Name Service Author(s) : C. Monia, J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-09.txt,.pdf Pages : 14 Date : 2003-9-15 This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) 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-09.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-09.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-09.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: <2003-9-15115512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-15115512.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 15 16:01:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23520; Mon, 15 Sep 2003 16:01:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzWx-0001CB-RF; Mon, 15 Sep 2003 16:01:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19yzWl-0001Be-6x for dhcwg@optimus.ietf.org; Mon, 15 Sep 2003 16:00:51 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23437 for ; Mon, 15 Sep 2003 16:00:44 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19yzWj-0005Xd-00 for dhcwg@ietf.org; Mon, 15 Sep 2003 16:00:49 -0400 Received: from mail-orl.bigfish.com ([63.161.60.61] helo=mail4-atl-R.bigfish.com) by ietf-mx with esmtp (Exim 4.12) id 19yzWi-0005XC-00 for dhcwg@ietf.org; Mon, 15 Sep 2003 16:00:48 -0400 Received: from mail4-atl.bigfish.com (localhost.localdomain [127.0.0.1]) by mail4-atl-R.bigfish.com (Postfix) with ESMTP id 5CFD02EB1F4; Mon, 15 Sep 2003 20:00:11 +0000 (UCT) Received: by mail4-atl (MessageSwitch) id 1063656011307794_1439; Mon, 15 Sep 2003 20:00:11 +0000 (UCT) Received: from smtpgw5.sprintspectrum.com (smtpgw5.sprintspectrum.com [207.40.188.13]) by mail4-atl.bigfish.com (Postfix) with ESMTP id 0FCA92EB238; Mon, 15 Sep 2003 20:00:11 +0000 (UCT) Received: from mailhost.sprintspectrum.com (smtpgw7.it.sprintspectrum.com [207.40.65.55]) by smtpgw5.sprintspectrum.com (8.12.9/8.12.8) with ESMTP id h8FK0Av7022514; Mon, 15 Sep 2003 15:00:10 -0500 (CDT) Received: from PKDWG02A.ad.sprint.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8FK0At12027; Mon, 15 Sep 2003 15:00:10 -0500 (CDT) Received: from mail pickup service by PKDWG02A.ad.sprint.com with Microsoft SMTPSVC; Mon, 15 Sep 2003 14:59:42 -0500 Received: from mailhost.sprintspectrum.com ([207.40.65.55]) by PKDWG01A.ad.sprint.com with Microsoft SMTPSVC(5.0.2195.5329); Mon, 15 Sep 2003 13:33:33 -0500 Received: from damgwp01.corp.sprint.com (localhost [127.0.0.1]) by mailhost.sprintspectrum.com (Switch-2.2.6/Switch-2.2.6) with ESMTP id h8FIXWt01946 for ; Mon, 15 Sep 2003 13:33:32 -0500 (CDT) Received: from mail5-kan-R.bigfish.com (mail-chi.bigfish.com [63.161.60.29]) by damgwp01.corp.sprint.com (Switch-2.1.6/Switch-2.1.0) with ESMTP id h8FIalF01388 for ; Mon, 15 Sep 2003 13:36:47 -0500 (CDT) Received: from mail5-kan.bigfish.com (localhost.localdomain [127.0.0.1]) by mail5-kan-R.bigfish.com (Postfix) with ESMTP id 18C0D1FF5DF for ; Mon, 15 Sep 2003 18:33:31 +0000 (UCT) Received: by mail5-kan (MessageSwitch) id 1063650809698792_27182; Mon, 15 Sep 2003 18:33:29 +0000 (UCT) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mail5-kan.bigfish.com (Postfix) with ESMTP id 1FF3A1FF644; Mon, 15 Sep 2003 18:33:24 +0000 (UCT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19yy7l-0005yJ-R8 for ietf-announce-list@asgard.ietf.org; Mon, 15 Sep 2003 14:30:57 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19yy6P-0005hb-GL for all-ietf@asgard.ietf.org; Mon, 15 Sep 2003 14:29:33 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17092; Mon, 15 Sep 2003 14:29:26 -0400 (EDT) Message-Id: <200309151829.OAA17092@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: Mon, 15 Sep 2003 14:29:26 -0400 Precedence: bulk X-BigFish: pcs-62(z519j60di60eiz14c3M13bfIzz2cfRzz1033ILz1IV)v X-OriginalArrivalTime: 15 Sep 2003 18:33:39.0625 (UTC) FILETIME=[E1EEA190:01C37BB7] Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-09.txt,.pdf 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. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The IPv4 DHCP Options for the Internet Storage Name Service Author(s) : C. Monia, J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-09.txt,.pdf Pages : 14 Date : 2003-9-15 This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) 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-09.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-09.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-09.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: <2003-9-15115512.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-09.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-15115512.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 16 09:56:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13147; Tue, 16 Sep 2003 09:56:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGJK-0007ml-S7; Tue, 16 Sep 2003 09:56:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zGJ4-0007ly-C5 for dhcwg@optimus.ietf.org; Tue, 16 Sep 2003 09:55:50 -0400 Received: from asgard.ietf.org (asgard.ietf.org [10.27.6.40]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13110 for ; Tue, 16 Sep 2003 09:55:42 -0400 (EDT) Received: from apache by asgard.ietf.org with local (Exim 4.14) id 19zGIy-0007wx-6x; Tue, 16 Sep 2003 09:55:44 -0400 X-test-idtracker: no To: IETF-Announce :; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Message-Id: Date: Tue, 16 Sep 2003 09:55:44 -0400 Subject: [dhcwg] Last Call: 'KDC Server Address Sub-option' to Proposed Standard 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 IESG has received a request from the Dynamic Host Configuration WG to consider the following document: - 'KDC Server Address Sub-option ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2003-09-30. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-suboptions-kdc-serveraddress-04.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 16 15:04:32 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02561; Tue, 16 Sep 2003 15:04:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL7J-00049p-Eo; Tue, 16 Sep 2003 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zL6g-00046X-SD for dhcwg@optimus.ietf.org; Tue, 16 Sep 2003 15:03:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02173 for ; Tue, 16 Sep 2003 15:03:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zL6d-0007ja-00 for dhcwg@ietf.org; Tue, 16 Sep 2003 15:03:19 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19zL6d-0007jT-00 for dhcwg@ietf.org; Tue, 16 Sep 2003 15:03:19 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 05E2E1B203C for ; Tue, 16 Sep 2003 14:00:47 -0500 (CDT) From: Ted Lemon To: dhcwg@ietf.org Date: Tue, 16 Sep 2003 14:03:53 -0500 User-Agent: KMail/1.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309161403.53065.mellon@fugue.com> Content-Transfer-Encoding: 7bit Subject: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... 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 We have encountered in the field a relay agent that does something interesting. RFC3046 says that the relay agent is supposed to insert the Relay Agent Information option into the packet at the point where the End option in the packet was found, or at the end of the options. This client ignores RFC3046 and stores the Relay Agent Information option _after_ the packet's End option, followed by its own End option. Our first reaction was to think that the relay agent was just buggy, but I went and looked at the RFCs and discovered a problem, which this relay agent actually doesn't hit because of its weird way of storing the option. The problem is that what RFC3046 says about the End option is ambiguous with respect to figuring out what the packet looked like when the RFC3118 signature was computed. Consider the following scenarios: 1. The packet has an End option after the last informative option (by which I mean an option that conveys information, as opposed to an End or Pad option). 2. The packet has no End option, and has some number of bytes of Pad options after the last informative option. 3. The packet has no End option, and no Pad options after the last informative option. It could be argued that (2) and (3) violate section 4.1 of RFC2131, which says "The last option must always be the 'end' option." However, people have interpreted this in different ways - does this mean that the packet MUST have an End option, or does it mean that if the packet has an End option, it MUST be the last option in the packet? What should the sending agent do when it has exactly enough options to fill the option buffer, and no room for an End option? Does it send the End option, or not? So although cases (2) and (3) are technically out of spec, I would say that we should account for them. Even in case (1), it's not clear what to do. Is the End option included in the signature, or no? I think we need some language to explicitly say what relay agents should do in all of these cases, and also what sending agents should do in these cases. Comments? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 16 15:42:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05413; Tue, 16 Sep 2003 15:42:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLi5-0005cS-Ub; Tue, 16 Sep 2003 15:42:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zLhu-0005c5-Je for dhcwg@optimus.ietf.org; Tue, 16 Sep 2003 15:41:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05379 for ; Tue, 16 Sep 2003 15:41:43 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zLht-0000Zi-00 for dhcwg@ietf.org; Tue, 16 Sep 2003 15:41:49 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 19zLhs-0000Za-00 for dhcwg@ietf.org; Tue, 16 Sep 2003 15:41:48 -0400 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 19zLhN-00049S-00; Tue, 16 Sep 2003 12:41:17 -0700 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Sep 2003 12:41:05 -0700 Message-ID: From: "Kostur, Andre" To: "'Ted Lemon'" , dhcwg@ietf.org Subject: RE: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... Date: Tue, 16 Sep 2003 12:41:04 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37C8A.7782D5A0" 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_01C37C8A.7782D5A0 Content-Type: text/plain; charset="iso-8859-1" 3118 seems to be pretty clear in that it acknowledges that option 82 may be present, and that the signature is to be calculated: "the server MUST compute any hash function as if the option were NOT included" (section 3). However 3118 does make a bad mention of option 82 being the last option in a message (also in section 3). I'd assume that it means that option 82 is taken completely out of the packet, and the packet is compressed by those bytes (as opposed to being filled by Pad options). In either case, I'd still call the relay buggy since in the definition of the End option (RFC 2132, section 3.2) it states "The end option marks the end of valid information in the vendor field.". Thus a strictly complying server cannot rely on anything that appears after the End option. If the End option is in the message, I'd expect it to be included in the hash. As for the presence/absence of the End option, our DHCP server will honour it if it is there (and stop reading anything past it), or assume that the end of the packet is the end of the options. -----Original Message----- From: Ted Lemon [mailto:mellon@fugue.com] Sent: Tuesday, September 16, 2003 12:04 PM To: dhcwg@ietf.org Subject: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... We have encountered in the field a relay agent that does something interesting. RFC3046 says that the relay agent is supposed to insert the Relay Agent Information option into the packet at the point where the End option in the packet was found, or at the end of the options. This client ignores RFC3046 and stores the Relay Agent Information option _after_ the packet's End option, followed by its own End option. Our first reaction was to think that the relay agent was just buggy, but I went and looked at the RFCs and discovered a problem, which this relay agent actually doesn't hit because of its weird way of storing the option. The problem is that what RFC3046 says about the End option is ambiguous with respect to figuring out what the packet looked like when the RFC3118 signature was computed. Consider the following scenarios: 1. The packet has an End option after the last informative option (by which I mean an option that conveys information, as opposed to an End or Pad option). 2. The packet has no End option, and has some number of bytes of Pad options after the last informative option. 3. The packet has no End option, and no Pad options after the last informative option. It could be argued that (2) and (3) violate section 4.1 of RFC2131, which says "The last option must always be the 'end' option." However, people have interpreted this in different ways - does this mean that the packet MUST have an End option, or does it mean that if the packet has an End option, it MUST be the last option in the packet? What should the sending agent do when it has exactly enough options to fill the option buffer, and no room for an End option? Does it send the End option, or not? So although cases (2) and (3) are technically out of spec, I would say that we should account for them. Even in case (1), it's not clear what to do. Is the End option included in the signature, or no? I think we need some language to explicitly say what relay agents should do in all of these cases, and also what sending agents should do in these cases. Comments? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C37C8A.7782D5A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] An unfortunate ambiguity in = RFC3118/RFC3046...

3118 seems to be pretty clear in that it acknowledges = that option 82 may be present, and that the signature is to be = calculated: "the server MUST compute any hash function as if the = option were NOT included" (section 3).  However 3118 does = make a bad mention of option 82 being the last option in a message = (also in section 3).  I'd assume that it means that option 82 is = taken completely out of the packet, and the packet is compressed by = those bytes (as opposed to being filled by Pad options).

In either case, I'd still call the relay buggy since = in the definition of the End option (RFC 2132, section 3.2) it states = "The end option marks the end of valid information in the vendor = field.".  Thus a strictly complying server cannot rely on = anything that appears after the End option.

If the End option is in the message, I'd expect it to = be included in the hash.

As for the presence/absence of the End option, our = DHCP server will honour it if it is there (and stop reading anything = past it), or assume that the end of the packet is the end of the = options.

-----Original Message-----
From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Tuesday, September 16, 2003 12:04 PM
To: dhcwg@ietf.org
Subject: [dhcwg] An unfortunate ambiguity in = RFC3118/RFC3046...


We have encountered in the field a relay agent that = does something
interesting.   RFC3046 says that the relay = agent is supposed to insert the
Relay Agent Information option into the packet at = the point where the End
option in the packet was found, or at the end of the = options.   This client
ignores RFC3046 and stores the Relay Agent = Information option _after_ the
packet's End option, followed by its own End = option.

Our first reaction was to think that the relay agent = was just buggy, but I
went and looked at the RFCs and discovered a = problem, which this relay agent
actually doesn't hit because of its weird way of = storing the option.

The problem is that what RFC3046 says about the End = option is ambiguous with
respect to figuring out what the packet looked like = when the RFC3118
signature was computed.   Consider the = following scenarios:

1. The packet has an End option after the last = informative option (by which I
mean an option that conveys information, as opposed = to an End or Pad option).

2. The packet has no End option, and has some number = of bytes of Pad options
after the last informative option.

3. The packet has no End option, and no Pad options = after the last informative
option.

It could be argued that (2) and (3) violate section = 4.1 of RFC2131, which says
"The last option must always be the 'end' = option."   However, people have
interpreted this in different ways - does this mean = that the packet MUST have
an End option, or does it mean that if the packet = has an End option, it MUST
be the last option in the packet?   What = should the sending agent do when it
has exactly enough options to fill the option = buffer, and no room for an End
option?   Does it send the End option, or = not?

So although cases (2) and (3) are technically out of = spec, I would say that we
should account for them.   Even in case = (1), it's not clear what to do.   Is
the End option included in the signature, or = no?

I think we need some language to explicitly say what = relay agents should do in
all of these cases, and also what sending agents = should do in these cases.

Comments?


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

------_=_NextPart_001_01C37C8A.7782D5A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 16 17:48:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14782; Tue, 16 Sep 2003 17:48:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zNg1-0002XQ-Eg; Tue, 16 Sep 2003 17:48:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zNfN-0002TN-Df for dhcwg@optimus.ietf.org; Tue, 16 Sep 2003 17:47:21 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14622 for ; Tue, 16 Sep 2003 17:47:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zNfK-0003Q7-00 for dhcwg@ietf.org; Tue, 16 Sep 2003 17:47:18 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19zNfK-0003Q4-00 for dhcwg@ietf.org; Tue, 16 Sep 2003 17:47:18 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 385681B203B; Tue, 16 Sep 2003 16:44:47 -0500 (CDT) From: Ted Lemon To: "Kostur, Andre" Subject: Re: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... Date: Tue, 16 Sep 2003 16:47:54 -0500 User-Agent: KMail/1.5 References: In-Reply-To: Cc: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309161647.54563.mellon@nominum.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 On Tuesday 16 September 2003 14:41, you wrote: > If the End option is in the message, I'd expect it to be included in the > hash. But how do we know which device put it there? What if the relay agent put it there? How does the receiver verify the signature? > As for the presence/absence of the End option, our DHCP server will honour > it if it is there (and stop reading anything past it), or assume that the > end of the packet is the end of the options. I think this is the right behavior for the server, but it doesn't resolve the ambiguity I described. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 16 19:06:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19272; Tue, 16 Sep 2003 19:06:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zOtV-00065m-VR; Tue, 16 Sep 2003 19:06:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zOsv-00064q-1W for dhcwg@optimus.ietf.org; Tue, 16 Sep 2003 19:05:25 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19207 for ; Tue, 16 Sep 2003 19:05:15 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zOsr-0004j9-00 for dhcwg@ietf.org; Tue, 16 Sep 2003 19:05:21 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 19zOsq-0004in-00 for dhcwg@ietf.org; Tue, 16 Sep 2003 19:05:21 -0400 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 19zOsK-00067z-00; Tue, 16 Sep 2003 16:04:48 -0700 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Sep 2003 16:04:37 -0700 Message-ID: From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... Date: Tue, 16 Sep 2003 16:04:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37CA6.E18F34E0" 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_01C37CA6.E18F34E0 Content-Type: text/plain; charset="iso-8859-1" The relay isn't allowed to add extra options other than 82 to a packet. Thus if an end option exists, it must have been placed there by the originating device (the one performing the original hash). Section 4.1.1 of RFC 1542: "All other BOOTP fields MUST be preserved intact.". Which is somewhat overridden by Section 2.1 of RFC 3046: A DHCP relay agent adding a Relay Agent Information field SHALL add it as the last option (but before 'End Option' 255, if present) in the DHCP options field of any recognized BOOTP or DHCP packet forwarded from a client to a server. Interesting to note that 3046 acknowledges that a client may not have supplied an End option. But it does not say that the relay is allowed to add an End option if one doesn't already exist. It only allows for the addition of option 82 as the last option in the packet, but before the End option "if present". And 3118 doesn't have anything to say about option 82, since it's not supposed to be there by the time the end client receives the packet. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Tuesday, September 16, 2003 2:48 PM To: Kostur, Andre Cc: dhcwg@ietf.org Subject: Re: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... On Tuesday 16 September 2003 14:41, you wrote: > If the End option is in the message, I'd expect it to be included in the > hash. But how do we know which device put it there? What if the relay agent put it there? How does the receiver verify the signature? > As for the presence/absence of the End option, our DHCP server will honour > it if it is there (and stop reading anything past it), or assume that the > end of the packet is the end of the options. I think this is the right behavior for the server, but it doesn't resolve the ambiguity I described. ------_=_NextPart_001_01C37CA6.E18F34E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] An unfortunate ambiguity in = RFC3118/RFC3046...

The relay isn't allowed to add extra options other = than 82 to a packet.  Thus if an end option exists, it must have = been placed there by the originating device (the one performing the = original hash).  Section 4.1.1 of RFC 1542: "All other BOOTP = fields MUST be preserved intact.".  Which is somewhat = overridden by Section 2.1 of RFC 3046:

   A DHCP relay agent adding a Relay Agent = Information field SHALL add
   it as the last option (but before 'End = Option' 255, if present) in
   the DHCP options field of any = recognized BOOTP or DHCP packet
   forwarded from a client to a = server.

Interesting to note that 3046 acknowledges that a = client may not have supplied an End option.  But it does not say = that the relay is allowed to add an End option if one doesn't already = exist.  It only allows for the addition of option 82 as the last = option in the packet, but before the End option "if = present".  And 3118 doesn't have anything to say about option = 82, since it's not supposed to be there by the time the end client = receives the packet.

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Tuesday, September 16, 2003 2:48 PM
To: Kostur, Andre
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] An unfortunate ambiguity in = RFC3118/RFC3046...


On Tuesday 16 September 2003 14:41, you wrote:
> If the End option is in the message, I'd expect = it to be included in the
> hash.

But how do we know which device put it = there?   What if the relay agent put it
there?   How does the receiver verify the = signature?

> As for the presence/absence of the End option, = our DHCP server will honour
> it if it is there (and stop reading anything = past it), or assume that the
> end of the packet is the end of the = options.

I think this is the right behavior for the server, = but it doesn't resolve the
ambiguity I described.

------_=_NextPart_001_01C37CA6.E18F34E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 16 22:20:35 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24276; Tue, 16 Sep 2003 22:20:35 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zRvI-0003sE-FR; Tue, 16 Sep 2003 22:20:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zRuT-0003qO-5r for dhcwg@optimus.ietf.org; Tue, 16 Sep 2003 22:19:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24236 for ; Tue, 16 Sep 2003 22:19:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zRuQ-0006bN-00 for dhcwg@ietf.org; Tue, 16 Sep 2003 22:19:10 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 19zRuP-0006bK-00 for dhcwg@ietf.org; Tue, 16 Sep 2003 22:19:09 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 12B571B2001 for ; Tue, 16 Sep 2003 21:16:35 -0500 (CDT) From: Ted Lemon To: dhcwg@ietf.org Subject: Re: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... Date: Tue, 16 Sep 2003 21:19:45 -0500 User-Agent: KMail/1.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309162119.45259.mellon@nominum.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 On Tuesday 16 September 2003 18:04, Kostur, Andre wrote: > Interesting to note that 3046 acknowledges that a client may not have > supplied an End option. But it does not say that the relay is allowed to > add an End option if one doesn't already exist. It only allows for the > addition of option 82 as the last option in the packet, but before the End > option "if present". And 3118 doesn't have anything to say about option > 82, since it's not supposed to be there by the time the end client receives > the packet. Right, my point is that right now the protocol specifications are ambiguous. That doesn't mean that a reasonable person can't guess what they mean. It means that two reasonable people might independently make different guesses. This is the problem. This is what I want to fix. Are you saying that this is not worth fixing? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 17 05:41:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03171; Wed, 17 Sep 2003 05:41:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYo3-0004oP-2i; Wed, 17 Sep 2003 05:41:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zYnw-0004nz-2w for dhcwg@optimus.ietf.org; Wed, 17 Sep 2003 05:40:56 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03155 for ; Wed, 17 Sep 2003 05:40:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zYns-0003L6-00 for dhcwg@ietf.org; Wed, 17 Sep 2003 05:40:52 -0400 Received: from webmail.mail.se.dataphone.net ([212.37.1.50] helo=intermail.se.dataphone.net) by ietf-mx with esmtp (Exim 4.12) id 19zYnr-0003L3-00 for dhcwg@ietf.org; Wed, 17 Sep 2003 05:40:51 -0400 Received: from [193.12.201.10] (account budm@weird-solutions.com HELO offset.weird.se) by intermail.se.dataphone.net (CommuniGate Pro SMTP 4.0.5) with ESMTP id 1967900; Wed, 17 Sep 2003 11:40:51 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. Subject: Fwd: Re: [dhcwg] An unfortunate ambiguity in RFC3118/RFC3046... Date: Wed, 17 Sep 2003 11:43:03 +0200 User-Agent: KMail/1.4.3 To: "'Ted Lemon'" , "Kostur, Andre" Cc: dhcwg@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200309171143.03480.budm@weird-solutions.com> Content-Transfer-Encoding: quoted-printable 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: quoted-printable On Tuesday 16 September 2003 21.03, Ted Lemon wrote: > We have encountered in the field a relay agent that does something > interesting. RFC3046 says that the relay agent is supposed to insert = the > Relay Agent Information option into the packet at the point where the E= nd > option in the packet was found, or at the end of the options. This cl= ient > ignores RFC3046 and stores the Relay Agent Information option _after_ t= he > packet's End option, followed by its own End option. > > Our first reaction was to think that the relay agent was just buggy, bu= t I > went and looked at the RFCs and discovered a problem, which this relay > agent actually doesn't hit because of its weird way of storing the opti= on. > > The problem is that what RFC3046 says about the End option is ambiguous > with respect to figuring out what the packet looked like when the RFC31= 18 > signature was computed. Consider the following scenarios: > > 1. The packet has an End option after the last informative option (by w= hich > I mean an option that conveys information, as opposed to an End or Pad > option). > > 2. The packet has no End option, and has some number of bytes of Pad > options after the last informative option. > > 3. The packet has no End option, and no Pad options after the last > informative option. > > It could be argued that (2) and (3) violate section 4.1 of RFC2131, whi= ch > says "The last option must always be the 'end' option." However, peop= le > have interpreted this in different ways - does this mean that the packe= t > MUST have an End option, or does it mean that if the packet has an End > option, it MUST be the last option in the packet? (2) and (3) are common enough in practice, in my experience. A server sho= uld definitely handle these interpretations of the End option. > What should the sending > agent do when it has exactly enough options to fill the option buffer, = and > no room for an End option? Does it send the End option, or not? I've thought about this in the past, and it's easy enough to write a serv= er that handles either interpretation. But it's ambiguous for a client autho= r, because you don't know if you can pack your buffer with that last option = and "get away with" not sending an End option; you can't be sure the server w= ill accept it, although in practice it positively should. If I were to change the RFC to help client authors when making this decis= ion, I'd make it acceptable to not have an End option if there's exactly enoug= h room to fit the options. In all other cases I'd make it mandatory. > Even in case (1), it's not clear what to do. > Is the End option included in the signature, or no? > > If the End option is in the message, I'd expect it to be included in th= e > hash. > >> But how do we know which device put it there? What if the relay agen= t >> put it there? How does the receiver verify the signature? The End option is a valid option. I don't see why it would not be include= d in the hash. Also, I think Andre's comment about the relay agent not being able to add= an=20 end option is square on: you can't just add that option as a relay agent. If, as a relay agent, you find that you would have just enough room to in= sert option 82 if you left out the originator's End option, you're out of luck= ; End option is a legitimate option, and you are not allowed to remove it. RFC 3046 makes a special exception for the end option by saying "(but bef= ore=20 'End Option' 255, if present)", but that doesn't imply any other special treatment, such as being able to remove the option altogether. > I think we need some language to explicitly say what relay agents shoul= d do > in all of these cases, and also what sending agents should do in these > cases. I don't think RFC 3046 is ambiguous about handling of the End option, but= it=20 can't hurt to clarify the status of the End option if enough agent author= s=20 are getting it wrong. As for client authors, I do think it would be good = to=20 clarify when you can leave out the End option. When you said above: > Our first reaction was to think that the relay agent was just buggy, bu= t I > went and looked at the RFCs and discovered a problem, which this relay > agent actually doesn't hit because of its weird way of storing the opti= on. What I missed in this was how the relay agent you found can in any way justify placing option 82 *after* the End option. You're not saying it's justifiable, you're saying it will never result in an incorrectly comput= ed RFC 3118 hash value, right? But if the relay agent knows that it's not a= t liberty to remove any present End option, regardless of the circumstance= s, then there should not be a problem. That said, we discussed this here and are wondering about the behaviour o= f a relay that extends the original packet when the original packet does not = have an End option. The computed hash value would then be including n extra by= tes that the relay agent expanded the message by (although those bytes should= be zero). Is this a problem? It seems that from a purely technical perspective, the server should never compute bytes that were not part of the original mess= age. But without an end option, there's no way of knowing where to stop computation. If the hash function doesn't rely on the length of the origi= nal packet, that's good, but shouldn't it be stated explicitly that Pad optio= ns should not affect the hash value? Another suggestion could be to add a new suboption to option 82 denoting = the original length of the packet. 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 Wed Sep 17 08:31:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08884; Wed, 17 Sep 2003 08:31:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbSZ-0003cm-3C; Wed, 17 Sep 2003 08:31:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zbRr-0003ZD-Is for dhcwg@optimus.ietf.org; Wed, 17 Sep 2003 08:30:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA08845 for ; Wed, 17 Sep 2003 08:30:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19zbRq-0005DX-00 for dhcwg@ietf.org; Wed, 17 Sep 2003 08:30:18 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 19zbRp-0005DA-00 for dhcwg@ietf.org; Wed, 17 Sep 2003 08:30:18 -0400 Received: from cisco.com (171.68.223.138) by sj-iport-3.cisco.com with ESMTP; 17 Sep 2003 05:29:56 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h8HCTiBo007003; Wed, 17 Sep 2003 05:29:45 -0700 (PDT) Received: from rdroms-w2k01.cisco.com (rtp-vpn2-428.cisco.com [10.82.241.172]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACL71726; Wed, 17 Sep 2003 08:29:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20030917072421.00b89b80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 17 Sep 2003 08:29:39 -0400 To: dhcwg@ietf.org From: Ralph Droms Cc: Marc Majka , Vincent Lubet , dieter@apple.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Fwd: Withdrawal of draft-ietf-dhc-unused-optioncodes 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: , In response to the discovery that several option codes previously thought to be unused are, in fact, in use by devices from Apple Computer, I propose the changes included below to the Internet Draft "Unused DHCP Option Codes". These changes will be published in draft-ietf-dhc-unused-optioncodes-07.txt and the document will be resubmitted to the IESG. Please respond to these proposed changes by 9AM EDT, Mon, 9/22. If you agree with the changes as given below, please respond with a simple "OK" response. I am working with Dieter Sigmund of Apple to publish Internet Drafts describing these options. - Ralph 1st change - move descriptions of option codes 95, 112, 113 and 114 to section 3 of "Unused DHCP Option Codes": 3.2 In Use by Apple The following option codes are used by devices from Apple Computer. However, none of these option codes have been described in a published RFC. The dhc WG will endeavor to have specifications for these options published. 3.2.1 LDAP Servers Code: 95 Name: LDAP Servers Defined in: (none) Contact: Dieter Siegmund, dieter@apple.com Reason to recover: Never published in an RFC 3.2.2 Netinfo Parameters Codes: 112, 113 Name: Netinfo Address, Netinfo Tag Defined in: (none) Contact: Dieter Siegmund, dieter@apple.com Reason to recover: Never published in an RFC 3.2.3 URL Code: 114 Name: URL Defined in: (none) Contact: Dieter Siegmund, dieter@apple.com Reason to recover: Never published in an RFC 2nd change - add a sentence to section "IANA Considerations", specifying that the option codes returned for reassignment in this document should only be used after all of the currently available option codes have been assigned: 6. IANA Considerations IANA has returned the DHCP option codes listed in Section 2 to the list of available option codes. These option codes may be reassigned to new DHCP options, according to the procedures in RFC 2939 [6]. {+IANA is requested to reassign these option codes after the list of option codes that have never been assigned or have previously been returned has been exhausted.+} >X-Sender: mrw@mail.windriver.com >X-Mailer: QUALCOMM Windows Eudora Version 5.1 >Date: Mon, 01 Sep 2003 11:06:18 -0400 >To: iesg-secretary@ietf.org >From: Margaret Wasserman >Subject: Withdrawal of draft-ietf-dhc-unused-optioncodes >Cc: iesg@ietf.org, Ralph Droms > > >Hi All, > >We need to officially withdraw draft-ietf-dhc-unused-optioncodes >from the publication queue. > >After IESG approval, we discovered that three of the option codes >listed in this document are, in fact, in use by Apple. See >attached message for details. > >We will update the document to remove these options and resubmit >it. We also plan to modify the IANA considerations section to >indicate that the deprecated option numbers should not be resused >until the unallocated numbers are exhausted. > >Please let me or Thomas know if you have any questions or >concerns about this. > >Thanks, >Margaret > > > >--- > >Cc: Marc Majka , Vincent Lubet , > dieter@apple.com >From: Dieter Siegmund >Subject: DHCP options >Date: Tue, 26 Aug 2003 11:56:00 -0700 >To: rdroms@cisco.com >X-Mailer: Apple Mail (2.581) > >Hello, > >I noticed the following internet draft: >http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes -06.txt >in which it proposes re-using some options that we're using here at >Apple. > >In particular, we are using (and have been using for several releases): >2.7 LDAP Servers > Code: 95 > Name: LDAP Servers > Defined in: (none) > Contact: (none) > Reason to recover: Never published as Internet-Draft > >2.13 Netinfo Parameters > Codes: 112, 113 > Name: Netinfo Address, Netinfo Tag > Defined in: (none) > Contact: Marc Majka > Reason to recover: Never published as Internet-Draft > >We also recently started using: >2.14 URL > Code: 114 > Name: URL > Defined in: (none) > Contact: Vinod Valloppillil > Reason to recover: Never published as Internet-Draft > >I'd like to request that these not be returned to the unassigned pool >to give us time to formally document how they are defined, and that >they are being used. > >Sincerely, >Dieter Siegmund >Apple Core OS Networking _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Sep 17 09:51:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11356; Wed, 17 Sep 2003 09:51:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zchz-000764-3o; Wed, 17 Sep 2003 09:51:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19zche-00075e-Fx for dhcwg@optimus.ietf.org; Wed, 17 Sep 2003 09:50:42 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11162; Wed, 17 Sep 2003 09:50:32 -0400 (EDT) Message-Id: <200309171350.JAA11162@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: Wed, 17 Sep 2003 09:50:32 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-10.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 : The IPv4 DHCP Options for the Internet Storage Name Service Author(s) : C. Monia, J. Tseng, K. Gibbons Filename : draft-ietf-dhc-isnsoption-10.txt,.pdf Pages : 14 Date : 2003-9-17 This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) 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-10.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-10.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-10.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: <2003-9-17093120.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-17093120.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 18 13:37:36 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24940; Thu, 18 Sep 2003 13:37:36 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A02iF-00035a-LQ; Thu, 18 Sep 2003 13:37:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A02hu-000339-RF for dhcwg@optimus.ietf.org; Thu, 18 Sep 2003 13:36:43 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24879 for ; Thu, 18 Sep 2003 13:36:35 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A02hs-0006CE-00 for dhcwg@ietf.org; Thu, 18 Sep 2003 13:36:40 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A02hr-0006C5-00 for dhcwg@ietf.org; Thu, 18 Sep 2003 13:36:39 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id D5A7F1B2001; Thu, 18 Sep 2003 12:33:46 -0500 (CDT) From: Ted Lemon To: Erik Guttman Subject: Re: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP] Date: Thu, 18 Sep 2003 12:37:12 -0500 User-Agent: KMail/1.5 References: <3F60C8B5.900@sun.com> In-Reply-To: <3F60C8B5.900@sun.com> Cc: dhcwg@ietf.org, zeroconf@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309181237.12449.mellon@nominum.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 On Thursday 11 September 2003 14:10, Erik Guttman wrote: > This is important for the DHC WG to look at. It is the last open > issue up for discussion in the ZEROCONF WG. Feedback is requested > in the next week. Obviously we can't make a decision about this > without direction from the DHC WG. So I think the right answer to this question is to simply decouple the IPv4LL and DHCP state machines. As long as the IPV4ll state machine can reach out and touch the DHCP state machine, it's likely to do things that break the operation of the DHCP state machine. So the right answer is, IMHO, that if the IPv4LL believes that it *may* be in a state where connectivity has been lost, it should configure itself a link-local address, and when it leaves that state, it should make the transition back to using the globally routable address exclusively. In other words, the IPv4LL state machine should watch the DHCP state machine and make decisions at least in part based on what state the DHCP client is in, but the DHCP client should not change its behavior at all to accomodate this. So if the DHCP client is in the INIT-REBOOT state and doesn't get an answer from the DHCP server, it should continue using its globally routable address. But the IPv4LL agent should make note of this, and configure an IPv4LL address. Does that make sense? I realize that this has the downside that now the IPv4LL agent must be able to watch the DHCP client in order to do a good job of maintaining Iv4LL service, but I think this is preferable to breaking DHCP service. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Sep 18 13:56:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25712; Thu, 18 Sep 2003 13:56:27 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A030c-00059c-4g; Thu, 18 Sep 2003 13:56:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A030K-000583-IV for dhcwg@optimus.ietf.org; Thu, 18 Sep 2003 13:55:44 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25689 for ; Thu, 18 Sep 2003 13:55:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A030I-0007jz-00 for dhcwg@ietf.org; Thu, 18 Sep 2003 13:55:42 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A030H-0007ju-00 for dhcwg@ietf.org; Thu, 18 Sep 2003 13:55:41 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 904D91B2001; Thu, 18 Sep 2003 12:52:51 -0500 (CDT) From: Ted Lemon To: Ted Lemon , Erik Guttman Subject: Re: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP] Date: Thu, 18 Sep 2003 12:56:20 -0500 User-Agent: KMail/1.5 Cc: dhcwg@ietf.org, zeroconf@merit.edu References: <3F60C8B5.900@sun.com> <200309181237.12449.mellon@nominum.com> In-Reply-To: <200309181237.12449.mellon@nominum.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309181256.20887.mellon@fugue.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 On Thursday 18 September 2003 12:37, Ted Lemon wrote: > So I think the right answer to this question is to simply decouple the > IPv4LL and DHCP state machines. To be clear, I meant here "decouple the DHCP state machine from the IPv4ll state machine," but not "decouple the IPv4LL state machine from the DHCP state machine" - obviously this isn't possible if we do what I've proposed. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 19 12:30:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11364; Fri, 19 Sep 2003 12:30:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NoC-0002Lw-Gc; Fri, 19 Sep 2003 12:08:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nn9-0001r4-U9 for dhcwg@optimus.ietf.org; Fri, 19 Sep 2003 12:07:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07760 for ; Fri, 19 Sep 2003 12:07:18 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A07EJ-0001ZW-00 for dhcwg@ietf.org; Thu, 18 Sep 2003 18:26:27 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A06yi-0007jC-00 for dhcwg@ietf.org; Thu, 18 Sep 2003 18:10:20 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 2339B1B2001; Thu, 18 Sep 2003 17:07:28 -0500 (CDT) From: Ted Lemon To: Mika Liljeberg Subject: Re: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP] Date: Thu, 18 Sep 2003 17:10:58 -0500 User-Agent: KMail/1.5 Cc: dhcwg@ietf.org, zeroconf@merit.edu References: <3F60C8B5.900@sun.com> <200309181256.20887.mellon@fugue.com> <1063921090.18069.15.camel@hades> In-Reply-To: <1063921090.18069.15.camel@hades> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309181710.58592.mellon@fugue.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 On Thursday 18 September 2003 16:38, Mika Liljeberg wrote: > From the implementor's point of view the coupling either exists or it > doesn't. If it does exist an explicit interface is required between the > DHCP code and the v4LL code. How that interface is realized is an > implementation issue. The distinction is important because I do not want the presence of IPv4ll to break DHCP. There have been several suggestions about minimizing the damage that is caused by linking IPv4ll and DHCP. The way I've proposed eliminates the damage, as far as I can tell. > It would be better to have no coupling at all. I agree completely. However, in order for there to be no coupling, we have to say that IPv4ll and DHCP addresses should simply coexist at all times. We fought that battle and "lost." Personally, I'd be happier just to give up on IPv4ll entirely and use the Rendezvous standard instead, because of this damage. But given that the damage has been done, if the IPv4ll standard is going to go forward, it's imperative that we prevent it from making DHCP unreliable. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 19 13:04:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14693; Fri, 19 Sep 2003 13:04:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Ofq-0001IE-6Q; Fri, 19 Sep 2003 13:04:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0OfT-0001H2-J8 for dhcwg@optimus.ietf.org; Fri, 19 Sep 2003 13:03:49 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06419 for ; Fri, 19 Sep 2003 12:05:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0DAY-00030n-00 for dhcwg@ietf.org; Fri, 19 Sep 2003 00:46:58 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A0D1U-0002GZ-00 for dhcwg@ietf.org; Fri, 19 Sep 2003 00:37:36 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id A4BDD1B2001; Thu, 18 Sep 2003 23:34:42 -0500 (CDT) From: Ted Lemon To: Robert Elz Subject: Re: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP] Date: Thu, 18 Sep 2003 23:38:16 -0500 User-Agent: KMail/1.5 Cc: dhcwg@ietf.org, zeroconf@merit.edu References: <200309181237.12449.mellon@nominum.com> <3F60C8B5.900@sun.com> <4632.1063943577@munnari.OZ.AU> In-Reply-To: <4632.1063943577@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309182338.16364.mellon@fugue.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 On Thursday 18 September 2003 22:52, Robert Elz wrote: > This is really irrelevant to the issue raised. What was really being > requested, once all the wrapping is removed, was that this WG make a > change to the DHCP protocol (or perhaps more precisely, to the operational > requirements for DHCP) - that is to force DHCP clients to try harder to > get routable addresses (lower the delay as much as possible if there is > no immediate answer). That's one way to read it, yes. However, the reason for wanting this is that IPv4LL places a requirement on the network stack that it quickly *give up* trying to acquire an address, and several IPv4LL+DHCP implementations have in fact done this. And now we are being asked to put a bandaid on this by making it *re-acquire* an address quickly. So the root of the problem is, in fact, that the DHCP client is being made to act differently because of IPv4ll. The correct fix is to make sure that the DHCP client does not in fact modify its behaviour to make IPv4ll work, but rather to modify IPv4ll so that it doesn't interfere with the operation of the DHCP client. Lest you conclude that I am off my rocker, a way to check this would be to look for the place in RFC2131 where it says that the DHCP client should wait for five minutes after failing (that is, having retried and timed out) to contact a DHCP server, before reinitiating an attempt to contact one. I would direct your attention particularly to section 4.1, which says nothing like this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 19 13:08:23 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14887; Fri, 19 Sep 2003 13:08:23 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Oji-0001nh-7O; Fri, 19 Sep 2003 13:08:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0NnG-0001ts-Qx for dhcwg@optimus.ietf.org; Fri, 19 Sep 2003 12:07:39 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07905 for ; Fri, 19 Sep 2003 12:07:29 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A06XI-0004jk-00 for dhcwg@ietf.org; Thu, 18 Sep 2003 17:42:00 -0400 Received: from cs180094.pp.htv.fi ([213.243.180.94] helo=hades.pp.htv.fi) by ietf-mx with esmtp (Exim 4.12) id 1A06Tv-0004BG-00 for dhcwg@ietf.org; Thu, 18 Sep 2003 17:38:31 -0400 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h8ILcEn9023073; Fri, 19 Sep 2003 00:38:14 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h8ILcASX023064; Fri, 19 Sep 2003 00:38:10 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP] From: Mika Liljeberg To: Ted Lemon Cc: Ted Lemon , Erik Guttman , dhcwg@ietf.org, zeroconf@merit.edu In-Reply-To: <200309181256.20887.mellon@fugue.com> References: <3F60C8B5.900@sun.com> <200309181237.12449.mellon@nominum.com> <200309181256.20887.mellon@fugue.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1063921090.18069.15.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Fri, 19 Sep 2003 00:38:10 +0300 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 Thu, 2003-09-18 at 20:56, Ted Lemon wrote: > On Thursday 18 September 2003 12:37, Ted Lemon wrote: > > So I think the right answer to this question is to simply decouple the > > IPv4LL and DHCP state machines. > > To be clear, I meant here "decouple the DHCP state machine from the IPv4ll > state machine," but not "decouple the IPv4LL state machine from the DHCP > state machine" - obviously this isn't possible if we do what I've proposed. I don't think this is a particularly useful distinction. >From the implementor's point of view the coupling either exists or it doesn't. If it does exist an explicit interface is required between the DHCP code and the v4LL code. How that interface is realized is an implementation issue. It would be better to have no coupling at all. MikaL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 19 13:09:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14945; Fri, 19 Sep 2003 13:09:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Okh-000237-29; Fri, 19 Sep 2003 13:09:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nlh-0001HQ-Tg for dhcwg@optimus.ietf.org; Fri, 19 Sep 2003 12:06:02 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06564 for ; Fri, 19 Sep 2003 12:05:46 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0CkV-0007L6-00 for dhcwg@ietf.org; Fri, 19 Sep 2003 00:20:03 -0400 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1A0CPP-0004Ay-00 for dhcwg@ietf.org; Thu, 18 Sep 2003 23:58:16 -0400 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h8J3uBT09715; Fri, 19 Sep 2003 10:56:16 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8J3qvb20547; Fri, 19 Sep 2003 10:54:19 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: Erik Guttman , dhcwg@ietf.org, zeroconf@merit.edu Subject: Re: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP] In-Reply-To: <200309181237.12449.mellon@nominum.com> References: <200309181237.12449.mellon@nominum.com> <3F60C8B5.900@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 2003 10:52:57 +0700 Message-ID: <4632.1063943577@munnari.OZ.AU> 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: , Date: Thu, 18 Sep 2003 12:37:12 -0500 From: Ted Lemon Message-ID: <200309181237.12449.mellon@nominum.com> | So I think the right answer to this question is to simply decouple | the IPv4LL and DHCP state machines. This is really irrelevant to the issue raised. What was really being requested, once all the wrapping is removed, was that this WG make a change to the DHCP protocol (or perhaps more precisely, to the operational requirements for DHCP) - that is to force DHCP clients to try harder to get routable addresses (lower the delay as much as possible if there is no immediate answer). The relationship with LL addresses is purely coincidental to this. That's why this really belongs in the DHCP working group (where apparently, and I guess you already know, something has been proposed already), and not here at all. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Sep 19 13:32:42 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16407; Fri, 19 Sep 2003 13:32:42 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Nkm-00011G-Of; Fri, 19 Sep 2003 12:05:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0Njr-0000aI-Du for dhcwg@optimus.ietf.org; Fri, 19 Sep 2003 12:04:07 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05085 for ; Fri, 19 Sep 2003 12:03:57 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0I4U-000157-00 for dhcwg@ietf.org; Fri, 19 Sep 2003 06:01:02 -0400 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1A0Hqc-0005wV-00 for dhcwg@ietf.org; Fri, 19 Sep 2003 05:46:55 -0400 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h8J9jhT27217; Fri, 19 Sep 2003 16:45:43 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8J9im209586; Fri, 19 Sep 2003 16:44:52 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: dhcwg@ietf.org, zeroconf@merit.edu Subject: Re: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP] In-Reply-To: <200309182338.16364.mellon@fugue.com> References: <200309182338.16364.mellon@fugue.com> <200309181237.12449.mellon@nominum.com> <3F60C8B5.900@sun.com> <4632.1063943577@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Sep 2003 16:44:48 +0700 Message-ID: <19901.1063964688@munnari.OZ.AU> 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: , Date: Thu, 18 Sep 2003 23:38:16 -0500 From: Ted Lemon Message-ID: <200309182338.16364.mellon@fugue.com> | The correct fix is to make sure that the DHCP client does not in | fact modify its behaviour to make IPv4ll work, but rather to modify | IPv4ll so that it doesn't interfere with the operation of the DHCP client. I have no problem with that, that's what I'd do. The problem that we have is that everyone wants everything to fall into the perfect state instantly. Any time that we're in an unexpected state is "broken", even if there's nothing the implementation could really have done about that. That is, my approach to this, which I don't think conflicts with the drafts at all, would be to start the DHCP client (let it go do its thing just like it does now, ignoring LL addressing), wait a second and a half (puerly because of that 1 second boring meaningless non-answered ping delay verifying that the address is not assigned) and then see if I have an address. If not, configure an LL address as documented, and use that. Then keep monitoring the interface. If a routable address appears from somewhere (most likely from DHCP, but anywhere will do) mark the LL address (if the LL process has reached this stage yet) as deprecated - and yes, this means borrowing some (more) IPv6 innovation and terminology for v4 (which is really needed anyway to make dhcp work correctly - currently on the stack I use, if dhcp gives me a v4 address, then the lease expires, dhcp will then take away the address again - just as it should - but I can trivially avoid that just by killing my dhcp process, the IP stack has no concept at all of a lifetime for v4 addresses, if the dhcp process doesn't remove the address, it is permanent, it should have a valid time, just as v6 addresses do). The issue I was detecting in the issue (LL34) though is that once we're in that state, we don't want to remain in it, if a routable address should be available - LL34 is trying to tell DHCP to keep trying hard to get a routable address. | Lest you conclude that I am off my rocker, a way to check this would be to | look for the place in RFC2131 where it says that the DHCP client should | wait for five minutes after failing (that is, having retried and timed out) | to contact a DHCP server, before reinitiating an attempt to contact one. No, I know that's not there - that's why I used the words "operational requirements" in the previous message - LL34 wants to force implementations to retry quickly. 2131 doesn't say "wait 5 minutes" but it also doesn't say "don't wait 5 minutes", or "try again every 5 seconds" - something like the latter is what LL34 seems to be asking of DHCP (though it actually says 1 minute, not 5 seconds, but hints that 30 secs would be even better). That's why I see this issue as an attempt to change DHCP from the zeroconf WG. The LL processing happens just the same, other than wrt absolute times, whatever the DHCP server does, but people want it to happen quickly, not slowly... This is exacerbated with LL addresses existing (the problem is made worse), so now there's a greater incentive to fix it. Before LL, networking was simply broken, if no DHCP address could be obtained. That's a simple state - easy to explain - easy for the user to handle ("popop box says no dhcp server responded, no address, no networking - someone fix the dhcp server please!"). With LL addresses getting no routable address is "expected", it isn't an error - the stack just configures an LL address and says "I'm ready, use me" - and the user believes all is OK - except nothing works. In this situation we really want things to revert to the "fixed" state as quickly as possible, lest frustration result "where did I get this stupid useless address instead of the one I should have - the network is broken". kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 20 06:58:03 2003 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 GAA00457; Sat, 20 Sep 2003 06:58:03 -0400 (EDT) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.12.8/8.12.8) with ESMTP id h8KAtivN029349; Sat, 20 Sep 2003 06:55:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 19z4P9-0007EN-3A for dhcwg@optimus.ietf.org; Mon, 15 Sep 2003 21:13:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05606 for ; Mon, 15 Sep 2003 21:13:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 19z4P6-0001KY-00 for dhcwg@ietf.org; Mon, 15 Sep 2003 21:13:16 -0400 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 19z4P6-0001KK-00 for dhcwg@ietf.org; Mon, 15 Sep 2003 21:13:16 -0400 Received: from [66.95.38.74] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5405877 for dhcwg@ietf.org; Mon, 15 Sep 2003 21:13:11 -0400 Message-Id: <5.1.0.14.0.20030915160652.023f6e40@mail.stevecrocker.com> X-Sender: joel@stevecrocker.com@mail.stevecrocker.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 15 Sep 2003 16:38:32 -0400 To: dhcwg@ietf.org From: "Joel M. Halpern" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Review of DNA draft 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: , Bernard Aboba requested a "SIR" review of the Detection of Network Attachment (DNA) in IPv4 internet draft . I have read the document and have the comments below. My apologies if my concerns have been discussed on the mailing list already and resolved. I reviewed the document and the issues page (and the ARP RFC) in preparing this. I hope this review is of assistance to your work. Joel M. Halpern Over all the draft is well written and clear. It is on the right track, but I believe it could use some clarifications. In particular, two aspects seem to me to be in need of assistance. Firstly, the problem statement seems to be missing a piece. While the concern being addressed is likely obvious to those who work daily with DHCP and DHCP related issues, it is not obvious to a reader from another community. In particular, I found myself asking why I would use the reachability validation step rather than simply going directly to INIT-REBOOT state and sending a DHCPREQUEST to the broadcast address. I suspect that the ARP reachability verification mechanism is expected to be significantly faster and to place less load on other parts of the system. But the document does not say that. Secondly, in the description of the reachability verification mechanisms it would be helpful if there were a sentence indicating why the use of the 0.0.0.0 source protocol address will be effective. (I checked the ARP RFC< not having ARP code handy, and I understand that the ARP response generation sends the response to the source hardware address. It would be helpful to the reader if the document said this.) Related to this clarification, it would probably be helpful to note (probably in an appendix) both whether this behavior has been observed to cuase any strange ARP cache entries and whether most observed implementations do indeed respond properly to the message proposed here. (I know they should. However, the difference between theory and practice...) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 20 11:07:08 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10014; Sat, 20 Sep 2003 11:07:08 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jJC-000134-Qh; Sat, 20 Sep 2003 11:06:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jIr-00011g-SV for dhcwg@optimus.ietf.org; Sat, 20 Sep 2003 11:05:41 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22829 for ; Fri, 19 Sep 2003 17:44:04 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0T2x-0001v4-00 for dhcwg@ietf.org; Fri, 19 Sep 2003 17:44:11 -0400 Received: from pan.gwi.net ([207.5.128.165]) by ietf-mx with esmtp (Exim 4.12) id 1A0T2m-0001uo-00 for dhcwg@ietf.org; Fri, 19 Sep 2003 17:44:00 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by pan.gwi.net (8.12.6p3/8.12.6) with ESMTP id h8JLh9QU086663; Fri, 19 Sep 2003 17:43:13 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie & Maureen Volz" To: "'Ralph Droms'" , Cc: "'Marc Majka'" , "'Vincent Lubet'" , Subject: RE: [dhcwg] Fwd: Withdrawal of draft-ietf-dhc-unused-optioncodes Date: Fri, 19 Sep 2003 17:43:13 -0400 Message-ID: <000001c37ef7$07a23a40$6401a8c0@BVolz> 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.4510 Importance: Normal In-Reply-To: <4.3.2.7.2.20030917072421.00b89b80@flask.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 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 OK by me! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 20 11:22:06 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11251; Sat, 20 Sep 2003 11:22:06 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jXj-0003gw-It; Sat, 20 Sep 2003 11:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0ihy-0006f7-3r for dhcwg@optimus.ietf.org; Sat, 20 Sep 2003 10:27:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19749 for ; Fri, 19 Sep 2003 15:38:48 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0R5k-0000Vb-00 for dhcwg@ietf.org; Fri, 19 Sep 2003 15:38:56 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A0R5a-0000VV-00 for dhcwg@ietf.org; Fri, 19 Sep 2003 15:38:46 -0400 Received: from depa.dmes.org (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 6FECF1B221D; Fri, 19 Sep 2003 13:57:21 -0500 (CDT) From: Ted Lemon To: Robert Elz Subject: Re: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP] Date: Fri, 19 Sep 2003 14:01:01 -0500 User-Agent: KMail/1.5 References: <200309182338.16364.mellon@fugue.com> <4632.1063943577@munnari.OZ.AU> <19901.1063964688@munnari.OZ.AU> In-Reply-To: <19901.1063964688@munnari.OZ.AU> Cc: dhcwg@ietf.org, zeroconf@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200309191401.02029.mellon@nominum.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 On Friday 19 September 2003 04:44, Robert Elz wrote: > That is, my approach to this, which I don't think conflicts with the > drafts at all, would be to start the DHCP client (let it go do its thing > just like it does now, ignoring LL addressing), wait a second and a half > (puerly because of that 1 second boring meaningless non-answered ping delay > verifying that the address is not assigned) and then see if I have an > address. If not, configure an LL address as documented, and use that. Then > keep monitoring the interface. If a routable address appears from > somewhere (most likely from DHCP, but anywhere will do) mark the LL address > (if the LL process has reached this stage yet) as deprecated - [...] Right, this is exactly what I had in mind too. > The issue I was detecting in the issue (LL34) though is that once we're in > that state, we don't want to remain in it, if a routable address should be > available - LL34 is trying to tell DHCP to keep trying hard to get a > routable address. I don't think this is necessary. Section 4.1 of RFC2131 is already pretty explicit about what the DHCP client is supposed to do - the problem is that some popular DHCP clients aren't doing this, because (I presume) their state machines have been tweaked to accomodate IPv4ll. > No, I know that's not there - that's why I used the words "operational > requirements" in the previous message - LL34 wants to force implementations > to retry quickly. 2131 doesn't say "wait 5 minutes" but it also doesn't > say "don't wait 5 minutes", or "try again every 5 seconds" - something like > the latter is what LL34 seems to be asking of DHCP (though it actually > says 1 minute, not 5 seconds, but hints that 30 secs would be even better). Actually, section 4.1 already says that the DHCP client shouldn't back off to more than 64 seconds, so the DHCP client should be retrying roughly every 64 seconds if it's following RFC2131. Perhaps the IPv4ll spec needs to make clear that implementors of IPv4ll that also implement DHCP must still follow the recommendations put forth in RFC2131 section 4.1. > Before LL, networking was simply broken, if no DHCP address could be > obtained. That's a simple state - easy to explain - easy for the user > to handle ("popop box says no dhcp server responded, no address, no > networking - someone fix the dhcp server please!"). With LL addresses > getting no routable address is "expected", it isn't an error - the stack > just configures an LL address and says "I'm ready, use me" - and the user > believes all is OK - except nothing works. In this situation we really > want things to revert to the "fixed" state as quickly as possible, lest > frustration result "where did I get this stupid useless address instead > of the one I should have - the network is broken". Right, and if we just don't let the IPv4ll state machine reach out and touch the DHCP state machine, this is precisely what will happen. That is, the DHCP client should never care about IPv4ll. It is helpful, however, for the IPv4ll agent to notice that the DHCP client has timed out in contacting the DHCP server. In this case, the DHCP client will still configure its interface if it has a valid lease. However, the IPv4ll agent at this point should probably also configure an IPv4ll address, since the address the DHCP client is using is by no means guaranteed to be correct. So simply watching the interface isn't going to get you the best results for IPv4ll, although it's an improvement over having the IPv4ll agent reaching out and touching the DHCP client. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 20 11:39:18 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13565; Sat, 20 Sep 2003 11:39:18 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0joJ-000075-4q; Sat, 20 Sep 2003 11:38:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A0jEA-0000sX-R5 for dhcwg@optimus.ietf.org; Sat, 20 Sep 2003 11:01:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00283 for ; Sat, 20 Sep 2003 06:44:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A0fDt-0002fx-00 for dhcwg@ietf.org; Sat, 20 Sep 2003 06:44:17 -0400 Received: from ratree.psu.ac.th ([202.12.73.3]) by ietf-mx with esmtp (Exim 4.12) id 1A0fDi-0002dA-00 for dhcwg@ietf.org; Sat, 20 Sep 2003 06:44:06 -0400 Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id h8KAdsT02163; Sat, 20 Sep 2003 17:39:55 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8KAdZP14652; Sat, 20 Sep 2003 17:39:36 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: dhcwg@ietf.org, zeroconf@merit.edu Subject: Re: [dhcwg] [Fwd: new issue: LL34 Better transition to routable from v4LL using DHCP] In-Reply-To: <200309191401.02029.mellon@nominum.com> References: <200309191401.02029.mellon@nominum.com> <200309182338.16364.mellon@fugue.com> <4632.1063943577@munnari.OZ.AU> <19901.1063964688@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 20 Sep 2003 17:39:35 +0700 Message-ID: <14282.1064054375@munnari.OZ.AU> 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: , Date: Fri, 19 Sep 2003 14:01:01 -0500 From: Ted Lemon Message-ID: <200309191401.02029.mellon@nominum.com> | I don't think this is necessary. Section 4.1 of RFC2131 is already pretty | explicit about what the DHCP client is supposed to do Necessary or not wasn't my point (and I'm not disagreeing with you), just that if anything were to be done in this area, changes in the LL spec by the zeroconf WG are not the right way to do it... | Right, and if we just don't let the IPv4ll state machine reach out and | touch the DHCP state machine, this is precisely what will happen. That | is, the DHCP client should never care about IPv4ll. Agreed. | It is helpful, however, for the IPv4ll agent to notice that the DHCP client | has timed out in contacting the DHCP server. Maybe, I am less sure about that one. | In this case, the DHCP client | will still configure its interface if it has a valid lease. Yes, and in most circumstances where that happens, that address will work just as well as a LL address (the DHCP client is supposed to verify that the lease still makes some kind of sense - it needs to do that to choose between the several valid leases it might have from past assignments (I've had clients allocated multi-year leases from some weird servers, and sometimes had several of those simultaneously). If the DHCP client checks that the address seems functional before assigning it, then the LL address would only be useful in the rarest cases. | However, the IPv4ll agent at this point should probably also configure | an IPv4ll address, since the address the DHCP client is using is by no | means guaranteed to be correct. That's true - but no-one knows. The DHCP client doesn't (if it knew it was incorrect, it would not configure it, to know it is correct it needs a DHCP server response, which we are assuming does not happen), the LL assignment machinery has no idea, it just sees a non-LL address (and perhaps the DHCP timeout), but more than that, none of the applications that are to use the address know either. They're going to be faced with the situation of having a choice of 2 local addresses to use, and no idea which one is going to work better. In most cases, the (old) DHCP address will work fine, and probably reach more destinations than the LL address, so in most cases that is what the applications are going to want to use, I suspect. Given that, doing the extra work to assign an LL address in this scenario seems pointless. | So simply watching the interface isn't going to get you the best | results for IPv4ll, If getting the best results for IPv4LL was an objective, I'd probably agree. But it isn't. Rather, IPv4LL is an attempt to get the best results for the system (or more likely, the system's user). That is, it doesn't matter in the slightest if IPv4LL fails miserably, as long as the end result is correct, and communications get established, at least in the vast majority of cases. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 22 11:52:34 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21731; Mon, 22 Sep 2003 11:52:34 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Syn-0002gS-Dg; Mon, 22 Sep 2003 11:52:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1Syc-0002fj-Hd for dhcwg@optimus.ietf.org; Mon, 22 Sep 2003 11:51:50 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21618 for ; Mon, 22 Sep 2003 11:51:36 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1SyW-0000hs-00 for dhcwg@ietf.org; Mon, 22 Sep 2003 11:51:44 -0400 Received: from chimera.incognito.com ([207.102.214.2]) by ietf-mx with esmtp (Exim 4.12) id 1A1SyL-0000hC-00 for dhcwg@ietf.org; Mon, 22 Sep 2003 11:51:33 -0400 Received: from [207.102.214.106] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 3.35 #1 (Debian)) id 1A1Sww-0003nE-00 for ; Mon, 22 Sep 2003 08:50:06 -0700 Received: by HOMER.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Mon, 22 Sep 2003 08:49:53 -0700 Message-ID: From: "Kostur, Andre" To: "'dhcwg@ietf.org'" Date: Mon, 22 Sep 2003 08:49:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C38121.2998A7C0" Subject: [dhcwg] LeaseQuery-05 and time calculations 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_01C38121.2998A7C0 Content-Type: text/plain; charset="iso-8859-1" I think there's needs to be some clarification on the following (Section 6.4.2, last paragraph of page 19): A request for the Renewal (T1) Time Value option or the Rebinding (T2) Time Value option in the Parameter Request List of the DHCPLEASEQUERY message MUST be handled like the IP Address Lease Time option is handled. If there is a valid lease, then the DHCP server SHOULD return these options (when requested) with the remaining time until renewal or rebinding, respectively. If there is not currently a valid lease for this IP address, the DHCP server MUST NOT return these options. This doesn't mention what to do if the T1 or T2 time has passed. Options 58 and 59 have no provisions for returning negative numbers. So would the better behaviour be to send back a zero time, or not send the option at all? Come to think of it... back up two paragraphs: If the IP Address Lease Time option (option 51) is specified in the Parameter Request List and if there is a currently valid lease for the IP address specified in the ciaddr, then the DHCP server MUST return this option in the DHCPLEASEKNOWN with its value equal to the time remaining until lease expiration. If there is no valid lease for the IP address, then the server MUST NOT return the IP Address Lease Time option (option 51). If there's a currently valid lease for the device, shouldn't it be returning a DHCPLEASEACTIVE, not a DHCPLEASEKNOWN? (Other than that discrepancy, the paragraph is fine....) ------_=_NextPart_001_01C38121.2998A7C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable LeaseQuery-05 and time calculations

I think there's needs to be some clarification on the = following (Section 6.4.2, last paragraph of page 19):

   A request for the Renewal (T1) Time = Value option or the Rebinding
   (T2) Time Value option in the Parameter = Request List of the
   DHCPLEASEQUERY message MUST be handled = like the IP Address Lease Time
   option is handled.  If there is a = valid lease, then the DHCP server
   SHOULD return these options (when = requested) with the remaining time
   until renewal or rebinding, = respectively.  If there is not currently
   a valid lease for this IP address, the = DHCP server MUST NOT return
   these options.

This doesn't mention what to do if the T1 or T2 time = has passed.  Options 58 and 59 have no provisions for returning = negative numbers.  So would the better behaviour be to send back a = zero time, or not send the option at all?

Come to think of it... back up two paragraphs:

   If the IP Address Lease Time option = (option 51) is specified in the
   Parameter Request List and if there is = a currently valid lease for
   the IP address specified in the ciaddr, = then the DHCP server MUST
   return this option in the = DHCPLEASEKNOWN with its value equal to the
   time remaining until lease = expiration.  If there is no valid lease
   for the IP address, then the server = MUST NOT return the IP Address
   Lease Time option (option 51).

If there's a currently valid lease for the device, = shouldn't it be returning a DHCPLEASEACTIVE, not a = DHCPLEASEKNOWN?  (Other than that discrepancy, the paragraph is = fine....)

------_=_NextPart_001_01C38121.2998A7C0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 27 17:12:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13439; Sat, 27 Sep 2003 17:12:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3MMC-0004vW-Hz; Sat, 27 Sep 2003 17:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kCa-0004n4-06 for dhcwg@optimus.ietf.org; Tue, 23 Sep 2003 06:15:24 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04523 for ; Tue, 23 Sep 2003 06:15:14 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1kCW-0005fN-00 for dhcwg@ietf.org; Tue, 23 Sep 2003 06:15:20 -0400 Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx with esmtp (Exim 4.12) id 1A1kCV-0005cV-00 for dhcwg@ietf.org; Tue, 23 Sep 2003 06:15:19 -0400 Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id h8NAEnis025159; Tue, 23 Sep 2003 03:14:49 -0700 (PDT) Received: from sun.com (vpn-129-159-0-194.EMEA.Sun.COM [129.159.0.194]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h8NAEkw04044; Tue, 23 Sep 2003 12:14:46 +0200 (MEST) Message-ID: <3F701D1B.8040704@sun.com> Date: Tue, 23 Sep 2003 12:14:51 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu, dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using 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: , Content-Transfer-Encoding: 7bit Action: Accept the issue, with the text as modified during discussion New text: 2.11 Transition from Link-Local IPv4 to Routable Address As discussed in Section 1.7, use of a routable address is preferred to assignment of a Link-Local IPv4 address. A Link-Local IPv4 address can be configured due to transient failures, such as incomplete link-layer authentication, spanning tree convergence issues, or because a DHCP server failed to respond to an initial query, or is inoperative for some time. Where a Link-Local IPv4 address is assigned due to a transient failure, experience has shown that five minutes (see Appendix A.2) may be too long an interval to wait prior to attempting to configure with DHCP. This document does not specify a strategy for quickly recovering a routable address in situations where a Link-Local IPv4 address is assigned due to a transient failure. In situations where many hosts are present on a single subnet, frequent attempts to contact the DHCP server could result in a heavy traffic load. Further discussion of this issue is provided in [DNAv4]. [DNAv4] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", draft-ietf-dhc-dna-ipv4-01.txt, Internet draft (work in progress), September 2003. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Sep 27 18:01:17 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13440; Sat, 27 Sep 2003 17:12:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3MMC-0004ve-UX; Sat, 27 Sep 2003 17:12:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A1kH3-0005Ol-Pq for dhcwg@optimus.ietf.org; Tue, 23 Sep 2003 06:20:01 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04774 for ; Tue, 23 Sep 2003 06:19:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A1kGz-000675-00 for dhcwg@ietf.org; Tue, 23 Sep 2003 06:19:57 -0400 Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx with esmtp (Exim 4.12) id 1A1kGy-00063P-00 for dhcwg@ietf.org; Tue, 23 Sep 2003 06:19:56 -0400 Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id h8NAJQVo001093; Tue, 23 Sep 2003 03:19:26 -0700 (PDT) Received: from sun.com (vpn-129-159-0-194.EMEA.Sun.COM [129.159.0.194]) by hs-ehdb03-01.Germany.Sun.COM (8.11.7+Sun/8.11.7/ENSMAIL,v2.2) with ESMTP id h8NAJNw04225; Tue, 23 Sep 2003 12:19:24 +0200 (MEST) Message-ID: <3F701E30.6010101@sun.com> Date: Tue, 23 Sep 2003 12:19:28 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: zeroconf@merit.edu, dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re: new issue: LL34 Better transition to routable from v4LL using 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: , Content-Transfer-Encoding: 7bit The text supplied by Bernard has the property that it does not specify any new behavior for DHCP. The new text makes it clear that an implementation of IPv4LL must attempt to obtain configuration via DHCP according to the DHCP specification, even if it has failed to in the past. I think this satisfies Ted's concern: Ted Lemon wrote: > The correct fix is to make sure that the DHCP client does not in fact > modify its behaviour to make IPv4ll work, but rather to modify IPv4ll > so that it doesn't interfere with the operation of the DHCP client. Erik _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Sep 29 10:57:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19433; Mon, 29 Sep 2003 10:57:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zSO-0006uV-Rd; Mon, 29 Sep 2003 10:57:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zRT-0006sv-8j for dhcwg@optimus.ietf.org; Mon, 29 Sep 2003 10:56:03 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19095; Mon, 29 Sep 2003 10:55:53 -0400 (EDT) Message-Id: <200309291455.KAA19095@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: Mon, 29 Sep 2003 10:55:53 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dna-ipv4-02.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 : Detection of Network Attachment (DNA) in IPv4 Author(s) : B. Aboba Filename : draft-ietf-dhc-dna-ipv4-02.txt Pages : 13 Date : 2003-9-29 The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This specification synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link-Local addresses, in order to optimize detection of network attachment by mobile hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.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-dna-ipv4-02.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-dna-ipv4-02.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: <2003-9-29110622.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dna-ipv4-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-29110622.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 29 22:51:38 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22408; Mon, 29 Sep 2003 22:51:38 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4AbO-00020H-93; Mon, 29 Sep 2003 22:51:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Aau-0001zq-Vv for dhcwg@optimus.ietf.org; Mon, 29 Sep 2003 22:50:33 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22382 for ; Mon, 29 Sep 2003 22:50:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Aar-0000kK-00 for dhcwg@ietf.org; Mon, 29 Sep 2003 22:50:29 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A4Aaq-0000kH-00 for dhcwg@ietf.org; Mon, 29 Sep 2003 22:50:28 -0400 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 5C6241B2C80; Mon, 29 Sep 2003 21:44:42 -0500 (CDT) Date: Mon, 29 Sep 2003 21:49:14 -0500 Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: dhcwg@ietf.org, zeroconf@merit.edu To: Erik Guttman From: Ted Lemon In-Reply-To: <3F701D1B.8040704@sun.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Tuesday, September 23, 2003, at 05:14 AM, Erik Guttman wrote: > The text supplied by Bernard has the property that it does not > specify any new behavior for DHCP. The new text makes it clear > that an implementation of IPv4LL must attempt to obtain configuration > via DHCP according to the DHCP specification, even if it has failed > to in the past. I think this satisfies Ted's concern: > > Ted Lemon wrote: > > The correct fix is to make sure that the DHCP client does not in fact > > modify its behaviour to make IPv4ll work, but rather to modify IPv4ll > > so that it doesn't interfere with the operation of the DHCP client. The new text that Bernard has supplied, at least as specified in your proposed resolution for LL34, does not seem to address the problem at all. The problem is that right now the IPv4ll protocol specification creates a situation in which there is an incentive to break the DHCP client in order to get correct IPv4ll behavior. My goal is not to break the DHCP client less. It is to not break it at all. If you don't agree with this goal, can you please try to build consensus by explaining why you don't agree with it? Also, I think that you should withdraw the statement that your proposed solution to LL34 has been accepted, since there was no discussion on it, and thus no opportunity for consensus. I certainly do not agree that it solves the stated problem. Possibly I am reading too much into the problem statement, but if so, I think we need a new discussion item: "IPv4LL state machine must not place requirements on DHCPv4 state machine." _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 10:19:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23437; Tue, 30 Sep 2003 10:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LLB-0000wG-F6; Tue, 30 Sep 2003 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zP2-0006hp-DQ for dhcwg@optimus.ietf.org; Mon, 29 Sep 2003 10:53:32 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18893 for ; Mon, 29 Sep 2003 10:53:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zOz-0006rz-00 for dhcwg@ietf.org; Mon, 29 Sep 2003 10:53:29 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1A3zOy-0006rr-00 for dhcwg@ietf.org; Mon, 29 Sep 2003 10:53:29 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8TEJJk01540 for ; Mon, 29 Sep 2003 07:19:19 -0700 Date: Mon, 29 Sep 2003 07:19:19 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Proposed Resolution to DNA Issue 6: SIRs review 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 text of DNA Issue #6 is enclosed below. The proposed fix is as follows: Change the abstract to: " The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This specification synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link-Local addresses, in order to optimize detection of network attachment by mobile hosts." Add the following text to Section 1: " The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. As a result, optimizing detection of network attachment is important for mobile hosts." Add the following text to Section 2.2: " Since the ARP Response is sent to the sender hardware address, the contents of the sender protocol address field do not affect delivery of the ARP Response. Since existing implementations do not create an ARP cache entry for 0.0.0.0, using this as the sender protocol address is harmless." ---------------------------------------------------------------------------------- Issue 6: SIRs Review Submitter: Joel Halpern Submitter email address: joel@stevecrocker.com Date first submitted: September 15, 2003 Reference: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02357.html Document: DNAv4-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Over all the draft is well written and clear. It is on the right track, but I believe it could use some clarifications. In particular, two aspects seem to me to be in need of assistance. Firstly, the problem statement seems to be missing a piece. While the concern being addressed is likely obvious to those who work daily with DHCP and DHCP related issues, it is not obvious to a reader from another community. In particular, I found myself asking why I would use the reachability validation step rather than simply going directly to INIT-REBOOT state and sending a DHCPREQUEST to the broadcast address. I suspect that the ARP reachability verification mechanism is expected to be significantly faster and to place less load on other parts of the system. But the document does not say that. Secondly, in the description of the reachability verification mechanisms it would be helpful if there were a sentence indicating why the use of the 0.0.0.0 source protocol address will be effective. (I checked the ARP RFC< not having ARP code handy, and I understand that the ARP response generation sends the response to the source hardware address. It would be helpful to the reader if the document said this.) Related to this clarification, it would probably be helpful to note (probably in an appendix) both whether this behavior has been observed to cuase any strange ARP cache entries and whether most observed implementations do indeed respond properly to the message proposed here. (I know they should. However, the difference between theory and practice...) _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 10:19:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23438; Tue, 30 Sep 2003 10:19:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4LLB-0000wO-ST; Tue, 30 Sep 2003 10:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A3zVU-0007AY-R9 for dhcwg@optimus.ietf.org; Mon, 29 Sep 2003 11:00:12 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19707 for ; Mon, 29 Sep 2003 11:00:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A3zVR-0006yz-00 for dhcwg@ietf.org; Mon, 29 Sep 2003 11:00:09 -0400 Received: from h-66-167-171-107.sttnwaho.covad.net ([66.167.171.107] helo=internaut.com) by ietf-mx with esmtp (Exim 4.12) id 1A3zVQ-0006yn-00 for dhcwg@ietf.org; Mon, 29 Sep 2003 11:00:08 -0400 Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id h8TEQ2601896 for ; Mon, 29 Sep 2003 07:26:03 -0700 Date: Mon, 29 Sep 2003 07:26:02 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Proposed resolution to DNA Issue 5: IPv4LL -> DHCP transition 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 text for DNA Issue 5 is enclosed below. The proposed fix is as follows: Add the following text to Section 2.3: "Where a Link-Local IPv4 address is assigned, experience has shown that five minutes (see [IPv4LL] Appendix A.2) is too long an interval to wait until retrying to obtain a routable IPv4 address using DHCP. According to [RFC2131] Section 4.1: The retransmission delay SHOULD be doubled with subsequent retransmissions up to a maximum of 64 seconds. As a result, a DHCP client compliant with [RFC2131] will continue to retry every 64 seconds, even after allocating a Link-Local IPv4 address. Should the DHCP client succeed in obtaining a routable address, then as noted in [IPv4LL], the Link-Local IPv4 address is deprecated. In order to avoid inappropriate assignment of an IPv4 Link-Local address, it is RECOMMENDED that such an address not be assigned until the DHCP client has retransmitted at least 3 times." ------------------------------------------------------------------------- Issue 5: IPv4LL -> DHCP transition Submitter: Robert Elz Submitter email address: kre@munnari.OZ.AU Date first submitted: September 10, 2003 Reference: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02331.html Document: DNAv4-01 Comment type: T Priority: S Section: 2.3 Rationale/Explanation of issue: I certainly agree that the long waits that dhcp clients usually fall into after their initial few attempts to contact a dhcp server can be most annoying, and that retrying more often would be nicer from the end user's viewpoint. On the other hand, I'm not sure that I'd be happy to have a LAN with perhaps hundreds of hosts (maybe thousands) all sending continuous streams of broadcast packets looking for a DHCP server. (A thousand hosts, with a 25 second (avg) delay is 40 broadcast packets a second, which is starting to get too high - make that 5000 hosts, which is not unreasonable in some switched environments, and you're at 200 broadcast packets a second - which is beyond inconvenient and into extremely annoying). It may be that the correct strategy here is for hosts that have failed to contact the DHCP server [and allocated an IPv4LL address is] to remain on a "slow retry" regime, but always set the "broadcast reply" bit in dhcp requests. Then, upon noticing a DHCP reply, hosts could (after a short random delay to avoid a packet deluge) try again to get an address (no requirement to request a broadcast reply, if not needed, after seeing one) - the observed reply would indicate that the DHCP server has returned to life. If there are just a few hosts that aren't getting replies, perhaps because the DHCP server is ignoring them deliberately, having them set the broadcast reply request bit (unnecessarily) will be harmless, there won't be replies. If the DHCP server has really gone absent, and there are lots of people looking for replies, this would allow the hosts to avoid sending much traffic until there is evidence that there's a reasonable chance of achieving a result. Ideally, the slow down rate would depend upon the number of clients around to make requests (what is really wanted is one client at random making a request every few seconds, and all the others staying quiet until they observe a reply) but with DHCP, knowing how many other clients there are would mean listening to request packets, that clients don't usually want to do (and on some OS's is hard, without precluding the client from also being a server on a different LAN). So, probably there just needs to be a reasonable compromise rate set. But this is all DHCP, not LL addressing, and needs the DHCP experts to give advice on - it is possible that they have considered, and rejected, this kind of approach in the past. [Ted Lemon] I think the right answer to this question is to simply decouple the IPv4LL and DHCP state machines. As long as the IPV4ll state machine can reach out and touch the DHCP state machine, it's likely to do things that break the operation of the DHCP state machine. So the right answer is, IMHO, that if the IPv4LL believes that it *may* be in a state where connectivity has been lost, it should configure itself a link-local address, and when it leaves that state, it should make the transition back to using the globally routable address exclusively. In other words, the IPv4LL state machine should watch the DHCP state machine and make decisions at least in part based on what state the DHCP client is in, but the DHCP client should not change its behavior at all to accomodate this. So if the DHCP client is in the INIT-REBOOT state and doesn't get an answer from the DHCP server, it should continue using its globally routable address. But the IPv4LL agent should make note of this, and configure an IPv4LL address. To be clear, I meant here "decouple the DHCP state machine from the IPv4ll state machine," but not "decouple the IPv4LL state machine from the DHCP state machine" - obviously this isn't possible if we do what I've proposed. Does that make sense? I realize that this has the downside that now the IPv4LL agent must be able to watch the DHCP client in order to do a good job of maintaining Iv4LL service, but I think this is preferable to breaking DHCP service. Now we are being asked to put a bandaid on this by making it *re-acquire* an address quickly. So the root of the problem is, in fact, that the DHCP client is being made to act differently because of IPv4ll. The correct fix is to make sure that the DHCP client does not in fact modify its behaviour to make IPv4ll work, but rather to modify IPv4ll so that it doesn't interfere with the operation of the DHCP client. Lest you conclude that I am off my rocker, a way to check this would be to look for the place in RFC2131 where it says that the DHCP client should wait for five minutes after failing (that is, having retried and timed out) to contact a DHCP server, before reinitiating an attempt to contact one. I would direct your attention particularly to section 4.1, which says nothing like this. Section 4.1 of RFC2131 is already pretty explicit about what the DHCP client is supposed to do - the problem is that some popular DHCP clients aren't doing this, because (I presume) their state machines have been tweaked to accomodate IPv4ll. Actually, section 4.1 already says that the DHCP client shouldn't back off to more than 64 seconds, so the DHCP client should be retrying roughly every 64 seconds if it's following RFC2131. Perhaps the IPv4ll spec needs to make clear that implementors of IPv4ll that also implement DHCP must still follow the recommendations put forth in RFC2131 section 4.1. [Robert Elz] | The correct fix is to make sure that the DHCP client does not in | fact modify its behaviour to make IPv4ll work, but rather to modify | IPv4ll so that it doesn't interfere with the operation of the DHCP | client. I have no problem with that, that's what I'd do. The problem that we have is that everyone wants everything to fall into the perfect state instantly. Any time that we're in an unexpected state is "broken", even if there's nothing the implementation could really have done about that. That is, my approach to this, which I don't think conflicts with the drafts at all, would be to start the DHCP client (let it go do its thing just like it does now, ignoring LL addressing), wait a second and a half (puerly because of that 1 second boring meaningless non-answered ping delay verifying that the address is not assigned) and then see if I have an address. If not, configure an LL address as documented, and use that. Then keep monitoring the interface. If a routable address appears from somewhere (most likely from DHCP, but anywhere will do) mark the LL address (if the LL process has reached this stage yet) as deprecated - and yes, this means borrowing some (more) IPv6 innovation and terminology for v4 (which is really needed anyway to make dhcp work correctly - currently on the stack I use, if dhcp gives me a v4 address, then the lease expires, dhcp will then take away the address again - just as it should - but I can trivially avoid that just by killing my dhcp process, the IP stack has no concept at all of a lifetime for v4 addresses, if the dhcp process doesn't remove the address, it is permanent, it should have a valid time, just as v6 addresses do). The issue I was detecting in the issue (LL34) though is that once we're in that state, we don't want to remain in it, if a routable address should be available - LL34 is trying to tell DHCP to keep trying hard to get a routable address. | Lest you conclude that I am off my rocker, a way to check this would | be to look for the place in RFC2131 where it says that the DHCP | client should wait for five minutes after failing (that is, having | retried and timed out) to contact a DHCP server, before | reinitiating an attempt to contact one. No, I know that's not there - that's why I used the words "operational requirements" in the previous message - LL34 wants to force implementations to retry quickly. 2131 doesn't say "wait 5 minutes" but it also doesn't say "don't wait 5 minutes", or "try again every 5 seconds" - something like the latter is what LL34 seems to be asking of DHCP (though it actually says 1 minute, not 5 seconds, but hints that 30 secs would be even better). That's why I see this issue as an attempt to change DHCP from the zeroconf WG. The LL processing happens just the same, other than wrt absolute times, whatever the DHCP server does, but people want it to happen quickly, not slowly... This is exacerbated with LL addresses existing (the problem is made worse), so now there's a greater incentive to fix it. Before LL, networking was simply broken, if no DHCP address could be obtained. That's a simple state - easy to explain - easy for the user to handle ("popop box says no dhcp server responded, no address, no networking - someone fix the dhcp server please!"). With LL addresses getting no routable address is "expected", it isn't an error - the stack just configures an LL address and says "I'm ready, use me" - and the user believes all is OK - except nothing works. In this situation we really want things to revert to the "fixed" state as quickly as possible, lest frustration result "where did I get this stupid useless address instead of the one I should have - the network is broken". [Ted Lemon] Right, and if we just don't let the IPv4ll state machine reach out and touch the DHCP state machine, this is precisely what will happen. That is, the DHCP client should never care about IPv4ll. It is helpful, however, for the IPv4ll agent to notice that the DHCP client has timed out in contacting the DHCP server. In this case, the DHCP client will still configure its interface if it has a valid lease. However, the IPv4ll agent at this point should probably also configure an IPv4ll address, since the address the DHCP client is using is by no means guaranteed to be correct. So simply watching the interface isn't going to get you the best results for IPv4ll, although it's an improvement over having the IPv4ll agent reaching out and touching the DHCP client. [Robert Elz] | In this case, the DHCP client | will still configure its interface if it has a valid lease. Yes, and in most circumstances where that happens, that address will work just as well as a LL address (the DHCP client is supposed to verify that the lease still makes some kind of sense - it needs to do that to choose between the several valid leases it might have from past assignments (I've had clients allocated multi-year leases from some weird servers, and sometimes had several of those simultaneously). If the DHCP client checks that the address seems functional before assigning it, then the LL address would only be useful in the rarest cases. | However, the IPv4ll agent at this point should probably also configure | an IPv4ll address, since the address the DHCP client is using is by no | means guaranteed to be correct. That's true - but no-one knows. The DHCP client doesn't (if it knew it was incorrect, it would not configure it, to know it is correct it needs a DHCP server response, which we are assuming does not happen), the LL assignment machinery has no idea, it just sees a non-LL address (and perhaps the DHCP timeout), but more than that, none of the applications that are to use the address know either. They're going to be faced with the situation of having a choice of 2 local addresses to use, and no idea which one is going to work better. In most cases, the (old) DHCP address will work fine, and probably reach more destinations than the LL address, so in most cases that is what the applications are going to want to use, I suspect. Given that, doing the extra work to assign an LL address in this scenario seems pointless. | So simply watching the interface isn't going to get you the best | results for IPv4ll, If getting the best results for IPv4LL was an objective, I'd probably agree. But it isn't. Rather, IPv4LL is an attempt to get the best results for the system (or more likely, the system's user). That is, it doesn't matter in the slightest if IPv4LL fails miserably, as long as the end result is correct, and communications get established, at least in the vast majority of cases. [Erik Guttman] The text supplied by Bernard has the property that it does not specify any new behavior for DHCP. The new text makes it clear that an implementation of IPv4LL must attempt to obtain configuration via DHCP according to the DHCP specification, even if it has failed to in the past. I think this satisfies Ted's concern: Ted Lemon wrote: > The correct fix is to make sure that the DHCP client does not in fact > modify its behaviour to make IPv4ll work, but rather to modify IPv4ll > so that it doesn't interfere with the operation of the DHCP client. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 13:56:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04637; Tue, 30 Sep 2003 13:56:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OjB-00072O-4s; Tue, 30 Sep 2003 13:56:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4OiL-0006vg-Dr for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 13:55:09 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04525 for ; Tue, 30 Sep 2003 13:55:01 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4OiJ-0002LT-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 13:55:07 -0400 Received: from cs180094.pp.htv.fi ([213.243.180.94] helo=hades.pp.htv.fi) by ietf-mx with esmtp (Exim 4.12) id 1A4OiH-0002LQ-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 13:55:06 -0400 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h8UHtq9H005266; Tue, 30 Sep 2003 20:55:52 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h8UHtnvB005265; Tue, 30 Sep 2003 20:55:49 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP From: Mika Liljeberg To: Erik Guttman Cc: Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu In-Reply-To: <3F79B93E.6030601@sun.com> References: <3F79B93E.6030601@sun.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1064944549.4769.5.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 30 Sep 2003 20:55:49 +0300 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 Erik, On Tue, 2003-09-30 at 20:11, Erik Guttman wrote: > I do agree with you. The DHCP client should not be broken or effected > by IPv4LL. The host stack which uses both will of course be more > complex than one which does not. Are you saying it is ok to run the DHCP and v4LL state machines independently of each other? I just want to be absolutely clear on this. MikaL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 14:32:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06233; Tue, 30 Sep 2003 14:32:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PI1-00010z-It; Tue, 30 Sep 2003 14:32:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PH6-0000xv-Tx for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 14:31:05 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06135 for ; Tue, 30 Sep 2003 14:30:56 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PH4-0002mb-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 14:31:02 -0400 Received: from [192.150.250.67] (helo=fuchsia.home) by ietf-mx with esmtp (Exim 4.12) id 1A4PH2-0002mM-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 14:31:01 -0400 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h8UIUcIe016279; Wed, 1 Oct 2003 01:30:38 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8UIODb06827; Wed, 1 Oct 2003 01:24:18 +0700 (ICT) From: Robert Elz To: Mika Liljeberg cc: Erik Guttman , Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP In-Reply-To: <1064944549.4769.5.camel@hades> References: <1064944549.4769.5.camel@hades> <3F79B93E.6030601@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Oct 2003 01:24:13 +0700 Message-ID: <25653.1064946253@munnari.OZ.AU> 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: , Date: Tue, 30 Sep 2003 20:55:49 +0300 From: Mika Liljeberg Message-ID: <1064944549.4769.5.camel@hades> | Are you saying it is ok to run the DHCP and v4LL state machines | independently of each other? I just want to be absolutely clear on this. The state machines run independently, when they're run - but you don't generate a LL address if you get an address from elsewhere. DHCP simply does its thing, as it does now, no changes needed. LL looks to see if an address has been obtained (or even manually configured), and if not, it runs its state machine to acquire one. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 14:44:33 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06857; Tue, 30 Sep 2003 14:44:33 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PTd-00028m-AW; Tue, 30 Sep 2003 14:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PTO-0001z0-Fb for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 14:43:46 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06782 for ; Tue, 30 Sep 2003 14:43:37 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PTL-0002wv-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 14:43:43 -0400 Received: from cs180094.pp.htv.fi ([213.243.180.94] helo=hades.pp.htv.fi) by ietf-mx with esmtp (Exim 4.12) id 1A4PTK-0002ws-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 14:43:42 -0400 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h8UIiU9H005407; Tue, 30 Sep 2003 21:44:30 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h8UIiT79005406; Tue, 30 Sep 2003 21:44:29 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP From: Mika Liljeberg To: Robert Elz Cc: Erik Guttman , Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu In-Reply-To: <25653.1064946253@munnari.OZ.AU> References: <1064944549.4769.5.camel@hades> <3F79B93E.6030601@sun.com> <25653.1064946253@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1064947469.4768.13.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 30 Sep 2003 21:44:29 +0300 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 Tue, 2003-09-30 at 21:24, Robert Elz wrote: > > | Are you saying it is ok to run the DHCP and v4LL state machines > | independently of each other? I just want to be absolutely clear on this. > > The state machines run independently, when they're run - but you don't > generate a LL address if you get an address from elsewhere. DHCP simply > does its thing, as it does now, no changes needed. LL looks to see if an > address has been obtained (or even manually configured), and if not, it > runs its state machine to acquire one. That's not exactly independent. In any case, in an ad-hoc scenario I need a working address within approx. 10 seconds after the user activates an application and the RF is powered up. Not much time to dance around, there. I figure the only way to meet the usability requirements is to run the state machines in parallel and deprecate the v4LL address later if DHCP happens to succeed. Time syncing the state machines is kind of hard, as the DHCP client is in user space and the v4LL protocol is in kernel space. If synching the state machines is a requirement, I'm afraid the DHCP client will have to do it. MikaL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 14:47:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07070; Tue, 30 Sep 2003 14:47:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PWX-0002bm-9W; Tue, 30 Sep 2003 14:47:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PWE-0002ZX-69 for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 14:46:42 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07023 for ; Tue, 30 Sep 2003 14:46:33 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PWB-00031U-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 14:46:39 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A4PWA-00031R-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 14:46:38 -0400 Received: from nominum.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 2F5321B2297; Tue, 30 Sep 2003 13:46:32 -0500 (CDT) Date: Tue, 30 Sep 2003 13:46:35 -0500 Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: zeroconf@merit.edu, dhcwg@ietf.org To: Erik Guttman From: Ted Lemon In-Reply-To: <1064944549.4769.5.camel@hades> Message-Id: <6B18505F-F376-11D7-B8D3-000A95D9C74C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) 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 Tuesday, September 30, 2003, at 12:55 PM, Mika Liljeberg wrote: >> I do agree with you. The DHCP client should not be broken or effected >> by IPv4LL. The host stack which uses both will of course be more >> complex than one which does not. > > Are you saying it is ok to run the DHCP and v4LL state machines > independently of each other? I just want to be absolutely clear on > this. This is the meat of the issue. The fact that the IPv4ll draft doesn't explicitly mention IPv4ll interaction with the DHCP state engine doesn't mean that there is no interaction. This is the topic about which I would like to see some dialog, and this is why I'm complaining. Erik, you are correct to say that the draft doesn't explicitly place requirements of any kind on DHCP. However, the draft does say what happens when routable IP addresses appear and disappear. And the problem with this is that we have seen implementors do the wrong thing because of this. The requirements in the draft about not having an IPv4ll address and an IPv4 routable address at the same time exacerbate the situation. So what would satisfy me would be some implementation notes in the document that looks something like this: x.x.x Interaction between DHCPv4 client and IPv4ll state machines A device that implements both IPv4ll and a DHCPv4 client MUST NOT alter the behavior of the DHCPv4 client to accommodate the IPv4ll state machine. Specifically, DHCPv4 specifies an INIT-REBOOT state. If a DHCPv4 client fails to contact a DHCP server while in INIT-REBOOT state, the implementor may be tempted to not configure the IP address from the client's valid DHCPv4 lease, preferring instead to acquire an IPv4ll address and use that address exclusively. This is an incorrect optimization. Instead, the implementor should allow the IPv4ll state machine in this case to acquire and use an IPv4ll address, while at the same time allowing the DHCPv4 client to configure the IP address from its lease. The problem with adding this text is that right now the IPv4ll draft isn't very helpful about how to choose an IP source address when you have both an IPv4ll address and a routable address. The result is that the implementor will have to figure this out on his or her own, through trial and error, or, more likely, will leave the problem unsolved, resulting in poor behavior in cases where both addresses are configured. I think that the draft needs to address this in detail, but whether it addresses this or not, in order for IPv4ll to not break the DHCP client, some text like what I've proposed needs to be added. I don't believe simply not explicitly requiring IPv4ll to break the DHCP INIT-REBOOT case is sufficient. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 15:04:28 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08360; Tue, 30 Sep 2003 15:04:28 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Pmz-0004OI-AX; Tue, 30 Sep 2003 15:04:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PmM-0004Nl-IF for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 15:03:22 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08219 for ; Tue, 30 Sep 2003 15:03:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PmJ-0003N6-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 15:03:19 -0400 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1A4PmJ-0003N2-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 15:03:19 -0400 Received: from cisco.com (64.102.124.12) by sj-iport-2.cisco.com with ESMTP; 30 Sep 2003 12:02:21 -0700 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id h8UJ2k01014596 for ; Tue, 30 Sep 2003 15:02:46 -0400 (EDT) Received: from rdroms-w2k01.cisco.com ([161.44.65.247]) by flask.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id ACU15716; Tue, 30 Sep 2003 15:02:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20030930150030.02012708@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 30 Sep 2003 15:02:43 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Agenda and scheduling for dhc WG during IETF 58 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 requested a slot for the dhc WG to meet in Minneapolis. Please contact me if you have items you want to get on the meeting agenda. I've asked for a slot to avoid conflicts with the following WGs: dnsext, dnsops, geopriv, ipcdn, ipv6, nemo, netconf, v6ops, zeroconf, zerouter Let me know if there are other WG meetings to avoid... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 15:15:29 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09713; Tue, 30 Sep 2003 15:15:29 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Pxf-0005kN-36; Tue, 30 Sep 2003 15:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4PxC-0005jf-Ab for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 15:14:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09590 for ; Tue, 30 Sep 2003 15:14:27 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4PxB-0003WZ-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 15:14:33 -0400 Received: from [192.150.250.67] (helo=fuchsia.home) by ietf-mx with esmtp (Exim 4.12) id 1A4Px9-0003WR-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 15:14:32 -0400 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h8UJE7Ie015302; Wed, 1 Oct 2003 02:14:07 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8UJ7Cb02872; Wed, 1 Oct 2003 02:07:12 +0700 (ICT) From: Robert Elz To: Ted Lemon cc: Erik Guttman , zeroconf@merit.edu, dhcwg@ietf.org Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP In-Reply-To: <6B18505F-F376-11D7-B8D3-000A95D9C74C@nominum.com> References: <6B18505F-F376-11D7-B8D3-000A95D9C74C@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Oct 2003 02:07:12 +0700 Message-ID: <20155.1064948832@munnari.OZ.AU> 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: , Date: Tue, 30 Sep 2003 13:46:35 -0500 From: Ted Lemon Message-ID: <6B18505F-F376-11D7-B8D3-000A95D9C74C@nominum.com> | A device that implements both IPv4ll and a DHCPv4 client MUST NOT alter | the behavior of the DHCPv4 client to accommodate the IPv4ll state | machine. That's too much, for two reasons. First, we don't specify how implementers implement the specifications, just the end results - so that's inappropriate right from the start. Second, if I want to alter my dhcp client, to have the LL address generation done by it, as well as dhcp address aquisition, why shouldn't I? Or if I just want to provide info from my dhcp client. I know those aren't the kinds of modifications you're concerned about, but they're covered by that blanket exclusion. If anything needs to be said, all it needs to be is that the DHCP state machine is not altered by LL. That's it. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 15:19:24 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10173; Tue, 30 Sep 2003 15:19:24 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Q1V-0006XQ-57; Tue, 30 Sep 2003 15:19:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Q0p-0006W5-I4 for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 15:18:19 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10105 for ; Tue, 30 Sep 2003 15:18:12 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Q0o-0003aa-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 15:18:18 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A4Q0n-0003aX-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 15:18:17 -0400 Received: from fugue.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 8473D1B2379; Tue, 30 Sep 2003 14:18:12 -0500 (CDT) Date: Tue, 30 Sep 2003 14:18:16 -0500 Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Ted Lemon To: dhcwg@ietf.org, zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <20155.1064948832@munnari.OZ.AU> Message-Id: X-Mailer: Apple Mail (2.552) 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 Tuesday, September 30, 2003, at 02:07 PM, Robert Elz wrote: > If anything needs to be said, all it needs to be is that the DHCP state > machine is not altered by LL. That's it. That's probably a better way to introduce the note than the MUST NOT that I put in. However, I think it's important to state explicitly what sort of interaction we are worried about, and why. You are right that we can't and shouldn't place requirements on the implementor as to how he or she implements this - that wasn't my intention, just bad wording. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 15:22:27 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10377; Tue, 30 Sep 2003 15:22:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Q4P-0006hq-HA; Tue, 30 Sep 2003 15:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Q3e-0006gT-2a for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 15:21:14 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10288 for ; Tue, 30 Sep 2003 15:21:03 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Q3Z-0003dZ-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 15:21:09 -0400 Received: from [192.150.250.67] (helo=fuchsia.home) by ietf-mx with esmtp (Exim 4.12) id 1A4Q3X-0003dU-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 15:21:08 -0400 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h8UJKkIe023613; Wed, 1 Oct 2003 02:20:46 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8UJDjb23361; Wed, 1 Oct 2003 02:13:45 +0700 (ICT) From: Robert Elz To: Mika Liljeberg cc: Erik Guttman , Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP In-Reply-To: <1064947469.4768.13.camel@hades> References: <1064947469.4768.13.camel@hades> <1064944549.4769.5.camel@hades> <3F79B93E.6030601@sun.com> <25653.1064946253@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 01 Oct 2003 02:13:45 +0700 Message-ID: <22850.1064949225@munnari.OZ.AU> 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: , Date: Tue, 30 Sep 2003 21:44:29 +0300 From: Mika Liljeberg Message-ID: <1064947469.4768.13.camel@hades> | That's not exactly independent. It is independent state machines - they are just dependencies on when they're used. | In any case, in an ad-hoc scenario I need a working address within | approx. 10 seconds after the user activates an application and the RF is | powered up. 10 secs should be plenty - it only takes a couple of seconds after the link is stable to get a DHCP assigned address, if you're going to get one, in the vast majority of cases (and perhaps an extra second or two for one more retry). LL is supposed to take about 3 seconds in the current version isn't it (I forget just what we eventually decided on the LL timers). That's 5-8 if run serially (assuming that you start LL acquisition if DHCP doesn't quickly get an address, which is what I suggest - not wait for DHCP to exhaust all its possibilities). | I figure the only way | to meet the usability requirements is to run the state machines in | parallel and deprecate the v4LL address later if DHCP happens to | succeed. Fine, I have no problem with that. | Time syncing the state machines is kind of hard, as the DHCP | client is in user space and the v4LL protocol is in kernel space. That's an implementation choice, you could move either to the other space. When one makes implementation choices, one, of course, has to live with the consequences. | If synching the state machines is a requirement, I'm afraid the DHCP client | will have to do it. I see no problem with that either, and I don't think Ted does either. What he's objecting to (I believe) is changing the nature of the DHCP exchange (the DHCP protocol), not really to changing the dhcp client code. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 15:34:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10890; Tue, 30 Sep 2003 15:34:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QG1-0007Pe-Gr; Tue, 30 Sep 2003 15:34:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QFa-0007Nv-84 for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 15:33:34 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10862 for ; Tue, 30 Sep 2003 15:33:26 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4QFY-0003mI-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 15:33:32 -0400 Received: from toccata.fugue.com ([204.152.186.142]) by ietf-mx with esmtp (Exim 4.12) id 1A4QFY-0003mF-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 15:33:32 -0400 Received: from fugue.com (dsl093-187-232.chi2.dsl.speakeasy.net [66.93.187.232]) by toccata.fugue.com (Postfix) with ESMTP id 0CBFF1B221C; Tue, 30 Sep 2003 14:33:27 -0500 (CDT) Date: Tue, 30 Sep 2003 14:33:31 -0500 Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Ted Lemon To: zeroconf@merit.edu, dhcwg@ietf.org Content-Transfer-Encoding: 7bit In-Reply-To: <22850.1064949225@munnari.OZ.AU> Message-Id: X-Mailer: Apple Mail (2.552) 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 Tuesday, September 30, 2003, at 02:13 PM, Robert Elz wrote: > | If synching the state machines is a requirement, I'm afraid the > DHCP client > | will have to do it. > > I see no problem with that either, and I don't think Ted does either. > What he's objecting to (I believe) is changing the nature of the DHCP > exchange (the DHCP protocol), not really to changing the dhcp client > code. That's right. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 15:39:25 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11324; Tue, 30 Sep 2003 15:39:25 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QKr-0008O1-G4; Tue, 30 Sep 2003 15:39:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QJy-00081O-2m for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 15:38:06 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11224; Tue, 30 Sep 2003 15:37:58 -0400 (EDT) Message-Id: <200309301937.PAA11224@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: Tue, 30 Sep 2003 15:37:57 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-vendor-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. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Vendor-Identifying Vendor Options for DHCPv4 Author(s) : J. Littlefield Filename : draft-ietf-dhc-vendor-00.txt Pages : 7 Date : 2003-9-30 The DHCP options for Vendor Class and Vendor-Specific Information can be ambiguous when a DHCP client represents multiple vendors. This document defines two new options, modeled on the IPv6 options for vendor class and vendor-specific information, which contain Enterprise Numbers to remove ambiguity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-vendor-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-ietf-dhc-vendor-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-ietf-dhc-vendor-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: <2003-9-30153020.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-vendor-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-vendor-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-9-30153020.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 16:01:37 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13380; Tue, 30 Sep 2003 16:01:37 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4QgF-0002SC-H6; Tue, 30 Sep 2003 16:01:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Qff-0002EO-1i for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 16:00:31 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13255 for ; Tue, 30 Sep 2003 16:00:23 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Qfd-0004Vh-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 16:00:29 -0400 Received: from maillock.lubrizol.com ([165.129.2.11] helo=mailtest.lubrizol.com) by ietf-mx with esmtp (Exim 4.12) id 1A4Qfc-0004V5-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 16:00:29 -0400 Content-Class: urn:content-classes:message Received: from mail pickup service by mailtest.lubrizol.com with Microsoft SMTPSVC; Tue, 30 Sep 2003 15:41:46 -0400 Received: from trapdoor.merit.edu ([198.108.1.26]) by maillock.Lubrizol.com with Microsoft SMTPSVC(5.0.2195.5329); Tue, 30 Sep 2003 14:33:41 -0400 Received: by trapdoor.merit.edu (Postfix) id 1E03791271; Tue, 30 Sep 2003 14:31:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DFC8491272; Tue, 30 Sep 2003 14:31:07 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Content-Transfer-Encoding: 7bit Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0223C91271 for ; Tue, 30 Sep 2003 14:31:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DB9C05DDBC; Tue, 30 Sep 2003 14:31:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fuchsia.home (unknown [192.150.250.67]) by segue.merit.edu (Postfix) with ESMTP id 35B495DD9E for ; Tue, 30 Sep 2003 14:31:05 -0400 (EDT) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Received: from delta.cs.mu.OZ.AU (delta.ex0.home [192.168.192.22]) by fuchsia.home with ESMTP id h8UIUcIe016279; Wed, 1 Oct 2003 01:30:38 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id h8UIODb06827; Wed, 1 Oct 2003 01:24:18 +0700 (ICT) From: "Robert Elz" To: "Mika Liljeberg" Cc: "Erik Guttman" , "Ted Lemon" , , Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP In-Reply-To: <1064944549.4769.5.camel@hades> References: <1064944549.4769.5.camel@hades> <3F79B93E.6030601@sun.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Wed, 01 Oct 2003 01:24:13 +0700 Message-ID: <25653.1064946253@munnari.OZ.AU> Precedence: bulk X-OriginalArrivalTime: 30 Sep 2003 18:33:41.0734 (UTC) FILETIME=[5F62B060:01C38781] 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 Date: Tue, 30 Sep 2003 20:55:49 +0300 From: Mika Liljeberg Message-ID: <1064944549.4769.5.camel@hades> | Are you saying it is ok to run the DHCP and v4LL state machines | independently of each other? I just want to be absolutely clear on this. The state machines run independently, when they're run - but you don't generate a LL address if you get an address from elsewhere. DHCP simply does its thing, as it does now, no changes needed. LL looks to see if an address has been obtained (or even manually configured), and if not, it runs its state machine to acquire one. kre _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 16:07:30 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13763; Tue, 30 Sep 2003 16:07:30 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Qlx-0002sO-MQ; Tue, 30 Sep 2003 16:07:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Qlv-0002ry-RR for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 16:07:00 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13685 for ; Tue, 30 Sep 2003 16:06:51 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Qlu-0004ec-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 16:06:58 -0400 Received: from cs180094.pp.htv.fi ([213.243.180.94] helo=hades.pp.htv.fi) by ietf-mx with esmtp (Exim 4.12) id 1A4Qls-0004eZ-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 16:06:57 -0400 Received: from hades.pp.htv.fi (liljeber@localhost [127.0.0.1]) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) with ESMTP id h8UK7i9H005645; Tue, 30 Sep 2003 23:07:45 +0300 Received: (from liljeber@localhost) by hades.pp.htv.fi (8.12.9/8.12.9/Debian-5) id h8UK7gus005644; Tue, 30 Sep 2003 23:07:42 +0300 X-Authentication-Warning: hades.pp.htv.fi: liljeber set sender to mika.liljeberg@welho.com using -f Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP From: Mika Liljeberg To: Robert Elz Cc: Erik Guttman , Ted Lemon , dhcwg@ietf.org, zeroconf@merit.edu In-Reply-To: <22850.1064949225@munnari.OZ.AU> References: <1064947469.4768.13.camel@hades> <1064944549.4769.5.camel@hades> <3F79B93E.6030601@sun.com> <25653.1064946253@munnari.OZ.AU> <22850.1064949225@munnari.OZ.AU> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1064952461.4769.70.camel@hades> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Tue, 30 Sep 2003 23:07:42 +0300 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 Tue, 2003-09-30 at 22:13, Robert Elz wrote: > | That's not exactly independent. > > It is independent state machines - they are just dependencies > on when they're used. I'd say that's mostly semantics. There's clearly a dependency but I think you're saying that it is limited to the DHCP client sending, as part of one of its own state transitions, the v4LL state machine a start or stop signal. I can live with that (it's more or less what I expected the requirement to be). But I do agree with Ted that there is some danger of misinterpritation. We need some fairly specific language on implementation issues to steer implementors away from harmful interpretations. MikaL _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 17:15:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16231; Tue, 30 Sep 2003 17:15:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Rpn-0006MC-1n; Tue, 30 Sep 2003 17:15:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Rp6-0006LI-R3 for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 17:14:20 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16179 for ; Tue, 30 Sep 2003 17:14:11 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Rp4-0005R8-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 17:14:18 -0400 Received: from 65.105.158.139.ptr.us.xo.net ([65.105.158.139] helo=mail.provocitypower.com) by ietf-mx with esmtp (Exim 4.12) id 1A4Rp3-0005R4-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 17:14:17 -0400 Received: from provoleachxp (65.105.158.177.ptr.us.xo.net [65.105.158.177]) by mail.provocitypower.com (Postfix) with ESMTP id F171142E57 for ; Tue, 30 Sep 2003 15:14:14 -0600 (MDT) From: "Aaron Leach" To: Date: Tue, 30 Sep 2003 15:14:11 -0600 Message-ID: <001801c38797$cd383450$b19e6941@provoleachxp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <20030930160003.27623.92897.Mailman@www1.ietf.org> Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] DHCP Version 3 Issue 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: quoted-printable Having Issue with DHCP version 3 We are having a few types of devices not getting addresses via the DHCP server. DHCP server is running on OpenBSD version 3.2. Basically, the types of devices that are in question are Netgear and = Linksys routers, Packet 8 DTA-310 terminal devices, and some older Macintosh versions older than OS-X 10.0.=20 We use a MYSQL database that dynamically creates a DHCP.conf file. We = put the exact mac address into the database. We use mac authentication so = that only those who are in the database work. I did a network sniff on one of the devices that was having an issue. I noticed in the sniff that a mac address was not being sent, but rather a device identifier and the last 6 digits of the mac address. Something = that looked like this: Kino 34:0b:36 =20 (I could not remember the device identifier for the DTA-310, but I think = it was Kino. I accidentally deleted the sniff, so the Kino part could be = wrong) The sniff showed that only requests were sent from the DTA-310, not = offers. The dhcp.leases file showed no requests going to the mac that requested = an address. Now there might be an issue where the device is sending = part-name/part-mac address and this could be throwing off the DHCP server which results as = an offer not being sent.=20 Is this the case? Is there a fix for this issue? Or, can someone direct = me in the book the answer is so that I can get this issue fixed? I = appreciate any help that is given. Thanks, A Leach Iprovo.net -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of dhcwg-request@ietf.org Sent: Tuesday, September 30, 2003 10:00 AM To: dhcwg@ietf.org Subject: dhcwg digest, Vol 1 #639 - 3 msgs Send dhcwg mailing list submissions to dhcwg@ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/dhcwg or, via email, send a message with subject or body 'help' to dhcwg-request@ietf.org You can reach the person managing the list at dhcwg-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcwg digest..." Today's Topics: 1. Re: WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP (Ted Lemon) 2. Proposed Resolution to DNA Issue 6: SIRs review (Bernard Aboba) 3. Proposed resolution to DNA Issue 5: IPv4LL -> DHCP transition = (Bernard Aboba) --__--__-- Message: 1 Date: Mon, 29 Sep 2003 21:49:14 -0500 Subject: Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition = to routable from v4LL using DHCP Cc: dhcwg@ietf.org, zeroconf@merit.edu To: Erik Guttman From: Ted Lemon On Tuesday, September 23, 2003, at 05:14 AM, Erik Guttman wrote: > The text supplied by Bernard has the property that it does not > specify any new behavior for DHCP. The new text makes it clear > that an implementation of IPv4LL must attempt to obtain configuration > via DHCP according to the DHCP specification, even if it has failed > to in the past. I think this satisfies Ted's concern: > > Ted Lemon wrote: > > The correct fix is to make sure that the DHCP client does not in = fact > > modify its behaviour to make IPv4ll work, but rather to modify = IPv4ll > > so that it doesn't interfere with the operation of the DHCP client. The new text that Bernard has supplied, at least as specified in your=20 proposed resolution for LL34, does not seem to address the problem at=20 all. The problem is that right now the IPv4ll protocol specification=20 creates a situation in which there is an incentive to break the DHCP=20 client in order to get correct IPv4ll behavior. My goal is not to=20 break the DHCP client less. It is to not break it at all. If you=20 don't agree with this goal, can you please try to build consensus by=20 explaining why you don't agree with it? Also, I think that you should withdraw the statement that your=20 proposed solution to LL34 has been accepted, since there was no=20 discussion on it, and thus no opportunity for consensus. I certainly=20 do not agree that it solves the stated problem. Possibly I am=20 reading too much into the problem statement, but if so, I think we need=20 a new discussion item: "IPv4LL state machine must not place=20 requirements on DHCPv4 state machine." --__--__-- Message: 2 Date: Mon, 29 Sep 2003 07:19:19 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org Subject: [dhcwg] Proposed Resolution to DNA Issue 6: SIRs review The text of DNA Issue #6 is enclosed below. The proposed fix is as follows: Change the abstract to: " The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. This specification synthesizes experience garnered over the years in the deployment of hosts supporting ARP, DHCP and IPv4 Link-Local addresses, in order to optimize detection of network attachment by mobile hosts." Add the following text to Section 1: " The time required to detect movement (or lack of movement) between subnets, and to obtain (or continue to use) a valid IPv4 address may be significant as a fraction of the total delay in moving between points of attachment. As a result, optimizing detection of network attachment is important for mobile hosts." Add the following text to Section 2.2: " Since the ARP Response is sent to the sender hardware address, the contents of the sender protocol address field do not affect delivery of the ARP Response. Since existing implementations do not create an ARP cache entry for 0.0.0.0, using this as the sender protocol address is harmless." -------------------------------------------------------------------------= --- ------ Issue 6: SIRs Review Submitter: Joel Halpern Submitter email address: joel@stevecrocker.com Date first submitted: September 15, 2003 Reference: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02357.h= tml Document: DNAv4-01 Comment type: T Priority: S Section: Various Rationale/Explanation of issue: Over all the draft is well written and clear. It is on the right track, but I believe it could use some clarifications. In particular, two = aspects seem to me to be in need of assistance. Firstly, the problem statement seems to be missing a piece. While the concern being addressed is likely obvious to those who work daily with DHCP and DHCP related issues, it is not obvious to a reader from another community. In particular, I found myself asking why I would use the reachability validation step rather than simply going directly to INIT-REBOOT state and sending a DHCPREQUEST to the broadcast address. I suspect that the ARP reachability verification mechanism is expected to = be significantly faster and to place less load on other parts of the = system. But the document does not say that. Secondly, in the description of the reachability verification mechanisms it would be helpful if there were a sentence indicating why the use of = the 0.0.0.0 source protocol address will be effective. (I checked the ARP = RFC< not having ARP code handy, and I understand that the ARP response generation sends the response to the source hardware address. It would = be helpful to the reader if the document said this.) Related to this clarification, it would probably be helpful to note (probably in an appendix) both whether this behavior has been observed to cuase any strange ARP cache entries and whether most observed implementations do indeed respond properly to the message proposed here. (I know they = should. However, the difference between theory and practice...) --__--__-- Message: 3 Date: Mon, 29 Sep 2003 07:26:02 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org Subject: [dhcwg] Proposed resolution to DNA Issue 5: IPv4LL -> DHCP transition The text for DNA Issue 5 is enclosed below. The proposed fix is as follows: Add the following text to Section 2.3: "Where a Link-Local IPv4 address is assigned, experience has shown that five minutes (see [IPv4LL] Appendix A.2) is too long an interval to wait until retrying to obtain a routable IPv4 address using DHCP. According to [RFC2131] Section 4.1: The retransmission delay SHOULD be doubled with subsequent retransmissions up to a maximum of 64 seconds. As a result, a DHCP client compliant with [RFC2131] will continue to retry every 64 seconds, even after allocating a Link-Local IPv4 address. Should the DHCP client succeed in obtaining a routable address, then as noted in [IPv4LL], the Link-Local IPv4 address is deprecated. In order to avoid inappropriate assignment of an IPv4 Link-Local address, it is RECOMMENDED that such an address not be assigned until the DHCP client has retransmitted at least 3 times." -------------------------------------------------------------------------= Issue 5: IPv4LL -> DHCP transition Submitter: Robert Elz Submitter email address: kre@munnari.OZ.AU Date first submitted: September 10, 2003 Reference: http://www1.ietf.org/mail-archive/working-groups/dhcwg/current/msg02331.h= tml Document: DNAv4-01 Comment type: T Priority: S Section: 2.3 Rationale/Explanation of issue: I certainly agree that the long waits that dhcp clients usually fall into after their initial few attempts to contact a dhcp server can be most annoying, and that retrying more often would be nicer from the end user's viewpoint. On the other hand, I'm not sure that I'd be happy to have a LAN with perhaps hundreds of hosts (maybe thousands) all sending continuous streams of broadcast packets looking for a DHCP server. (A thousand hosts, with a 25 second (avg) delay is 40 broadcast packets a second, which is starting to get too high - make that 5000 hosts, which is not unreasonable in some switched environments, and you're at 200 broadcast packets a second - which is beyond inconvenient and into extremely annoying). It may be that the correct strategy here is for hosts that have failed to contact the DHCP server [and allocated an IPv4LL address is] = to remain on a "slow retry" regime, but always set the "broadcast reply" = bit in dhcp requests. Then, upon noticing a DHCP reply, hosts could (after a short random delay to avoid a packet deluge) try again to get an address (no requirement to request a broadcast reply, if not needed, after seeing one) - the observed reply would indicate that the DHCP server has returned to life. If there are just a few hosts that aren't getting replies, perhaps because the DHCP server is ignoring them deliberately, having them set the broadcast reply request bit (unnecessarily) will be harmless, there won't be replies. If the DHCP server has really gone absent, and there are lots of people looking for replies, this would allow the hosts to avoid sending much traffic until there is evidence that there's a reasonable chance of achieving a result. Ideally, the slow down rate would depend upon the number of clients around to make requests (what is really wanted is one client at random making a request every few seconds, and all the others staying quiet = until they observe a reply) but with DHCP, knowing how many other clients = there are would mean listening to request packets, that clients don't usually want to do (and on some OS's is hard, without precluding the client from also being a server on a different LAN). So, probably there just needs to be a reasonable compromise rate set. But this is all DHCP, not LL addressing, and needs the DHCP experts to give advice on - it is possible that they have considered, and rejected, this kind of approach in the past. [Ted Lemon] I think the right answer to this question is to simply decouple the = IPv4LL and DHCP state machines. As long as the IPV4ll state machine can reach out and touch the DHCP state machine, it's likely to do things that = break the operation of the DHCP state machine. So the right answer is, IMHO, that if the IPv4LL believes that it *may* = be in a state where connectivity has been lost, it should configure itself = a link-local address, and when it leaves that state, it should make the transition back to using the globally routable address exclusively. In other words, the IPv4LL state machine should watch the DHCP state machine and make decisions at least in part based on what state the DHCP client is in, but the DHCP client should not change its behavior at all to accomodate this. So if the DHCP client is in the INIT-REBOOT state and doesn't get an answer from the DHCP server, it should continue using its globally routable address. But the IPv4LL agent should make note of this, and configure an IPv4LL address. To be clear, I meant here "decouple the DHCP state machine from the = IPv4ll state machine," but not "decouple the IPv4LL state machine from the DHCP state machine" - obviously this isn't possible if we do what I've proposed. Does that make sense? I realize that this has the downside that now = the IPv4LL agent must be able to watch the DHCP client in order to do a good job of maintaining Iv4LL service, but I think this is preferable to = breaking DHCP service. Now we are being asked to put a bandaid on this by making it = *re-acquire* an address quickly. So the root of the problem is, in fact, that the DHCP client is being made to act differently because of IPv4ll. The correct fix is to make sure that the DHCP client does not in fact modify its behaviour to make IPv4ll work, but rather to modify IPv4ll so that it doesn't interfere with the operation of the DHCP client. Lest you conclude that I am off my rocker, a way to check this would be = to look for the place in RFC2131 where it says that the DHCP client should wait for five minutes after failing (that is, having retried and timed = out) to contact a DHCP server, before reinitiating an attempt to contact one. = I would direct your attention particularly to section 4.1, which says nothing like this. Section 4.1 of RFC2131 is already pretty explicit about what the DHCP client is supposed to do - the problem is that some popular DHCP clients aren't doing this, because (I presume) = their state machines have been tweaked to accomodate IPv4ll. Actually, section 4.1 already says that the DHCP client shouldn't back = off to more than 64 seconds, so the DHCP client should be retrying roughly = every 64 seconds if it's following RFC2131. Perhaps the IPv4ll spec needs to make clear that implementors of IPv4ll that also implement DHCP must still follow the recommendations put forth in RFC2131 section 4.1. [Robert Elz] | The correct fix is to make sure that the DHCP client does not in | fact modify its behaviour to make IPv4ll work, but rather to modify | IPv4ll so that it doesn't interfere with the operation of the DHCP | client. I have no problem with that, that's what I'd do. The problem that we have is that everyone wants everything to fall into the perfect state instantly. Any time that we're in an unexpected state is "broken", even = if there's nothing the implementation could really have done about that. That is, my approach to this, which I don't think conflicts with the drafts at all, would be to start the DHCP client (let it go do its thing just like it does now, ignoring LL addressing), wait a second and a half (puerly because of that 1 second boring meaningless non-answered ping delay verifying that the address is not assigned) and then see if I have an address. If not, configure an LL address as documented, and use that. Then keep monitoring the interface. If a routable address appears from somewhere (most likely from DHCP, but anywhere will do) mark the LL address (if = the LL process has reached this stage yet) as deprecated - and yes, this = means borrowing some (more) IPv6 innovation and terminology for v4 (which is really needed anyway to make dhcp work correctly - currently on the = stack I use, if dhcp gives me a v4 address, then the lease expires, dhcp will then take away the address again - just as it should - but I can = trivially avoid that just by killing my dhcp process, the IP stack has no concept = at all of a lifetime for v4 addresses, if the dhcp process doesn't remove = the address, it is permanent, it should have a valid time, just as v6 addresses do). The issue I was detecting in the issue (LL34) though is that once we're = in that state, we don't want to remain in it, if a routable address should = be available - LL34 is trying to tell DHCP to keep trying hard to get a routable address. | Lest you conclude that I am off my rocker, a way to check this = would | be to look for the place in RFC2131 where it says that the DHCP | client should wait for five minutes after failing (that is, having | retried and timed out) to contact a DHCP server, before | reinitiating an attempt to contact one. No, I know that's not there - that's why I used the words "operational requirements" in the previous message - LL34 wants to force implementations to retry quickly. 2131 doesn't say "wait 5 minutes" = but it also doesn't say "don't wait 5 minutes", or "try again every 5 = seconds" - something like the latter is what LL34 seems to be asking of DHCP (though it actually says 1 minute, not 5 seconds, but hints that 30 secs would be even better). That's why I see this issue as an attempt to change DHCP from the = zeroconf WG. The LL processing happens just the same, other than wrt absolute times, whatever the DHCP server does, but people want it to happen quickly, not slowly... This is exacerbated with LL addresses existing (the problem is made worse), so now there's a greater incentive to fix it. Before LL, networking was simply broken, if no DHCP address could be obtained. That's a simple state - easy to explain - easy for the user to handle ("popop box says no dhcp server responded, no address, no networking - someone fix the dhcp server please!"). With LL addresses getting no routable address is "expected", it isn't an error - the stack just configures an LL address and says "I'm ready, use me" - and the = user believes all is OK - except nothing works. In this situation we = really want things to revert to the "fixed" state as quickly as possible, lest frustration result "where did I get this stupid useless address instead of the one I should have - the network is broken". [Ted Lemon] Right, and if we just don't let the IPv4ll state machine reach out and touch the DHCP state machine, this is precisely what will happen. That is, the DHCP client should never care about IPv4ll. It is helpful, however, for the IPv4ll agent to notice that the DHCP client has timed out in contacting the DHCP server. In this case, the = DHCP client will still configure its interface if it has a valid lease. However, the IPv4ll agent at this point should probably also configure an IPv4ll address, since the address the DHCP client is using is by no means guaranteed to be correct. So simply watching the interface isn't going to get you the best results for IPv4ll, although it's an improvement over having the = IPv4ll agent reaching out and touching the DHCP client. [Robert Elz] | In this case, the DHCP client | will still configure its interface if it has a valid lease. Yes, and in most circumstances where that happens, that address will work just as well as a LL address (the DHCP client is supposed to verify that the lease still makes some kind of sense - it needs to do that to choose between the several valid leases it might have from past assignments (I've had clients allocated multi-year leases from some weird servers, and sometimes had several of those simultaneously). If the DHCP client checks that the address seems functional before = assigning it, then the LL address would only be useful in the rarest cases. | However, the IPv4ll agent at this point should probably also = configure | an IPv4ll address, since the address the DHCP client is using is by = no | means guaranteed to be correct. That's true - but no-one knows. The DHCP client doesn't (if it knew it was incorrect, it would not configure it, to know it is correct it needs a DHCP server response, which we are assuming does not happen), the LL assignment machinery has no idea, it just sees a non-LL address (and perhaps the DHCP timeout), but more than that, none of the applications that are to use the address know either. They're going to be faced = with the situation of having a choice of 2 local addresses to use, and no = idea which one is going to work better. In most cases, the (old) DHCP = address will work fine, and probably reach more destinations than the LL = address, so in most cases that is what the applications are going to want to use, = I suspect. Given that, doing the extra work to assign an LL address in this scenario seems pointless. | So simply watching the interface isn't going to get you the best | results for IPv4ll, If getting the best results for IPv4LL was an objective, I'd probably agree. But it isn't. Rather, IPv4LL is an attempt to get the best results for the system (or more likely, the system's user). That is, it doesn't matter in the slightest if IPv4LL fails miserably, as long as the end result is correct, and communications get established, at least in the vast majority of cases. [Erik Guttman] The text supplied by Bernard has the property that it does not specify any new behavior for DHCP. The new text makes it clear that an implementation of IPv4LL must attempt to obtain configuration via DHCP according to the DHCP specification, even if it has failed to in the past. I think this satisfies Ted's concern: Ted Lemon wrote: > The correct fix is to make sure that the DHCP client does not in fact > modify its behaviour to make IPv4ll work, but rather to modify IPv4ll > so that it doesn't interfere with the operation of the DHCP client. --__--__-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg End of dhcwg Digest _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 20:22:31 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22247; Tue, 30 Sep 2003 20:22:31 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Ukj-0007Ne-0T; Tue, 30 Sep 2003 20:22:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4Ujx-0007IE-BF for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 20:21:13 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22185 for ; Tue, 30 Sep 2003 20:21:05 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4Ujv-0007Ba-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 20:21:11 -0400 Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx with esmtp (Exim 4.12) id 1A4Uju-0007Ad-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 20:21:10 -0400 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0HM100L01YAFMS@mailout1.samsung.com> for dhcwg@ietf.org; Wed, 01 Oct 2003 09:20:39 +0900 (KST) Received: from ep_mmp2 (localhost [127.0.0.1]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0HM100FPRYAE15@mailout1.samsung.com> for dhcwg@ietf.org; Wed, 01 Oct 2003 09:20:39 +0900 (KST) Received: from daniel ([168.219.203.183]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0HM1000ZYYAEL5@mmp2.samsung.com> for dhcwg@ietf.org; Wed, 01 Oct 2003 09:20:38 +0900 (KST) Date: Wed, 01 Oct 2003 09:20:48 +0900 From: Soohong Daniel Park To: dhcwg@ietf.org Cc: "'Soohong Daniel Park'" Message-id: <005101c387b1$dd115e50$b7cbdba8@daniel> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [dhcwg] Rapid Commit Option 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 all I am so confusing what meaning of "Rapid Commit Option" is in DHCPv6. By this option, I can get a NEW address from DHCPv6 as soon as possible, just 2 messages exchange. Correct ? ... What is the original purpose of this option ? Could anyone please clarify that ? Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Sep 30 22:50:26 2003 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26253; Tue, 30 Sep 2003 22:50:26 -0400 (EDT) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4X3y-0006si-KW; Tue, 30 Sep 2003 22:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1A4X3L-0006sI-4y for dhcwg@optimus.ietf.org; Tue, 30 Sep 2003 22:49:23 -0400 Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26210 for ; Tue, 30 Sep 2003 22:49:13 -0400 (EDT) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1A4X3H-0000p6-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 22:49:19 -0400 Received: from aphrodite.gwi.net ([207.5.128.164]) by ietf-mx with esmtp (Exim 4.12) id 1A4X3G-0000p1-00 for dhcwg@ietf.org; Tue, 30 Sep 2003 22:49:18 -0400 Received: from BVolz (d-216-195-132-224.metrocast.net [216.195.132.224]) by aphrodite.gwi.net (8.12.6p3/8.12.6) with ESMTP id h912n7Yp069061; Tue, 30 Sep 2003 22:49:15 -0400 (EDT) (envelope-from volz@metrocast.net) From: "Bernie Volz" To: "'Soohong Daniel Park'" , Subject: RE: [dhcwg] Rapid Commit Option Date: Tue, 30 Sep 2003 22:49:15 -0400 Message-ID: <000001c387c6$9db0a620$6701a8c0@BVolz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4510 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal In-Reply-To: <005101c387b1$dd115e50$b7cbdba8@daniel> Content-Transfer-Encoding: quoted-printable 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: quoted-printable Soohong: That is correct. If the server(s) allow the rapid commit, the client can = get a committed address (and configuration information) in just 2 messages ("request" and "reply") instead of the standard 4-message exchange. There is a cost of this if there are multiple servers active (since they would all assign addresses/configuration information) and have no idea = which the client selected. (Though with IPv6 addresses, this is probably not = of any major concern as there are plenty of addresses available.) Please note that servers may not honor this (either because they don't implement it or have been configured to not honor it). So, clients must always be ready for the full 4-message exchange. - Bernie -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Soohong Daniel Park Sent: Tuesday, September 30, 2003 8:21 PM To: dhcwg@ietf.org Cc: 'Soohong Daniel Park' Subject: [dhcwg] Rapid Commit Option Hi all I am so confusing what meaning of "Rapid Commit Option" is in DHCPv6. By this option, I can get a NEW address from DHCPv6=20 as soon as possible, just 2 messages exchange. Correct ? ...=20 What is the original purpose of this option ? Could anyone please clarify that ? Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory, SAMSUNG Electronics _______________________________________________ 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