Interpretation of Option 60 (Vendor Class ID)

From daemon@optimus.ietf.org Thu May 2 05:51:29 2002 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 FAA05461 for ; Thu, 2 May 2002 05:51:28 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA23443 for dhcwg-archive@odin.ietf.org; Thu, 2 May 2002 05:51:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA23218; Thu, 2 May 2002 05:49:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA10350 for ; Tue, 30 Apr 2002 13:29:19 -0400 (EDT) Received: from haydn.spinweb.net (haydn.spinweb.net [161.58.226.153]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29953 for ; Tue, 30 Apr 2002 13:29:15 -0400 (EDT) Received: from rsand ([212.130.80.194]) by haydn.spinweb.net (8.11.6) id g3UHTGh71904; Tue, 30 Apr 2002 12:29:16 -0500 (EST) Message-ID: <002901c1f06c$8e527f70$0101010a@netegrity.com> From: "Richard Sand" To: Date: Tue, 30 Apr 2002 19:29:11 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C1F07D.4E5D7350" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Subject: [dhcwg] how to assign a netmask to a static route parameter Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C1F07D.4E5D7350 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all- I've configured a dhcp server (solaris) to serve information on = static route configurations to our dhcp clients. I got the server to = serve the static routes (via the StaticRt symbol). Works great. Now = the only problem is that my DHCP clients (i.e. windoze2k) are setting a netmask of 255.255.255.255 for the routes. In other words, I'm setting = via DHCP that the address 192.168.0.0 is routed through 10.1.1.2 with = the sincere hope that the dhcp clients will use the netmask 255.255.0.0 = for that static route. No such luck. The netmask is 255.255.255.255. How to I specify a netmask for a static route from a DHCP server? Thanks! Best regards, Richrad ------=_NextPart_000_0026_01C1F07D.4E5D7350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all- I've configured a dhcp server = (solaris) to=20 serve information on static route configurations to our dhcp clients.=20 I got the server to serve the static = routes (via=20 the StaticRt symbol). Works great. Now the = only=20 problem is that my DHCP clients (i.e. windoze2k) are setting = a
netmask of=20 255.255.255.255 for the routes. In other words, I'm setting via = DHCP that=20 the address 192.168.0.0 is routed through 10.1.1.2 with the sincere hope that the dhcp clients will use the = netmask=20 255.255.0.0 for that static route. No such luck. The netmask = is=20 255.255.255.255.

How to I specify a netmask for a static = route from=20 a DHCP server?

Thanks!

Best regards,

Richrad

------=_NextPart_000_0026_01C1F07D.4E5D7350-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Thu May 2 19:04:12 2002 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 TAA18994 for ; Thu, 2 May 2002 19:04:12 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA15610 for dhcwg-archive@odin.ietf.org; Thu, 2 May 2002 19:04:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA15455; Thu, 2 May 2002 19:02:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA14435 for ; Thu, 2 May 2002 18:45:58 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA16989; Thu, 2 May 2002 18:45:53 -0400 (EDT) Message-Id: <200205022245.SAA16989@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Thu, 02 May 2002 18:45:53 -0400 Subject: [dhcwg] Last Call: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The IESG has received a request from the Dynamic Host Configuration Working Group to consider Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 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 May 15, 2002. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-24.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Fri May 3 07:37:36 2002 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 HAA09963 for ; Fri, 3 May 2002 07:37:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA29844 for dhcwg-archive@odin.ietf.org; Fri, 3 May 2002 07:37:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28762; Fri, 3 May 2002 07:27:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28733 for ; Fri, 3 May 2002 07:27:35 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09424; Fri, 3 May 2002 07:27:29 -0400 (EDT) Message-Id: <200205031127.HAA09424@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, 03 May 2002 07:27:29 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org --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 : DNS Configuration Options for DHCPv6 Author(s) : R. Droms Filename : draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt Pages : 6 Date : 02-May-02 This document describes DHCPv6 options for passing a list of available DNS Servers and a domain search list to a client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-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-dhcpv6-opt-dnsconfig-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-dhcpv6-opt-dnsconfig-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: <20020502130811.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020502130811.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@ns.ietf.org Mon May 6 11:00:39 2002 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 LAA22331 for ; Mon, 6 May 2002 11:00:39 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA26012 for dhcwg-archive@odin.ietf.org; Mon, 6 May 2002 11:00:44 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA25168; Mon, 6 May 2002 10:50:34 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22273 for ; Mon, 6 May 2002 10:01:42 -0400 (EDT) Received: from netcore.fi (netcore.fi [193.94.160.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19475; Mon, 6 May 2002 10:01:33 -0400 (EDT) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id g46E15F27327; Mon, 6 May 2002 17:01:08 +0300 Date: Mon, 6 May 2002 17:01:05 +0300 (EEST) From: Pekka Savola To: iesg@ietf.org cc: dhcwg@ietf.org In-Reply-To: <200205022245.SAA16989@ietf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Re: Last Call: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org On Thu, 2 May 2002, The IESG wrote: > > The IESG has received a request from the Dynamic Host Configuration > Working Group to consider Dynamic Host Configuration Protocol for > IPv6 (DHCPv6) 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 May 15, 2002. > > Files can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-24.txt IPv6 working group has discussed a possibility of using a light-weight DHCPv6 solution for e.g. DNS configuration, but nothing related to address allocation. I threw up this idea and there was some support for it. Many people are a bit unconfortable with "legacy" parts of DHCPv6, that aren't really all that necessary with IPv6. And these features are the ones that most people will not need. So I see two practical approaches: 1) separate the draft to: a) Dynamic Node Configuration Protocol, which is used for Informational Records only (the main specification) b) XXX, which is used when one wants the "stateful" parts, e.g. address allocation. This has the great benefit that when the vast majority of people are only interested about a), the base specification would become very simple and relatively short. The drawback naturally is that this requires more work.. 2) after publishing the draft as is, later come back and specify which parts of the DHCPv6 protocol to implement to get either a). This has the drawback that those that are only intrerested about the lightweight solution have to go through the whole of DHCPv6, and that conceptually separating the two might be difficult. Needless to say, I'm in the favor of 1); I've never been a big fan of the idea behind DHCPv6, but this way I'd find it rather interesting, for solving the initial configuration problem. --8<-- Date: Mon, 18 Mar 2002 19:09:14 +0200 (EET) From: Pekka Savola To: rdroms@cisco.com Cc: ipng@sunroof.eng.sun.com Subject: Stateless DHCP and the DHCP draft Hi, Would it make sense to consider whether separating "stateless DHCPv6" and the stateful part (~address assignment) to separate drafts would make sense? I think a lot more people would be confortable with DHCPv6 if it was very simple and supported only the informational records most people would only use.. and stateful address and such specified in a separate draft? Just a thought... --8<-- -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue May 7 05:33:22 2002 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 FAA00915 for ; Tue, 7 May 2002 05:33:22 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA10435 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 05:33:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10359; Tue, 7 May 2002 05:31:35 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA10328 for ; Tue, 7 May 2002 05:31:34 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA00871 for ; Tue, 7 May 2002 05:31:27 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-35.cisco.com [10.82.224.35]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA01003 for ; Tue, 7 May 2002 05:31:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20020507052110.0373c8c0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 May 2002 05:30:54 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Last call on two DHCPv6 docs Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org These two docs were originally part of the DHCPv6 draft that went through WG last call: draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt draft-ietf-dhc-dhcpv6-opt-dstm-01.txt Unless there is an objection by 5PM Wed, 5/8, I will request IETF last call on these docs. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue May 7 08:39:19 2002 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 IAA05109 for ; Tue, 7 May 2002 08:39:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21487 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 08:39:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21377; Tue, 7 May 2002 08:37:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21352 for ; Tue, 7 May 2002 08:37:41 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04971 for ; Tue, 7 May 2002 08:37:34 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-35.cisco.com [10.82.224.35]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA05768 for ; Tue, 7 May 2002 08:37:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20020507083030.03778c30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 May 2002 08:37:04 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Scheduling for IETF 54 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I'm about to make a request for a meeting slot for the DHC WG at IETF 54. Please get back to me by 9AM EDT Fri, 5/10, to let me know about any WGs you'd like to avoid conflicting with the DHC WG meeting. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue May 7 08:42:54 2002 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 IAA05262 for ; Tue, 7 May 2002 08:42:45 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA21862 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 08:42:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21654; Tue, 7 May 2002 08:41:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21631 for ; Tue, 7 May 2002 08:41:13 -0400 (EDT) Received: from mail02.vsnl.net (mail02.vsnl.net [203.197.12.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05150 for ; Tue, 7 May 2002 08:40:38 -0400 (EDT) Received: from Sudheesh ([203.115.109.66]) by mail02.vsnl.net (Netscape Messaging Server 4.15) with ESMTP id GVQR7V01.1UU for ; Tue, 7 May 2002 18:10:43 +0530 Message-ID: <000a01c1f5c4$9efc3b10$de00000a@Sudheesh> From: "Sudheesh" To: Date: Tue, 7 May 2002 18:12:15 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Any method to get the physical address ? Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, I would like to know if there is any OS independant method to resolve the physical address of my ethernet adapter. thanks in advance Sudheesh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue May 7 08:58:18 2002 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 IAA05867 for ; Tue, 7 May 2002 08:58:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA22449 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 08:58:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22356; Tue, 7 May 2002 08:56:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22328 for ; Tue, 7 May 2002 08:56:10 -0400 (EDT) Received: from atlrel8.hp.com (atlrel8.hp.com [156.153.255.206]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05751 for ; Tue, 7 May 2002 08:56:01 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel8.hp.com (Postfix) with ESMTP id 62D9BA00430; Tue, 7 May 2002 08:55:30 -0400 (EDT) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id SAA28660; Tue, 7 May 2002 18:20:22 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Ralph Droms'" , Subject: RE: [dhcwg] Last call on two DHCPv6 docs Date: Tue, 7 May 2002 18:27:21 +0530 Message-ID: <002401c1f5c6$ba758c00$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <4.3.2.7.2.20020507052110.0373c8c0@funnel.cisco.com> Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit The Domain Name Server option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. The Domain Search List option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. Do these options really need to appear in all the above mesg types? Because, for all the messages originating from client, ORO option filled with DNS server/ Domain Search list option number will do. If there are muliple options the client is requesting, this will save some bytes also, if ORO is used for this. I feel that only in Reply message, this is needed. > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Ralph Droms > Sent: Tuesday, May 07, 2002 3:01 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Last call on two DHCPv6 docs > > > These two docs were originally part of the DHCPv6 draft that > went through > WG last call: > > draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt > draft-ietf-dhc-dhcpv6-opt-dstm-01.txt > > Unless there is an objection by 5PM Wed, 5/8, I will request > IETF last call > on these docs. > > - Ralph Droms > > > > _______________________________________________ > 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 daemon@optimus.ietf.org Tue May 7 09:36:09 2002 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 JAA07491 for ; Tue, 7 May 2002 09:36:09 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA25573 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 09:36:16 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25399; Tue, 7 May 2002 09:34:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25372 for ; Tue, 7 May 2002 09:34:38 -0400 (EDT) Received: from portal.incognito.com (PORTAL.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07400 for ; Tue, 7 May 2002 09:34:30 -0400 (EDT) Received: from homerdmz.incognito.com ([207.102.214.106] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 175501-0008Cg-00 for dhcwg@ietf.org; Tue, 07 May 2002 06:27:25 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <2ZV8S1HV>; Tue, 7 May 2002 06:40:31 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198692A12@homer.incognito.com.> From: "Cosmo, Patrick" To: dhcwg@ietf.org Date: Tue, 7 May 2002 06:40:31 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F5CC.C169BB70" Subject: [dhcwg] Interpretation of Option 60 (Vendor Class ID) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F5CC.C169BB70 Content-Type: text/plain; charset="windows-1252" RFC 2132 states that option 60 "is a string of n octets". We are having a little debate about how to interpret this and would like to know how others, and the working group, interpret this option. Some of us feel that "octet != character" and that this _could_ be binary data. On the other hand, none of us are aware of any devices that send binary (non-ascii) data for this option. This reinforces the opinion that the term "string" implies a character string. Some of us all do not feel that the word "octet" necessarily implies that these are not characters: since an "octet" and a "character" are both a single byte, and for some character tables (ISO-Latin-1) all values 1 - 254 are used as characters, with 0 being the string termination character, the word "octet" does not necessarily indicate that that this is binary data. comments? does anyone know of any devices that send data for this option which cannot be interpreted as a string? ------_=_NextPart_001_01C1F5CC.C169BB70 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Interpretation of Option 60 (Vendor Class ID)

RFC 2132 states that option 60 "is a string of n = octets". We are having a little debate about how to interpret this = and would like to know how others, and the working group, interpret = this option.

Some of us feel that "octet !=3D character" = and that this _could_ be binary data.

On the other hand, none of us are aware of any = devices that send binary (non-ascii) data for this option. This = reinforces the opinion that the term "string" implies a = character string. Some of us all do not feel that the word = "octet" necessarily implies that these are not characters: = since an "octet" and a "character" are both a = single byte, and for some character tables (ISO-Latin-1) all values 1 - = 254 are used as characters, with 0 being the string termination = character, the word "octet" does not necessarily indicate = that that this is binary data.

comments?

does anyone know of any devices that send data for = this option which cannot be interpreted as a string?

------_=_NextPart_001_01C1F5CC.C169BB70-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue May 7 10:56:34 2002 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 KAA10895 for ; Tue, 7 May 2002 10:56:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA01556 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 10:56:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01111; Tue, 7 May 2002 10:49:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA01063 for ; Tue, 7 May 2002 10:49:40 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10597 for ; Tue, 7 May 2002 10:49:34 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g47EnAi16875 for ; Tue, 7 May 2002 09:49:10 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g47En9I08200 for ; Tue, 7 May 2002 09:49:10 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Tue May 07 09:49:08 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 7 May 2002 09:49:08 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D39F@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'vijayak@india.hp.com'" , "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Last call on two DHCPv6 docs Date: Tue, 7 May 2002 09:49:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F5D6.5584FD70" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F5D6.5584FD70 Content-Type: text/plain; charset="iso-8859-1" I think the intended meaning here is that these options are only allowed in these messages and no others. For example, a Domain Name Server option may not appear in a Relay-Forw/-Reply. This was not intended to mean that the option MUST appear in each of these messages; just that it may. The likely usage is as follows: Solicit - In ORO Advertise - Option will appear since it is telling the client what it may get Request - In ORO Confirm - Option may appear since it might be useful in validating whether the client is on the correct link. Renew/Rebind- Option or in ORO Information-Request - In ORO or Option if Reconfigure response? Reply - Option - Bernie -----Original Message----- From: Vijayabhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, May 07, 2002 8:57 AM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] Last call on two DHCPv6 docs The Domain Name Server option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. The Domain Search List option MUST appear only in the following messages: Solicit, Advertise, Request, Confirm, Renew, Rebind, Information-Request, Reply. Do these options really need to appear in all the above mesg types? Because, for all the messages originating from client, ORO option filled with DNS server/ Domain Search list option number will do. If there are muliple options the client is requesting, this will save some bytes also, if ORO is used for this. I feel that only in Reply message, this is needed. > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Ralph Droms > Sent: Tuesday, May 07, 2002 3:01 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Last call on two DHCPv6 docs > > > These two docs were originally part of the DHCPv6 draft that > went through > WG last call: > > draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt > draft-ietf-dhc-dhcpv6-opt-dstm-01.txt > > Unless there is an objection by 5PM Wed, 5/8, I will request > IETF last call > on these docs. > > - Ralph Droms > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F5D6.5584FD70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Last call on two DHCPv6 docs

I think the intended meaning here is that these = options are only allowed in these messages and no others. For example, = a Domain Name Server option may not appear in a = Relay-Forw/-Reply.

This was not intended to mean that the option MUST = appear in each of these messages; just that it may.

The likely usage is as follows:
        Solicit - = In ORO
        Advertise       - Option will = appear since it is telling the client what it may get
        Request - = In ORO
        Confirm - = Option may appear since it might be useful in validating whether the = client is on the correct link.
        Renew/Rebind- Option or in ORO
        Information-Request - In ORO or Option if Reconfigure = response?
        Reply           - = Option

- Bernie

-----Original Message-----
From: Vijayabhaskar A K [mailto:vijayak@india.hp.com]
Sent: Tuesday, May 07, 2002 8:57 AM
To: 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] Last call on two DHCPv6 = docs

The Domain Name Server option MUST appear only in the = following
messages: Solicit, Advertise, Request, = Confirm, Renew, Rebind,
Information-Request, Reply.

The Domain Search List option MUST appear only in the = following
messages: Solicit, Advertise, Request, = Confirm, Renew, Rebind,
Information-Request, Reply.

Do these options really need to appear in all the = above mesg types?
Because, for all the messages originating from = client, ORO option
filled with DNS server/ Domain Search list option = number will do.
If there are muliple options the client is = requesting, this
will save some bytes also, if ORO is used for = this.
I feel that only in Reply message, this is = needed.

> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On = Behalf Of
> Ralph Droms
> Sent: Tuesday, May 07, 2002 3:01 PM
> To: dhcwg@ietf.org
> Subject: [dhcwg] Last call on two DHCPv6 = docs
>
>
> These two docs were originally part of the = DHCPv6 draft that
> went through
> WG last call:
>
> draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt
> draft-ietf-dhc-dhcpv6-opt-dstm-01.txt
>
> Unless there is an objection by 5PM Wed, 5/8, I = will request
> IETF last call
> on these docs.
>
> - Ralph Droms
>
>
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

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

------_=_NextPart_001_01C1F5D6.5584FD70-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue May 7 11:33:42 2002 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 LAA12723 for ; Tue, 7 May 2002 11:33:42 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05226 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 11:33:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04533; Tue, 7 May 2002 11:30:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04507 for ; Tue, 7 May 2002 11:30:02 -0400 (EDT) Received: from fep04-svc.swip.net (fep04.swip.net [130.244.199.132]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12501 for ; Tue, 7 May 2002 11:29:55 -0400 (EDT) Received: from there ([193.12.201.10]) by fep04-svc.swip.net with SMTP id <20020507152928.MCOH29474.fep04-svc.swip.net@there>; Tue, 7 May 2002 17:29:28 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: "Cosmo, Patrick" Subject: Re: [dhcwg] Interpretation of Option 60 (Vendor Class ID) Date: Tue, 7 May 2002 16:36:52 +0200 X-Mailer: KMail [version 1.3.2] References: <4FB49E60CFBA724E88867317DAA3D198692A12@homer.incognito.com.> In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198692A12@homer.incognito.com.> Cc: dhcwg@ietf.org MIME-Version: 1.0 Message-Id: <20020507152928.MCOH29474.fep04-svc.swip.net@there> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id LAA04508 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit On Tuesday 07 May 2002 15.40, you wrote: > RFC 2132 states that option 60 "is a string of n octets". We are having a > little debate about how to interpret this and would like to know how > others, and the working group, interpret this option. I went back and forth on this, and finally decided the best approach was to present it as a string, but allow escape sequences in the string so the user can at least work with non-printable characters if need be. > does anyone know of any devices that send data for this option which cannot > be interpreted as a string? Experience with my customer base has shown that they (and/or their devices) expect it to be a string. 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 daemon@optimus.ietf.org Tue May 7 12:03:05 2002 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 MAA13900 for ; Tue, 7 May 2002 12:03:05 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA08366 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 12:03:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06613; Tue, 7 May 2002 11:58:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06582 for ; Tue, 7 May 2002 11:58:49 -0400 (EDT) Received: from c015.snv.cp.net (h012.c015.snv.cp.net [209.228.35.127]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13742 for ; Tue, 7 May 2002 11:58:42 -0400 (EDT) Received: (cpmta 28976 invoked from network); 7 May 2002 08:58:18 -0700 Received: from 4.36.57.222 (HELO STEVEPC) by smtp.relicore.com (209.228.35.127) with SMTP; 7 May 2002 08:58:18 -0700 X-Sent: 7 May 2002 15:58:18 GMT From: "Steve Gonczi" To: "Cosmo, Patrick" Cc: Subject: RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID) Date: Tue, 7 May 2002 11:53:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0004_01C1F5BD.DB727520" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198692A12@homer.incognito.com.> Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. ------=_NextPart_000_0004_01C1F5BD.DB727520 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Interpretation of Option 60 (Vendor Class ID)IMHO it is meant to be an array of unsigned bytes. The authors would have spelled out any formatting restrictions, such as a specific character set, or required zero termination if they had that in mind. You will see that they did so in other cases. ( e.g.: section 9.9). Because the authors did not restrict the allowed octet values in any way, we can not safely use a zero termination convention. ( embedded zeros are allowed by the definition) /sG -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Cosmo, Patrick Sent: Tuesday, May 07, 2002 9:41 AM To: dhcwg@ietf.org Subject: [dhcwg] Interpretation of Option 60 (Vendor Class ID) RFC 2132 states that option 60 "is a string of n octets". We are having a little debate about how to interpret this and would like to know how others, and the working group, interpret this option. ------=_NextPart_000_0004_01C1F5BD.DB727520 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Interpretation of Option 60 (Vendor Class ID)

IMHO=20 it is meant to be an array of unsigned bytes.

The=20 authors would have spelled out any formatting restrictions, such as a=20 specific

character set, or required zero termination = if they=20 had that in mind.

You=20 will see that they did so in other cases. ( e.g.: section=20 9.9).

Because the authors did not restrict the = allowed octet=20 values in any way, we can not safely

use a=20 zero termination convention. ( embedded zeros are allowed by the=20 definition)

/sG

-----Original Message-----
From: = dhcwg-admin@ietf.org=20 [mailto:dhcwg-admin@ietf.org]On Behalf Of Cosmo,=20 Patrick
Sent: Tuesday, May 07, 2002 9:41 AM
To:=20 dhcwg@ietf.org
Subject: [dhcwg] Interpretation of Option 60 = (Vendor=20 Class ID)

RFC 2132 states that option 60 "is a = string of=20 n octets". We are having a little debate about how to interpret this = and would=20 like to know how others, and the working group, interpret this=20 option.

------=_NextPart_000_0004_01C1F5BD.DB727520-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue May 7 12:57:24 2002 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 MAA15660 for ; Tue, 7 May 2002 12:57:24 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11249 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 12:57:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11127; Tue, 7 May 2002 12:55:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11099 for ; Tue, 7 May 2002 12:55:21 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15539 for ; Tue, 7 May 2002 12:55:13 -0400 (EDT) Received: from BarrH63p601 ([64.170.116.122]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GVR00KGT306RG@mta5.snfc21.pbi.net> for dhcwg@ietf.org; Tue, 07 May 2002 09:55:19 -0700 (PDT) Date: Tue, 07 May 2002 09:54:57 -0700 From: Richard Barr Hibbs Subject: RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID) In-reply-to: <4FB49E60CFBA724E88867317DAA3D198692A12@homer.incognito.com> To: Dhcwg Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: multipart/alternative; boundary="Boundary_(ID_cs62t8PGERKhF89vt+yseA)" Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a multi-part message in MIME format. --Boundary_(ID_cs62t8PGERKhF89vt+yseA) Content-type: text/plain; charset=Windows-1252 Content-Transfer-Encoding: 7BIT Interpretation of Option 60 (Vendor Class ID)If only the language used in the RFCs was always precise, with well-understood meanings for all terms.... Is Vendor Class ID an octet string with no restrictions or a character string? If it is a character string, is it NVT-ASCII, UTF-8, or some other encoding? Is it a null-terminated string? The word "octets" usually appears when no encoding (UTF-8, for example) is implied or required, permitting binary values in the field, while "string" usually means (and sometimes is actually specified in the definition of the option) a character sequence encoded using NVT-ASCII. In my opinion, Option 60 contains an octet string without any assumed encoding. As a practical matter, however, a string containing encoded characters, for example, "SwampRat Model 66R IP Phone," has advantages for implementors and field service technicians. Finally, since all options contain a length octet, a null octet in an octet string is NOT a terminator if it appears within the "n" characters specified in the length octet. There is the interesting case of a mixed encoded, unencoded string, such as

. That might be confusing for simple parsers, but certainly possible. I've never liked the wording of this option description with respect to interpretation by servers of the values, mostly because it provides little guidance to implementors and leaves even the form of the value open to discussion like this message thread. --Barr -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Cosmo, Patrick Sent: Tuesday, May 07, 2002 06:41 RFC 2132 states that option 60 "is a string of n octets". We are having a little debate about how to interpret this and would like to know how others, and the working group, interpret this option. Some of us feel that "octet != character" and that this _could_ be binary data. On the other hand, none of us are aware of any devices that send binary (non-ascii) data for this option. This reinforces the opinion that the term "string" implies a character string. Some of us all do not feel that the word "octet" necessarily implies that these are not characters: since an "octet" and a "character" are both a single byte, and for some character tables (ISO-Latin-1) all values 1 - 254 are used as characters, with 0 being the string termination character, the word "octet" does not necessarily indicate that that this is binary data. --Boundary_(ID_cs62t8PGERKhF89vt+yseA) Content-type: text/html; charset=Windows-1252 Content-Transfer-Encoding: 7BIT Interpretation of Option 60 (Vendor Class ID)

If only the language used in the RFCs was always precise, with well-understood meanings for all terms....

Is Vendor Class ID an octet string with no restrictions or a character string? If it is a character string, is it NVT-ASCII, UTF-8, or some other encoding? Is it a null-terminated string?

The word "octets" usually appears when no encoding (UTF-8, for example) is implied or required, permitting binary values in the field, while "string" usually means (and sometimes is actually specified in the definition of the option) a character sequence encoded using NVT-ASCII.

In my opinion, Option 60 contains an octet string without any assumed encoding. As a practical matter, however, a string containing encoded characters, for example, "SwampRat Model 66R IP Phone," has advantages for implementors and field service technicians.

Finally, since all options contain a length octet, a null octet in an octet string is NOT a terminator if it appears within the "n" characters specified in the length octet.

There is the interesting case of a mixed encoded, unencoded string, such as <character-encoded-part><unencoded-part><character-encoded-part>. That might be confusing for simple parsers, but certainly possible.

I've never liked the wording of this option description with respect to interpretation by servers of the values, mostly because it provides little guidance to implementors and leaves even the form of the value open to discussion like this message thread.

--Barr

-----Original Message-----
From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Cosmo, Patrick
Sent: Tuesday, May 07, 2002 06:41

RFC 2132 states that option 60 "is a string of n octets". We are having a little debate about how to interpret this and would like to know how others, and the working group, interpret this option.

Some of us feel that "octet != character" and that this _could_ be binary data.

On the other hand, none of us are aware of any devices that send binary (non-ascii) data for this option. This reinforces the opinion that the term "string" implies a character string. Some of us all do not feel that the word "octet" necessarily implies that these are not characters: since an "octet" and a "character" are both a single byte, and for some character tables (ISO-Latin-1) all values 1 - 254 are used as characters, with 0 being the string termination character, the word "octet" does not necessarily indicate that that this is binary data.

--Boundary_(ID_cs62t8PGERKhF89vt+yseA)-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue May 7 15:44:30 2002 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 PAA22054 for ; Tue, 7 May 2002 15:44:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA15087 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 15:44:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14666; Tue, 7 May 2002 15:41:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA14469 for ; Tue, 7 May 2002 15:41:35 -0400 (EDT) Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18636 for ; Tue, 7 May 2002 14:01:08 -0400 (EDT) Received: from jurassic.eng.sun.com ([129.146.83.130]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA22338; Tue, 7 May 2002 11:00:45 -0700 (PDT) Received: from sun.com (d-mpk17-86-133.Eng.Sun.COM [129.146.86.133]) by jurassic.eng.sun.com (8.12.3+Sun/8.12.3) with ESMTP id g47I0jUE018025; Tue, 7 May 2002 11:00:45 -0700 (PDT) Message-ID: <3CD81629.2060905@sun.com> Date: Tue, 07 May 2002 11:00:09 -0700 From: Michael Carney Organization: Sun Microsystems, Inc User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4.1) Gecko/20020406 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 To: Steve Gonczi CC: "Cosmo, Patrick" , dhcwg@ietf.org Subject: Re: [dhcwg] Interpretation of Option 60 (Vendor Class ID) References: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Steve Gonczi wrote: > IMHO it is meant to be an array of unsigned bytes. > > > > The authors would have spelled out any formatting restrictions, such as > a specific > > character set, or required zero termination if they had that in mind. > > > > You will see that they did so in other cases. ( e.g.: section 9.9). > > > > Because the authors did not restrict the allowed octet values in any > way, we can not safely > > use a zero termination convention. ( embedded zeros are allowed by the > definition) Sigh. Actually, it was intended to be an ASCII (printable) string of some value to the client vendor (OS). To the server(s), it's just an opaque string of characters. I originally wrote the text for this back in '93. I suspect my fervor for ensuring that servers would treat the value as opaque lead to my use the term "octets". [Diving under desk to avoid incoming missiles ;^)] > > > > /sG > > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Cosmo, Patrick > Sent: Tuesday, May 07, 2002 9:41 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Interpretation of Option 60 (Vendor Class ID) > > RFC 2132 states that option 60 "is a string of n octets". We are > having a little debate about how to interpret this and would like to > know how others, and the working group, interpret this option. > > > -- Mike Carney Sun Microsystems, Inc. Solaris Networking Technology Mailstop UMPK17-202 The noise electric never stops 901 San Antonio Rd (650) 786-4171 Palo Alto, CA 94303 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Tue May 7 19:55:45 2002 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 TAA27368 for ; Tue, 7 May 2002 19:55:44 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA28958 for dhcwg-archive@odin.ietf.org; Tue, 7 May 2002 19:55:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28791; Tue, 7 May 2002 19:51:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA28766 for ; Tue, 7 May 2002 19:51:40 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA27297 for ; Tue, 7 May 2002 19:51:31 -0400 (EDT) Received: from BarrH63p601 ([64.170.116.122]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GVR00A13MA1XZ@mta5.snfc21.pbi.net> for dhcwg@ietf.org; Tue, 07 May 2002 16:51:38 -0700 (PDT) Date: Tue, 07 May 2002 16:51:15 -0700 From: Richard Barr Hibbs Subject: RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID) In-reply-to: <3CD81629.2060905@sun.com> To: Michael Carney , Steve Gonczi Cc: "Cosmo, Patrick" , dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=Windows-1252 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7BIT > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Michael Carney > Sent: Tuesday, May 07, 2002 11:00 > > > Steve Gonczi wrote: > > > IMHO it is meant to be an array of unsigned bytes. > > > > The authors would have spelled out any formatting restrictions, such as > > a specific character set, or required zero termination if they had that > > in mind. > > > > You will see that they did so in other cases. ( e.g.: section 9.9). > > > > Because the authors did not restrict the allowed octet values in any > > way, we can not safely use a zero termination convention. ( embedded > > zeros are allowed by the definition) > > > Sigh. Actually, it was intended to be an ASCII (printable) string of > some value to the client vendor (OS). To the server(s), it's just an > opaque string of characters. I originally wrote the text for this back > in '93. I suspect my fervor for ensuring that servers would treat the > value as opaque lead to my use the term "octets". > > [Diving under desk to avoid incoming missiles ;^)] > no missiles, brickbats, or other detritus.... when I re-read this section of the RFC earlier today, I was left with the impression that the octet string was NOT opaque, else it would be impossible for the vendor to "...choose to define specific vendor class identifiers to convey particular configuration or other identification information about a client," or to "...encode the client's hardware configuration," which would be the basis for an Option 43 reply. *sigh* Mike, I agree that a character-encoded identifier is often much easier for implementors and technicians, but I'm not sure that the string is necessarily opaque to be useful. An opaque string would imply that the vendor supplies some magic values to be returned in option 43 if a specific string is encountered in option 60 -- the server need not interpret the value of option 60, just recognize it. But my sense is that option 60 is just one piece of information used by a server to formulate an option 43 response, which means that the server must have some idea of the "meaning" of the vendor class identifier. Having said that, I think a perfectly valid use of option 60 does not require option 43 in the response. For example, suppose you had a hardware printer server that would fail to initialize properly if sent an option it did not expect, but it sent a unique class identifier. A DHCP server could then avoid sending things unrecognized by the device, such as "Default IRC Server," and not send anything at all in option 43. Ain't semantics, syntax, and semiotics wunnerful?? --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 00:19:40 2002 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 AAA02911 for ; Wed, 8 May 2002 00:19:40 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA11008 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 00:19:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA10940; Wed, 8 May 2002 00:17:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA10917 for ; Wed, 8 May 2002 00:17:53 -0400 (EDT) Received: from hindon.hss.co.in ([202.54.26.202]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02855 for ; Wed, 8 May 2002 00:17:46 -0400 (EDT) From: animesh@hss.hns.com Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id g484IQc03533 for ; Wed, 8 May 2002 09:48:26 +0530 (IST) Received: from sandesh.hss.hns.com (localhost [127.0.0.1]) by ultra.hss.co.in (8.10.0/8.10.0) with SMTP id g484IPk03043 for ; Wed, 8 May 2002 09:48:26 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256BB3.00174F53 ; Wed, 8 May 2002 09:44:36 +0530 X-Lotus-FromDomain: HSS To: dhcwg@ietf.org Message-ID: <65256BB3.00174D08.00@sandesh.hss.hns.com> Date: Wed, 8 May 2002 09:47:21 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [dhcwg] un-subscribe Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Please remove my mail id from the list DISCLAIMER: This message is proprietary to Hughes Software Systems Limited (HSS) and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. HSS accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 10:02:14 2002 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 KAA07683 for ; Wed, 8 May 2002 10:02:14 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29125 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 10:02:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28545; Wed, 8 May 2002 09:59:41 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28524 for ; Wed, 8 May 2002 09:59:40 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07493 for ; Wed, 8 May 2002 09:59:31 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48DxX64078556 for ; Wed, 8 May 2002 09:59:33 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48DxXQ183732 for ; Wed, 8 May 2002 09:59:33 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48DxvY18754 for ; Wed, 8 May 2002 09:59:57 -0400 Message-Id: <200205081359.g48DxvY18754@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 09:59:57 -0400 From: Thomas Narten Subject: [dhcwg] draft-ietf-dhc-dhcpv6-24.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I've done a review of the lastest rev. Overall, this document seems to be in pretty good shape. But I have some additional questions and comments regarding some issues. I will be sending out a number of followup notes (with subjects identifying the issue) to help focus discussion. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 10:11:18 2002 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 KAA08130 for ; Wed, 8 May 2002 10:11:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA29535 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 10:11:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29282; Wed, 8 May 2002 10:06:53 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29254 for ; Wed, 8 May 2002 10:06:52 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07857 for ; Wed, 8 May 2002 10:06:42 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48E6o64141372 for ; Wed, 8 May 2002 10:06:50 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48E6mQ54380 for ; Wed, 8 May 2002 10:06:48 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48E7BI18794 for ; Wed, 8 May 2002 10:07:11 -0400 Message-Id: <200205081407.g48E7BI18794@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 10:07:11 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: use of DNS names in DUIDs Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The document makes references to DNS names in two places: > 9.3. Vendor-assigned unique ID based on Domain Name (VUID-DN) > > The vendor-assigned unique ID based on the domain name consists of a > two-octet value giving the length of the identifier, the value of the > identifier and the vendor's registered domain name. I don't think VUID-DN format is needed and would suggest simply removing it. Rational: DNS names are NOT permanent identifiers. For example, registrars can reclaim DNS names if the renewal fees are not paid, if there disputes of trademark, etc. Thus, these may be less permanent than appears. Second, they don't seem to provide any additional benefits/functionality compared with VUID-EN. In those DUIDs, an enterprise number provides the global uniqueness. Enterprise numbers were defined precisely for this purpose, are permanent, and are easy to get. > 8. Representation and use of domain names > > So that domain names may be encoded uniformly and compactly, a > domain name or a list of domain names is encoded using the technique > described in sections 3.1 and 4.1.4 of RFC1035 [12]. Section 4.1.4 > of RFC1035 describes how more than one domain name can be represented > in a list of domain names. For use in this specification, in a > list of domain names, the compression pointer (see section 4.1.4 of > RFC1035) refers to the offset within the list. I don't think this needs to be in the base document. Nowhere does the base spec use DNS names according to this format. Thus, there is nothing to implement. Note that VUID-DN mentioned above doesn't use this format (is that a bug?) -- it seems to use an ascii string (which, BTW, is probably not really what is needed, given a future with I18N DNS names). When an option gets defined that encodes a DNS name, that is where the above text needs to be specified. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:01:36 2002 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 LAA10745 for ; Wed, 8 May 2002 11:01:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA03669 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:01:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA03011; Wed, 8 May 2002 10:59:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA02981 for ; Wed, 8 May 2002 10:59:16 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10616 for ; Wed, 8 May 2002 10:59:07 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48ExF64029672 for ; Wed, 8 May 2002 10:59:15 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48Ex5Q235052 for ; Wed, 8 May 2002 10:59:05 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48ExTa19129 for ; Wed, 8 May 2002 10:59:29 -0400 Message-Id: <200205081459.g48ExTa19129@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 10:59:29 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: use of anycast Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Seems to me that the anycast text is a bit underspecified. It's also not clear to me exactly what problem the anycast text is trying to address. > 13. Transmission of messages by a client > > Unless otherwise specified, a client sends DHCP messages to the > All_DHCP_Relay_Agents_and_Servers or the DHCP_Anycast address. This is ambiguous. What should clients actually implement by default? This document should make it clear what clients should implement. For example try one and if it doesn't work, try the other? Leaving when to use anycast to the implementor without guidelines will likely lead to interoperability problems, with different implementations doing different things. > If the client is attached to a link that supports multicast > transmission, the client sends DHCP messages to the > All_DHCP_Relay_Agents_and_Servers address. If the client is My understanding is that all IPv6 links support multicast by definition. If the underlying network doesn't, it must be emulated. Note that multicast is needed for Neighbor Discovery, which all IPv6 nodes have to implement. > When a client sends a DHCP message to the DHCP_Anycast address, it > MUST use an address assigned to the interface for which the client > is interested in obtaining configuration, which is suitable for use > by the server in responding to the client, as the source address in > the header of the IP datagram. See "Default Address Selection for > IPv6" [4] for more details. Don't you also need to say that anycast can only be used if the client already has a properly scoped address? It seems to me that anycast isn't very useful for the *client*. I.e, let it always send to the relay agent and let the relay agent deal with anycast vs. mcast. Or, is this specifically restricted to the information-request message? If so, might be good to say that. In private mail, Ralph asked: > Good question to ask...How about words to the effect of "if the link is > connected to an NBMA link, use anycast; otherwise, use multicast"? What is an NBMA link? Who defines what that is? I'm not sure there is a well-defined definition of NBMA link. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:08:26 2002 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 LAA11085 for ; Wed, 8 May 2002 11:08:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04215 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:08:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03150; Wed, 8 May 2002 11:00:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03116 for ; Wed, 8 May 2002 11:00:06 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10670 for ; Wed, 8 May 2002 10:59:57 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48F0364067254 for ; Wed, 8 May 2002 11:00:05 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48F02Q210200 for ; Wed, 8 May 2002 11:00:02 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48F0Qw19144 for ; Wed, 8 May 2002 11:00:26 -0400 Message-Id: <200205081500.g48F0Qw19144@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:00:26 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > 17.1.2. Transmission of Solicit Messages > > The first Solicit message from the client on the interface MUST > be delayed by a random amount of time between MIN_SOL_DELAY and > MAX_SOL_DELAY. In the case of a Solicit message transmitted when DHCP > is initiated by IPv6 Neighbor Discovery, the delay gives the amount > of time to wait after the ManagedFlag changes from FALSE to TRUE (see > section 5.5.3 of RFC2462). This random delay desynchronizes clients > which start at the same time (for example, after a power outage). Hmm. I see a couple of potential problems here. First, we have to be careful about tying this to the change of the value from FALSE to TRUE. Consider a misconfiguration, where there are two routers, and one sends out RAs with the bit set to 0, the other router sets it to 1. This will result in a flip-flop with every RA. Do we really want to restart DHC everytime that happens? A better approach might be to say, if the managed bit changes from FALSE to TRUE, *and* the client isn't currently already using DHC on that interface, then start the process. note: if the flag changes from true to false, does the client drop all its DHC-learned stuff and issue a release? There is no text that suggests this be done, and I don't think we want to do this. Also, the delay should be tied to receipt of the first RA that says use DHC. On a power outage, all the clients will get the first RA at the same time. This is the issue where having a random delay would seem to be most important. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:08:33 2002 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 LAA11127 for ; Wed, 8 May 2002 11:08:33 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04244 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:08:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03639; Wed, 8 May 2002 11:01:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03613 for ; Wed, 8 May 2002 11:01:22 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10735 for ; Wed, 8 May 2002 11:01:13 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-877.cisco.com [10.21.99.109]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA23873; Wed, 8 May 2002 11:00:50 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508105641.0320ce68@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 11:00:44 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] dhcpv6-24: use of DNS names in DUIDs Cc: dhcwg@ietf.org In-Reply-To: <200205081407.g48E7BI18794@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thomas - the VUID-DN format is useful for vendors that have a DNS name but do not have an enterprise number. Whether or not there are enough vendors in that situation to warrant the definition of the VUID-DN is up for discussion. I argue for the domain name representation to be in the base spec to cover all possible future uses of domain names in options, even if none of those options appear in the base spec. With the definition in the base spec, we are guaranteed uniformity of domain name representation across all future options. If there is a conflcit between the spec in section 8 and in the VUID-DN definition, we should fix (or drop) the VUID-DN definition. - Ralph At 10:07 AM 5/8/2002 -0400, Thomas Narten wrote: >The document makes references to DNS names in two places: > > > 9.3. Vendor-assigned unique ID based on Domain Name (VUID-DN) > > > > The vendor-assigned unique ID based on the domain name consists of a > > two-octet value giving the length of the identifier, the value of the > > identifier and the vendor's registered domain name. > >I don't think VUID-DN format is needed and would suggest simply >removing it. > >Rational: > >DNS names are NOT permanent identifiers. For example, registrars >can reclaim DNS names if the renewal fees are not paid, if there >disputes of trademark, etc. Thus, these may be less permanent than >appears. > >Second, they don't seem to provide any additional >benefits/functionality compared with VUID-EN. In those DUIDs, an >enterprise number provides the global uniqueness. Enterprise numbers >were defined precisely for this purpose, are permanent, and are easy >to get. > > > 8. Representation and use of domain names > > > > So that domain names may be encoded uniformly and compactly, a > > domain name or a list of domain names is encoded using the technique > > described in sections 3.1 and 4.1.4 of RFC1035 [12]. Section 4.1.4 > > of RFC1035 describes how more than one domain name can be represented > > in a list of domain names. For use in this specification, in a > > list of domain names, the compression pointer (see section 4.1.4 of > > RFC1035) refers to the offset within the list. > >I don't think this needs to be in the base document. Nowhere does the >base spec use DNS names according to this format. Thus, there is >nothing to implement. Note that VUID-DN mentioned above doesn't use >this format (is that a bug?) -- it seems to use an ascii string >(which, BTW, is probably not really what is needed, given a future >with I18N DNS names). > >When an option gets defined that encodes a DNS name, that is where the >above text needs to be specified. > >Thomas > >_______________________________________________ >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 daemon@optimus.ietf.org Wed May 8 11:08:56 2002 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 LAA11178 for ; Wed, 8 May 2002 11:08:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04302 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:09:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04032; Wed, 8 May 2002 11:07:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04009 for ; Wed, 8 May 2002 11:06:59 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11008 for ; Wed, 8 May 2002 11:06:50 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48F6w64022682 for ; Wed, 8 May 2002 11:06:58 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48F6wQ87058 for ; Wed, 8 May 2002 11:06:58 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48F7M819234 for ; Wed, 8 May 2002 11:07:22 -0400 Message-Id: <200205081507.g48F7M819234@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:07:22 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: comparing client parameters and server state Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > 18.2.2. Receipt of Confirm messages > > When the server receives a Confirm message, the client is requesting > confirmation that the configuration information it will use is valid. > The server locates the binding for that client and compares the > information in the Confirm message from the client to the information > associated with that client. Couple of thoughts. The document doesn't really define "compare". Do the Lifetimes have to be equal? I would assume not, but this is not stated... Also, does the Confirm include *only* IAs that were assigned by that server? If not, seems like confirm will fail (i.e, if a client has IAs from different servers). Is the text clear on this? (I don't bthink the text says only include IAs allocated from the server to which the confirm is being sent.) Some clarifying text would seem to be needed here. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:08:57 2002 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 LAA11197 for ; Wed, 8 May 2002 11:08:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04316 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:09:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03955; Wed, 8 May 2002 11:06:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03924 for ; Wed, 8 May 2002 11:06:17 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10951 for ; Wed, 8 May 2002 11:06:08 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48F6G64112360 for ; Wed, 8 May 2002 11:06:16 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48F6CQ230384 for ; Wed, 8 May 2002 11:06:12 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48F6aB19222 for ; Wed, 8 May 2002 11:06:36 -0400 Message-Id: <200205081506.g48F6aB19222@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:06:36 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: movement detection and Confirm message Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > 18.1.2. Creation and transmission of Confirm messages > > Whenever a client may have moved to a new link, its IPv6 addresses > and other configuration information may no longer be valid. Examples > of times when a client may have moved to a new link include: > > o The client reboots > > o The client is physically disconnected from a wired connection > > o The client returns from sleep mode > > o The client using a wireless technology changes access points > > In any situation when a client may have moved to a new link, the > client MUST initiate a Confirm/Reply message exchange. The client Hmm. I wonder if movement detection should just be dropped from DHC. The problem of determining whether you have reconnected to a new link is a generic problem, not just one that DHC has. If you have routers, for example, you could use RAs to determine that you have moved, which would then retrigger DHC (as appropriate). I could imagine an RA option that included a unique identifier for the link (this might be useful for mobility in general). Or, you could just see of the router you were using has changed (its link-local address is an identifier). Or, use the set of on-link prefixes on the RA. If they are the same as before, you presumably haven't moved. Having the client send DHC messages to the server to determine whether it has moved seems like a fair amount of overhead and sub optimal. Also, if one dropped the movement detection from DHC, would this allow you to do away with the Confirm? I.e., if a client detects that it has moved, then just have it redo the normal DHC exchanges. That would seem simpler. Plus, if a node has actually moved, the confirm will fail, and the normal DHC exchanges have to be used anyway. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:09:29 2002 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 LAA11279 for ; Wed, 8 May 2002 11:09:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04465 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:09:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04198; Wed, 8 May 2002 11:08:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04171 for ; Wed, 8 May 2002 11:08:13 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11023 for ; Wed, 8 May 2002 11:08:04 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-877.cisco.com [10.21.99.109]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA24968; Wed, 8 May 2002 11:07:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508110115.031eaab0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 11:07:35 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] dhcpv6-24: use of anycast Cc: dhcwg@ietf.org In-Reply-To: <200205081459.g48ExTa19129@rotala.raleigh.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Thomas - the use of anycast is to allow the use of DHCP on links that do not support multicast. The intention is to use anycast just across the link to which the client is attached; a relay agent forward messages across the rest of the path to the server. More comments in line. At 10:59 AM 5/8/2002 -0400, Thomas Narten wrote: >Seems to me that the anycast text is a bit underspecified. It's also >not clear to me exactly what problem the anycast text is trying to >address. > > > 13. Transmission of messages by a client > > > > Unless otherwise specified, a client sends DHCP messages to the > > All_DHCP_Relay_Agents_and_Servers or the DHCP_Anycast address. > >This is ambiguous. What should clients actually implement by default? >This document should make it clear what clients should implement. For >example try one and if it doesn't work, try the other? Leaving when to >use anycast to the implementor without guidelines will likely lead to >interoperability problems, with different implementations doing >different things. Should read "send to All_DHCP_Relay_Agents_and_Servers unless link does not support multicast, in which case used DHCP_Anycast" > > If the client is attached to a link that supports multicast > > transmission, the client sends DHCP messages to the > > All_DHCP_Relay_Agents_and_Servers address. If the client is > >My understanding is that all IPv6 links support multicast by >definition. If the underlying network doesn't, it must be >emulated. Note that multicast is needed for Neighbor Discovery, which >all IPv6 nodes have to implement. If all IPv6 links support multicast, then we don't need the anycast address for DHCP. > > When a client sends a DHCP message to the DHCP_Anycast address, it > > MUST use an address assigned to the interface for which the client > > is interested in obtaining configuration, which is suitable for use > > by the server in responding to the client, as the source address in > > the header of the IP datagram. See "Default Address Selection for > > IPv6" [4] for more details. > >Don't you also need to say that anycast can only be used if the client >already has a properly scoped address? It seems to me that anycast >isn't very useful for the *client*. I.e, let it always send to the >relay agent and let the relay agent deal with anycast vs. mcast. We're extending the use of anycast to include direct communication with the server, which is parallel to the use of unicast (under the control of the server). >Or, is this specifically restricted to the information-request >message? If so, might be good to say that. No, it's not intended to be specific to Information-request. >In private mail, Ralph asked: > > > Good question to ask...How about words to the effect of "if the link is > > connected to an NBMA link, use anycast; otherwise, use multicast"? > >What is an NBMA link? Who defines what that is? I'm not sure there is >a well-defined definition of NBMA link. > >Thomas > >_______________________________________________ >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 daemon@optimus.ietf.org Wed May 8 11:09:53 2002 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 LAA11311 for ; Wed, 8 May 2002 11:09:53 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04502 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:10:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04114; Wed, 8 May 2002 11:07:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04051 for ; Wed, 8 May 2002 11:07:42 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11014 for ; Wed, 8 May 2002 11:07:33 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48F7f64058738 for ; Wed, 8 May 2002 11:07:42 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48F7fQ107180 for ; Wed, 8 May 2002 11:07:41 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48F85N19250 for ; Wed, 8 May 2002 11:08:05 -0400 Message-Id: <200205081508.g48F85N19250@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:08:05 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: sending Information-request via multicast Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > If the client has an IPv6 address of sufficient scope, the > client MAY choose to send the Information-request message to the > All_DHCP_Servers multicast address. This MAY leaves things very ambiguous. When should they do this? When not? It would be much better to have a clear algorithm the client always follows. Otherwise, you'll get different implementations doing different things, which is probably not good for interoperability. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:10:01 2002 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 LAA11330 for ; Wed, 8 May 2002 11:10:01 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04516 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:10:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03879; Wed, 8 May 2002 11:05:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA03850 for ; Wed, 8 May 2002 11:05:10 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10922 for ; Wed, 8 May 2002 11:05:00 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48F5964126130 for ; Wed, 8 May 2002 11:05:09 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48F59Q221082 for ; Wed, 8 May 2002 11:05:09 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48F5XQ19207 for ; Wed, 8 May 2002 11:05:33 -0400 Message-Id: <200205081505.g48F5XQ19207@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:05:33 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: Rapid Commit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This is a new addition relative to -23. I'm still trying to understand what its actual value is. The current specification seems to have some potential issues. > If the client has included a Rapid Commit option and is waiting for > a Reply message, the client terminates the retransmission process as > soon as a Reply message is received. I'm not sure I understand the model for Rapid Commit. What happens if two servers reply? I gather this isn't supposed to happen. Hmm. It seems like this is only useful if there is only one server, but in general there is a need for multiple servers for reliability/failover. So it seems like complexity that may not buy much in practice. What is the deployment scenario where this is viewed as must useful? Also. This document doesn't provide guidance on when a client should request this. Always? Seems like some guidance is needed, or you'll get clients doing random things (not good for interoperability). > 17.1.4. Receipt of Reply message > If the client includes a Rapid Commit option in the Solicit message, > it will expect a Reply message that includes a Rapid Commit option > in response. If the client receives a Reply message, it processes > the message as described in section 18.1.6. If the client does not > receive a Reply message, the client restarts the server solicitation > process by sending a Solicit message that does not include a Rapid > Commit option. So, if the client sets the Rapid Commit, because it is in a hurry, the process may actually take *longer* because some servers won't respond unless the Rapid Commit is not present? This seems like a disincentive to using the mechanism, as it might not only be quicker, it might actually be longer, and there isn't a way for the client to know without just trying. Right? Also, section 18.1.6 does not include any text about the Rapid Commit. So, what does a client do with a response that does include it? Doesn't include it? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:11:01 2002 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 LAA11416 for ; Wed, 8 May 2002 11:11:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA04599 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:11:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04419; Wed, 8 May 2002 11:09:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04390 for ; Wed, 8 May 2002 11:09:25 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11246 for ; Wed, 8 May 2002 11:09:16 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48F9P64142268 for ; Wed, 8 May 2002 11:09:25 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48F9OQ176822 for ; Wed, 8 May 2002 11:09:24 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48F9mY19283 for ; Wed, 8 May 2002 11:09:48 -0400 Message-Id: <200205081509.g48F9mY19283@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:09:48 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: Interface-ID option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > If the relay agent cannot use the address in the link-address field > to identify the interface through which the response to the client > will be forwarded, the relay agent MUST include an Interface-id > option (see section 22.19) in the Relay-forward message. The server I think the interface-id option may be underspecified. If it is included, but there is no valid link-address (which I understand is the reason for defining this particular option), how does the server know which addresses to assign the client? I.e., how does the server know on which link the client is? > The relay agent puts the client's address in the link-address field > regardless of whether the relay agent includes an Interface-id option > in the Relay-forward message. This doesn't seem right to me. I thought that the link-address is supposed to hold the address of the relay agent. Seems wrong to put the client's address in it. The link-address field is what the server uses to figure out which link the client is on (right?). Also, since the client's address is a link-local address, this field doesn't seem to contain useful information for the server in this case. > Servers MAY use the Interface-ID for parameter assignment policies. > The Interface-ID SHOULD be considered an opaque value, with policies > based on exact string match only; that is, the Interface-ID SHOULD > NOT be internally parsed by the server. Shouldn't the first MAY be a MUST? I.e., the link-address field contains no useful information. Also, not sure the above is sufficient. Unless the interface-identifier is somehow stable, it's not clear how the server policy could take it into account. There are no words suggesting the interface-identifier needs to be stable. > interface-id An opaque value of arbitrary length generated > by the relay agent to identify one of the > relay agent's interfaces Any reaosn not to make this 32 bits? the IPv6 API already has 32-bit interface IDs. Is there any reason to make it larger? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:12:52 2002 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 LAA11638 for ; Wed, 8 May 2002 11:12:52 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05013 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:13:01 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04722; Wed, 8 May 2002 11:11:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04697 for ; Wed, 8 May 2002 11:11:30 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11474 for ; Wed, 8 May 2002 11:11:21 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48FBT64069090 for ; Wed, 8 May 2002 11:11:29 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48FBTQ119356 for ; Wed, 8 May 2002 11:11:29 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FBrn19319 for ; Wed, 8 May 2002 11:11:53 -0400 Message-Id: <200205081511.g48FBrn19319@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:11:53 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: using IPsec to secure relay-agent <-> server messages Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > 21.2. Security of messages sent between servers and relay agents > > Relay agents and servers that choose to exchange messages securely > use the IPsec mechanisms for IPv6 [8]. The way in which IPsec > is employed by relay agents and servers is not specified in this > document. I suspect that this will not get through the IESG as is. IPsec doesn't work well with multicast. This is too underspecified. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:13:30 2002 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 LAA11724 for ; Wed, 8 May 2002 11:13:30 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05124 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:13:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04846; Wed, 8 May 2002 11:12:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04822 for ; Wed, 8 May 2002 11:12:06 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11521 for ; Wed, 8 May 2002 11:11:57 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48FC564063878 for ; Wed, 8 May 2002 11:12:05 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48FC5Q106066 for ; Wed, 8 May 2002 11:12:05 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FCT419328 for ; Wed, 8 May 2002 11:12:29 -0400 Message-Id: <200205081512.g48FCT419328@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:12:29 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: Elapsed Time option Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > 22.9. Elapsed Time > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_ELAPSED_TIME | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | elapsed-time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > option-code OPTION_ELAPSED_TIME (8) > > option-len 2. > > elapsed-time The amount of time since the client began its > current DHCP transaction. This time is expressed in > hundredths of a second (10^-2 seconds). Would it make sense to change this option to carry the retransmission number rather than an actual time? I.e., backup servers would respond only on (say) a retransmission? I understand this to be a holdover from DHC. But if the goal is to provide backup servers info on when they should respond, the retransmission count might be more useful than the elapsed time. Thoughts? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:14:00 2002 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 LAA11780 for ; Wed, 8 May 2002 11:13:56 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05184 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:14:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04935; Wed, 8 May 2002 11:12:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04898 for ; Wed, 8 May 2002 11:12:44 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11603 for ; Wed, 8 May 2002 11:12:34 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48FCh64159450 for ; Wed, 8 May 2002 11:12:43 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48FChQ215392 for ; Wed, 8 May 2002 11:12:43 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FD7W19372 for ; Wed, 8 May 2002 11:13:07 -0400 Message-Id: <200205081513.g48FD7W19372@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:13:07 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: confirm vs. renew vs. rebind Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > CONFIRM (4) A client sends a Confirm message to servers to > request that the server validate and confirm > that the addresses and current configuration > parameters assigned by the server to the client > are still valid. > > RENEW (5) A client sends a Renew message to the server > that originally provided the client's addresses > and configuration addresses to update the > addresses assigned to the client and the > lifetimes for those addresses, as well as the > current configuration parameters assigned by > the server to the client. > > REBIND (6) A client sends a Rebind message to update > the addresses assigned to the client and the > lifetimes for those addresses, as well as the > current configuration parameters assigned by > the server to the client; this message is sent > after a client receives no response to a Renew > message. > The document still could do a better job of explaining what the difference between these three messages is. Having read the document carefully twice now, I still don't feel like I understand the difference. For the confirm, I gather that the only answer is "yes" or "no". If so, it would also be good to say that and point out that this message is used to decide whether a rebind/renew/request needs to be done. (note: In a separate note, I have questions about the overall utility of confirm.) For rebind, is it different from renew in that it is sent to all dhc servers, rather than just the one to which renew is sent? If so, saying that in the overview would be helpful. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:14:34 2002 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 LAA11876 for ; Wed, 8 May 2002 11:14:34 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05309 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:14:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04679; Wed, 8 May 2002 11:11:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA04651 for ; Wed, 8 May 2002 11:11:20 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11465 for ; Wed, 8 May 2002 11:11:11 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48FBJ64047484 for ; Wed, 8 May 2002 11:11:20 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48FBJQ208322 for ; Wed, 8 May 2002 11:11:19 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FBh119311 for ; Wed, 8 May 2002 11:11:43 -0400 Message-Id: <200205081511.g48FBh119311@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:11:43 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: Temporary addresses Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > A server MUST return the same set of temporary address for the same > IA_TA (as identified by the IAID) as long as those addresses are > still valid. After the lifetimes of the addresses in an IA_TA have > expired, the IAID may be reused to identify a new IA_TA with new > temporary addresses. I don't think the above is what we want. A Client should be able to renew/extend lifetimes for temp addresses *if* they want. But in general, they won't. (Note this is also allowed in 3041 in the sense that this is left open as a possibility -- I don't see a need for DHC to preclude this from being done) Ralph asked: > The basic question is "can a client ask and a server agree to extend > the lifetimes on temp addresses". If lifetimes on temp addresses can > be extended, how are they different from non-temp addresses? Good > question to discuss in WG. They are different in that applications can specifically request that temp addresses be used for communication, *or* that temp addresses NOT be used. Thus, there has to be a way to distinguish between temp and non-temp addresses. Also, I believe that a node might be using several sets of temp addresses simultaneously. Normally, that would mean one set that is "preferred", but there could be a number of others that are "deprecated", meaning not to be used for new communication, but still available to the applications that are already using them. If an application is still using a temp address, it may need to extend the valid Lifetime to prevent the address from going away. This also raises a different point. There should be more text about when to get a new set of temp addresses. I.e., one could point to 3041 for guidance on when to get a new one and use similar rules. I.e., unlike permanent addresses, the normal action when a temporary address becomes deprecated is to request a new (i.e., different) one. The old one still remains for a while, but is being phased out. In contrast, for public/global addresses, the normal action is to renew the *same* address and extend its preferred lifetime. > An identity association for temporary addresses option MUST NOT > appear in a Renew or Rebind message. This option MAY appear in a > Confirm message if the lifetimes on the temporary addresses in the > associated IA have not expired. If the client wants to extend a binding (perhaps an application is still using that address) it should not be prohibited by the protocol from doing so. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:14:51 2002 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 LAA11897 for ; Wed, 8 May 2002 11:14:51 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05346 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:14:59 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05107; Wed, 8 May 2002 11:13:36 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05078 for ; Wed, 8 May 2002 11:13:34 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11715 for ; Wed, 8 May 2002 11:13:24 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48FDX64050178 for ; Wed, 8 May 2002 11:13:33 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48FDXQ101290 for ; Wed, 8 May 2002 11:13:33 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FDvW19387 for ; Wed, 8 May 2002 11:13:57 -0400 Message-Id: <200205081513.g48FDvW19387@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:13:57 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: response to a release message Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > After all the addresses have been processed, the server generates a > Reply message and includes a Status Code option with value Success > and a Server Identifier option with the server's DUID. The server > MUST NOT include any other options in the Reply message. > If the server cannot find a binding for the client, the server > sends a Reply message that includes a Status Code option with value > NoBinding. I can't quite tell what is supposed to happen if there are mixture of successes and failures. If there are failures, are multiple IAs returned indicating which ones were released successfully and which were not? The text seems to say no, no other options other than that Status Code. Seems like a simple success/fail for *all* the addresses will leave the client unsure of what state the various addresses are in. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:15:07 2002 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 LAA11938 for ; Wed, 8 May 2002 11:15:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA05408 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:15:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05222; Wed, 8 May 2002 11:14:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA05196 for ; Wed, 8 May 2002 11:14:05 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11775 for ; Wed, 8 May 2002 11:13:55 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48FE464028160 for ; Wed, 8 May 2002 11:14:04 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48FE4Q143940 for ; Wed, 8 May 2002 11:14:04 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FESQ19407 for ; Wed, 8 May 2002 11:14:28 -0400 Message-Id: <200205081514.g48FESQ19407@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Wed, 08 May 2002 11:14:28 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: vendor-specific issues Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Servers can interpret the meanings of multiple class specifications > in an implementation dependent or configuration dependent manner, and > so the use of multiple classes by a DHCP client should be based on > the specific server implementation and configuration which will be > used to process that User class option. This sure reads badly in the sense that it smells like interoperability will not result. But I'm not sure what the intent of the wording is here... Could someone clarify? > 22.18. Vendor-specific Information option > > This option is used by clients and servers to exchange > vendor-specific information. The definition of this information is > vendor specific. The vendor is indicated in the enterprise-number > field. Clients that do not receive desired vendor-specific > information SHOULD make an attempt to operate without it, although > they may do so (and announce they are doing so) in a degraded mode. This also reads badly and against interoperabilty. DHC clients should never depend on vendor-specific options in order to function correctly. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:35:08 2002 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 LAA13043 for ; Wed, 8 May 2002 11:35:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07156 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:35:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06899; Wed, 8 May 2002 11:33:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06868 for ; Wed, 8 May 2002 11:33:16 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12870 for ; Wed, 8 May 2002 11:33:08 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48FX664042434; Wed, 8 May 2002 11:33:06 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48FX6Q109964; Wed, 8 May 2002 11:33:06 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FXU519550; Wed, 8 May 2002 11:33:30 -0400 Message-Id: <200205081533.g48FXU519550@rotala.raleigh.ibm.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of DNS names in DUIDs In-Reply-To: Message from "Wed, 08 May 2002 11:00:44 EDT." <4.3.2.7.2.20020508105641.0320ce68@funnel.cisco.com> Date: Wed, 08 May 2002 11:33:30 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Thomas - the VUID-DN format is useful for vendors that have a DNS name but > do not have an enterprise number. I think you need to also add: "and cannot easily obtain one". My understanding is that they are easy to obtain. See http://www.iana.org/assignments/enterprise-numbers. There is also an online application form on the IANA page. > I argue for the domain name representation to be in the base spec to cover > all possible future uses of domain names in options, even if none of those > options appear in the base spec. With the definition in the base spec, we > are guaranteed uniformity of domain name representation across all future > options. I can live with this. > If there is a conflcit between the spec in section 8 and in the VUID-DN > definition, we should fix (or drop) the VUID-DN definition. The VUID-DN definition says the DNS name is in ascii. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:35:59 2002 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 LAA13126 for ; Wed, 8 May 2002 11:35:59 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07255 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:36:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06567; Wed, 8 May 2002 11:30:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06542 for ; Wed, 8 May 2002 11:30:54 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12697 for ; Wed, 8 May 2002 11:30:47 -0400 (EDT) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.us.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.12.2/8.12.2) with ESMTP id g48FUn64012920; Wed, 8 May 2002 11:30:49 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g48FUmQ143996; Wed, 8 May 2002 11:30:48 -0400 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g48FVCC19526; Wed, 8 May 2002 11:31:12 -0400 Message-Id: <200205081531.g48FVCC19526@rotala.raleigh.ibm.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of anycast In-Reply-To: Message from "Wed, 08 May 2002 11:07:35 EDT." <4.3.2.7.2.20020508110115.031eaab0@funnel.cisco.com> Date: Wed, 08 May 2002 11:31:12 -0400 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Thomas - the use of anycast is to allow the use of DHCP on links > that do not support multicast. The intention is to use anycast just > across the link to which the client is attached; a relay agent > forward messages across the rest of the path to the server. OK. It was not clear to me that anycast was restricted to the first hop. But... If a link doesn't support IPv6 multicast, how will it support Neighbor Discovery? I suspect there are only a few links that might have this property. Do we understand what those link types are and whether its important that DHC run over them? > If all IPv6 links support multicast, then we don't need the anycast address > for DHCP. This would be my assumption. Do folks have examples of link types they are concerned about? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:40:08 2002 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 LAA13410 for ; Wed, 8 May 2002 11:40:08 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA07636 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:40:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07370; Wed, 8 May 2002 11:37:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA07341 for ; Wed, 8 May 2002 11:37:32 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13242 for ; Wed, 8 May 2002 11:37:24 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g48FaGS09590; Wed, 8 May 2002 08:36:17 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g48FbE600335; Wed, 8 May 2002 10:37:14 -0500 (CDT) Date: Wed, 8 May 2002 10:37:14 -0500 Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: dhcwg@ietf.org To: Thomas Narten From: Ted Lemon In-Reply-To: <200205081506.g48F6aB19222@rotala.raleigh.ibm.com> Message-Id: <789B7E2C-6299-11D6-A5AB-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit What we've described in this section is precisely how the most functional DHCPv4 clients operate today - e.g., the Apple DHCPv4 client does link change detection, and in practice the user experience is much better than what you get with the ISC dhcp client, which does not do link change detection. The confirm message is necessary. Using RA messages to do link change detection is great, and we talked about it, but as you say, it requires an additional RA option on whose presence we cannot count at this time. So I would say we should leave this just the way it is. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 11:49:25 2002 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 LAA13974 for ; Wed, 8 May 2002 11:49:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08461 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 11:49:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08322; Wed, 8 May 2002 11:46:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08302 for ; Wed, 8 May 2002 11:46:49 -0400 (EDT) Received: from cisco.com (mrwint.cisco.com [144.254.98.48]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13774 for ; Wed, 8 May 2002 11:46:41 -0400 (EDT) Received: (from otroan@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id QAA11998; Wed, 8 May 2002 16:46:17 +0100 (BST) X-Authentication-Warning: mrwint.cisco.com: otroan set sender to ot@cisco.com using -f To: Thomas Narten Cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of anycast References: <200205081531.g48FVCC19526@rotala.raleigh.ibm.com> From: Ole Troan Date: Wed, 08 May 2002 16:46:17 +0100 In-Reply-To: <200205081531.g48FVCC19526@rotala.raleigh.ibm.com> (Thomas Narten's message of "Wed, 08 May 2002 11:31:12 -0400") Message-ID: <7t5d6w6wsl2.fsf@mrwint.cisco.com> Lines: 26 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/20.7 (sparc-sun-solaris2.8) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >> Thomas - the use of anycast is to allow the use of DHCP on links >> that do not support multicast. The intention is to use anycast just >> across the link to which the client is attached; a relay agent >> forward messages across the rest of the path to the server. > > OK. It was not clear to me that anycast was restricted to the first > hop. > > But... If a link doesn't support IPv6 multicast, how will it support > Neighbor Discovery? I suspect there are only a few links that might > have this property. Do we understand what those link types are and > whether its important that DHC run over them? > >> If all IPv6 links support multicast, then we don't need the anycast address >> for DHCP. > > This would be my assumption. Do folks have examples of link types they > are concerned about? ATM, Frame Relay RFC2491), ISDN/PSTN, MPLS, 6to4, ISATAP. if routers use DHCP (e.g Prefix Delegation) then support is needed for the first set of media. hosts connecting through an ISATAP cloud could very well need DHCP I should think. cheers, Ole _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 12:04:37 2002 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 MAA14484 for ; Wed, 8 May 2002 12:04:31 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10531 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:04:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09019; Wed, 8 May 2002 11:59:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA09003 for ; Wed, 8 May 2002 11:59:53 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14244 for ; Wed, 8 May 2002 11:59:46 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g48Fxql14496 for ; Wed, 8 May 2002 10:59:52 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48FxqE21588 for ; Wed, 8 May 2002 10:59:52 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed May 08 10:58:58 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 10:58:58 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3BA@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Date: Wed, 8 May 2002 10:58:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6A9.3D1AFF90" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6A9.3D1AFF90 Content-Type: text/plain; charset="iso-8859-1" This issue on the flip-flop of the ManagedFlag is already addressed in RFC 2462: 5.5.3. Router Advertisement Processing On receipt of a valid Router Advertisement (as defined in [DISCOVERY]), a host copies the value of the advertisement's M bit into ManagedFlag. If the value of ManagedFlag changes from FALSE to TRUE, and the host is not already running the stateful address autoconfiguration protocol, the host should invoke the stateful address autoconfiguration protocol, requesting both address information and other information. If the value of the ManagedFlag changes from TRUE to FALSE, the host should continue running the stateful address autoconfiguration, i.e., the change in the value of the ManagedFlag has no effect. If the value of the flag stays unchanged, no special action takes place. In particular, a host MUST NOT reinvoke stateful address configuration if it is already participating in the stateful protocol as a result of an earlier advertisement. So, it shouldn't need to be restated in the DHCP specification? - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:00 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: randomization delay before invoking DHC > 17.1.2. Transmission of Solicit Messages > > The first Solicit message from the client on the interface MUST > be delayed by a random amount of time between MIN_SOL_DELAY and > MAX_SOL_DELAY. In the case of a Solicit message transmitted when DHCP > is initiated by IPv6 Neighbor Discovery, the delay gives the amount > of time to wait after the ManagedFlag changes from FALSE to TRUE (see > section 5.5.3 of RFC2462). This random delay desynchronizes clients > which start at the same time (for example, after a power outage). Hmm. I see a couple of potential problems here. First, we have to be careful about tying this to the change of the value from FALSE to TRUE. Consider a misconfiguration, where there are two routers, and one sends out RAs with the bit set to 0, the other router sets it to 1. This will result in a flip-flop with every RA. Do we really want to restart DHC everytime that happens? A better approach might be to say, if the managed bit changes from FALSE to TRUE, *and* the client isn't currently already using DHC on that interface, then start the process. note: if the flag changes from true to false, does the client drop all its DHC-learned stuff and issue a release? There is no text that suggests this be done, and I don't think we want to do this. Also, the delay should be tied to receipt of the first RA that says use DHC. On a power outage, all the clients will get the first RA at the same time. This is the issue where having a random delay would seem to be most important. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6A9.3D1AFF90 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC

This issue on the flip-flop of the ManagedFlag is already addressed in RFC 2462:

5.5.3. Router Advertisement Processing

   On receipt of a valid Router Advertisement (as defined in
   [DISCOVERY]), a host copies the value of the advertisement's M bit
   into ManagedFlag. If the value of ManagedFlag changes from FALSE to
   TRUE, and the host is not already running the stateful address
   autoconfiguration protocol, the host should invoke the stateful
   address autoconfiguration protocol, requesting both address
   information and other information. If the value of the ManagedFlag
   changes from TRUE to FALSE, the host should continue running the
   stateful address autoconfiguration, i.e., the change in the value of
   the ManagedFlag has no effect. If the value of the flag stays
   unchanged, no special action takes place. In particular, a host MUST
   NOT reinvoke stateful address configuration if it is already
   participating in the stateful protocol as a result of an earlier
   advertisement.

So, it shouldn't need to be restated in the DHCP specification?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:00 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: randomization delay before invoking DHC

> 17.1.2. Transmission of Solicit Messages
>
>    The first Solicit message from the client on the interface MUST
>    be delayed by a random amount of time between MIN_SOL_DELAY and
>    MAX_SOL_DELAY. In the case of a Solicit message transmitted when DHCP
>    is initiated by IPv6 Neighbor Discovery, the delay gives the amount
>    of time to wait after the ManagedFlag changes from FALSE to TRUE (see
>    section 5.5.3 of RFC2462). This random delay desynchronizes clients
>    which start at the same time (for example, after a power outage).

Hmm. I see a couple of potential problems here. First, we have to be
careful about tying this to the change of the value from FALSE to
TRUE. Consider a misconfiguration, where there are two routers, and
one sends out RAs with the bit set to 0, the other router sets it to
1. This will result in a flip-flop with every RA. Do we really want to
restart DHC everytime that happens?

A better approach might be to say, if the managed bit changes from
FALSE to TRUE, *and* the client isn't currently already using DHC on
that interface, then start the process. note: if the flag changes from
true to false, does the client drop all its DHC-learned stuff and
issue a release? There is no text that suggests this be done, and I
don't think we want to do this.

Also, the delay should be tied to receipt of the first RA that says
use DHC. On a power outage, all the clients will get the first RA at
the same time. This is the issue where having a random delay would
seem to be most important.

Thomas

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

------_=_NextPart_001_01C1F6A9.3D1AFF90-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 12:07:09 2002 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 MAA14622 for ; Wed, 8 May 2002 12:07:07 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA10742 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:07:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10476; Wed, 8 May 2002 12:03:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10455 for ; Wed, 8 May 2002 12:03:51 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14418 for ; Wed, 8 May 2002 12:03:39 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g48G3jl17503 for ; Wed, 8 May 2002 11:03:45 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48G3jn28858 for ; Wed, 8 May 2002 11:03:45 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 08 11:03:45 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:03:45 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3BB@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Rapid Commit Date: Wed, 8 May 2002 11:03:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6A9.EC4BEFB0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6A9.EC4BEFB0 Content-Type: text/plain; charset="iso-8859-1" I too would like the Rapid Commit handling improved. In particular: - A client should be able to send this option always if it supports it. - Servers that don't support the Rapid Commit or have not been configured to support it should respond with Advertise messages. - A client that receives a Reply to a Solicit w/Rapid Commit *may* use that Reply. If it doesn't, it should send a Release. - A client must use the normal Solicit procedure and await multiple Reply messages (and Advertises). If the client receives a Reply and doesn't use the information, it must send a Release. If the client receives no Reply messages or doesn't choose to use any, it should then follow the Advertise handling as normal. The option does have a value at least from the server / server administrator standpoint. An administrator could select not to allow this if there are multiple servers in the configuration. If there is a single server (or single set of primary/backup type servers), a server can be configured to allow Rapid Commit. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:06 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: Rapid Commit This is a new addition relative to -23. I'm still trying to understand what its actual value is. The current specification seems to have some potential issues. > If the client has included a Rapid Commit option and is waiting for > a Reply message, the client terminates the retransmission process as > soon as a Reply message is received. I'm not sure I understand the model for Rapid Commit. What happens if two servers reply? I gather this isn't supposed to happen. Hmm. It seems like this is only useful if there is only one server, but in general there is a need for multiple servers for reliability/failover. So it seems like complexity that may not buy much in practice. What is the deployment scenario where this is viewed as must useful? Also. This document doesn't provide guidance on when a client should request this. Always? Seems like some guidance is needed, or you'll get clients doing random things (not good for interoperability). > 17.1.4. Receipt of Reply message > If the client includes a Rapid Commit option in the Solicit message, > it will expect a Reply message that includes a Rapid Commit option > in response. If the client receives a Reply message, it processes > the message as described in section 18.1.6. If the client does not > receive a Reply message, the client restarts the server solicitation > process by sending a Solicit message that does not include a Rapid > Commit option. So, if the client sets the Rapid Commit, because it is in a hurry, the process may actually take *longer* because some servers won't respond unless the Rapid Commit is not present? This seems like a disincentive to using the mechanism, as it might not only be quicker, it might actually be longer, and there isn't a way for the client to know without just trying. Right? Also, section 18.1.6 does not include any text about the Rapid Commit. So, what does a client do with a response that does include it? Doesn't include it? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6A9.EC4BEFB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Rapid Commit

I too would like the Rapid Commit handling = improved.

In particular:

- A client should be able to send this option always = if it supports it.
- Servers that don't support the Rapid Commit or = have not been configured to support it should respond with Advertise = messages.

- A client that receives a Reply to a Solicit w/Rapid = Commit *may* use that Reply. If it doesn't, it should send a = Release.

- A client must use the normal Solicit procedure and = await multiple Reply messages (and Advertises). If the client receives = a Reply and doesn't use the information, it must send a Release. If the = client receives no Reply messages or doesn't choose to use any, it = should then follow the Advertise handling as normal.

The option does have a value at least from the server = / server administrator standpoint. An administrator could select not to = allow this if there are multiple servers in the configuration. If there = is a single server (or single set of primary/backup type servers), a = server can be configured to allow Rapid Commit.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:06 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: Rapid Commit

This is a new addition relative to -23. I'm still = trying to understand
what its actual value is. The current specification = seems to have some
potential issues.

>    If the client has included a = Rapid Commit option and is waiting for
>    a Reply message, the client = terminates the retransmission process as
>    soon as a Reply message is = received.

I'm not sure I understand the model for Rapid Commit. = What happens if
two servers reply? I gather this isn't supposed to = happen. Hmm. It
seems like this is only useful if there is only one = server, but in
general there is a need for multiple servers = for
reliability/failover. So it seems like complexity = that may not buy
much in practice. What is the deployment scenario = where this is viewed
as must useful?

Also. This document doesn't provide guidance on when = a client should
request this. Always? Seems like some guidance is = needed, or you'll
get clients doing random things (not good for = interoperability).

> 17.1.4. Receipt of Reply message

>    If the client includes a Rapid = Commit option in the Solicit message,
>    it will expect a Reply = message that includes a Rapid Commit option
>    in response. If the = client receives a Reply message, it processes
>    the message as described in = section 18.1.6. If the client does not
>    receive a Reply message, the = client restarts the server solicitation
>    process by sending a Solicit = message that does not include a Rapid
>    Commit option.

So, if the client sets the Rapid Commit, because it = is in a hurry, the
process may actually take *longer* because some = servers won't respond
unless the Rapid Commit is not present? This seems = like a disincentive
to using the mechanism, as it might not only be = quicker, it might
actually be longer, and there isn't a way for the = client to know
without just trying. Right?

Also, section 18.1.6 does not include any text = about the Rapid
Commit. So, what does a client do with a response = that does include
it? Doesn't include it?

Thomas

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

------_=_NextPart_001_01C1F6A9.EC4BEFB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 12:10:17 2002 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 MAA14803 for ; Wed, 8 May 2002 12:10:17 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11037 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:10:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10814; Wed, 8 May 2002 12:08:29 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10785 for ; Wed, 8 May 2002 12:08:27 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14643 for ; Wed, 8 May 2002 12:08:19 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g48G7ui10497 for ; Wed, 8 May 2002 11:07:56 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48G7un01526 for ; Wed, 8 May 2002 11:07:56 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed May 08 11:07:53 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:07:53 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3BC@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: comparing client parameters and server sta te Date: Wed, 8 May 2002 11:07:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6AA.7F3668F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6AA.7F3668F0 Content-Type: text/plain; charset="iso-8859-1" The Confirm is sent to all servers and not just the server from which the client obtained configuration information. The client should include all IAs for the link. Additional options (such as Domain Name Servers, etc) are allowed in the Confirm. They may be useful for the server to determine if the configuration information the client has is considered valid. What the server compares is really up to it - based on what it wants to check. I think the draft should state that the server MUST check that the prefixes for addresses (and perhaps addresses) are valid. The Confirm is to provide information to the client as to whether it is still on the same link - hence, that is what is more important to check. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:07 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: comparing client parameters and server state > 18.2.2. Receipt of Confirm messages > > When the server receives a Confirm message, the client is requesting > confirmation that the configuration information it will use is valid. > The server locates the binding for that client and compares the > information in the Confirm message from the client to the information > associated with that client. Couple of thoughts. The document doesn't really define "compare". Do the Lifetimes have to be equal? I would assume not, but this is not stated... Also, does the Confirm include *only* IAs that were assigned by that server? If not, seems like confirm will fail (i.e, if a client has IAs from different servers). Is the text clear on this? (I don't bthink the text says only include IAs allocated from the server to which the confirm is being sent.) Some clarifying text would seem to be needed here. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6AA.7F3668F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: comparing client parameters and server = state

The Confirm is sent to all servers and not just the = server from which the client obtained configuration information.

The client should include all IAs for the link. = Additional options (such as Domain Name Servers, etc) are allowed in = the Confirm. They may be useful for the server to determine if the = configuration information the client has is considered = valid.

What the server compares is really up to it - based = on what it wants to check. I think the draft should state that the = server MUST check that the prefixes for addresses (and perhaps = addresses) are valid. The Confirm is to provide information to the = client as to whether it is still on the same link - hence, that is what = is more important to check.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:07 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: comparing client = parameters and server state

> 18.2.2. Receipt of Confirm messages
>
>    When the server receives a = Confirm message, the client is requesting
>    confirmation that the = configuration information it will use is valid.
>    The server locates the = binding for that client and compares the
>    information in the Confirm = message from the client to the information
>    associated with that = client.

Couple of thoughts. The document doesn't really = define "compare". Do
the Lifetimes have to be equal? I would assume not, = but this is not
stated...

Also, does the Confirm include *only* IAs that were = assigned by that
server? If not, seems like confirm will fail (i.e, = if a client has IAs
from different servers). Is the text clear on this? = (I don't bthink
the text says only include IAs allocated from the = server to which the
confirm is being sent.)

Some clarifying text would seem to be needed = here.

Thomas

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

------_=_NextPart_001_01C1F6AA.7F3668F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 12:10:57 2002 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 MAA14881 for ; Wed, 8 May 2002 12:10:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11142 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:11:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10884; Wed, 8 May 2002 12:09:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10860 for ; Wed, 8 May 2002 12:09:10 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14672 for ; Wed, 8 May 2002 12:09:02 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g48G88S09664; Wed, 8 May 2002 09:08:08 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g48G97600352; Wed, 8 May 2002 11:09:07 -0500 (CDT) Date: Wed, 8 May 2002 11:09:06 -0500 Subject: Re: [dhcwg] dhcpv6-24: Rapid Commit Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: dhcwg@ietf.org To: Thomas Narten From: Ted Lemon In-Reply-To: <200205081505.g48F5XQ19207@rotala.raleigh.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit The rationale for rapid commit is that there are devices that need to operate over a limited-bandwidth link, where the cost of the additional message exchange is significant. For example, a cell phone. Also, rapid commit introduces less latency to the address configuration process, which can be very significant in some cases. With respect to the dual server model, the idea is that both servers do rapid commit, but the client only binds one of the server's addresses, and it simply drops the other server's addresses. When it goes to renew, it only talks to the server it bound to, so the other leases expire, and the addresses burned by rapid commit are reclaimed. This is considered okay because we have addresses to burn, and we consider the rapid commit to be more important than the burned addresses, which are reclaimed fairly quickly anyway. I think that you are right to object to the specific implementation we've described. It would be better to insist that the client be prepared to do the four-way handshake if it doesn't get a Reply with the rapid commit option - that is, a server can ignore the rapid commit option and send a Reply without it, and the client can wait if it wants to see if some other server replies with Rapid commit, or it can immediately proceed with the four-way handshake. I don't see any reason to require that the client restart the whole process without rapid commit if it doesn't receive a reply - I would expect it to be the server provider's responsibility to make sure that all DHCP servers that serve a link where rapid commit is desired are configured to actually support rapid commit. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 12:11:11 2002 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 MAA14903 for ; Wed, 8 May 2002 12:11:11 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11157 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:11:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10990; Wed, 8 May 2002 12:09:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA10961 for ; Wed, 8 May 2002 12:09:44 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14741 for ; Wed, 8 May 2002 12:09:36 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g48G9Di11262 for ; Wed, 8 May 2002 11:09:13 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48G9DE25309 for ; Wed, 8 May 2002 11:09:13 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 08 11:09:12 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:09:12 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3BD@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: using IPsec to secure relay-agent <-> serv er messages Date: Wed, 8 May 2002 11:09:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6AA.B1076690" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6AA.B1076690 Content-Type: text/plain; charset="iso-8859-1" Yeah, we probably should be clear here that IPSEC can only be used when the DHCP server addresses are preconfigured in the Relay. IPSEC can not be used if the relay is using multicast addresses (at least not until the IPSEC issues with multicast are addressed). - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:12 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: using IPsec to secure relay-agent <-> server messages > 21.2. Security of messages sent between servers and relay agents > > Relay agents and servers that choose to exchange messages securely > use the IPsec mechanisms for IPv6 [8]. The way in which IPsec > is employed by relay agents and servers is not specified in this > document. I suspect that this will not get through the IESG as is. IPsec doesn't work well with multicast. This is too underspecified. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6AA.B1076690 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: using IPsec to secure relay-agent = <-> server messages

Yeah, we probably should be clear here that IPSEC can = only be used when the DHCP server addresses are preconfigured in the = Relay. IPSEC can not be used if the relay is using multicast addresses = (at least not until the IPSEC issues with multicast are = addressed).

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:12 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: using IPsec to secure = relay-agent <-> server
messages

> 21.2. Security of messages sent between servers = and relay agents
>
>    Relay agents and servers that = choose to exchange messages securely
>    use the IPsec mechanisms for = IPv6 [8]. The way in which IPsec
>    is employed by relay agents = and servers is not specified in this
>    document.

I suspect that this will not get through the IESG as = is. IPsec doesn't
work well with multicast. This is too = underspecified.

Thomas

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

------_=_NextPart_001_01C1F6AA.B1076690-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 12:13:25 2002 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 MAA15032 for ; Wed, 8 May 2002 12:13:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11435 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:13:20 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11199; Wed, 8 May 2002 12:11:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11170 for ; Wed, 8 May 2002 12:11:29 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14918 for ; Wed, 8 May 2002 12:11:21 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g48GAwi12183 for ; Wed, 8 May 2002 11:10:58 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48GAwn03207 for ; Wed, 8 May 2002 11:10:58 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 08 11:10:57 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:10:57 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3BE@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option Date: Wed, 8 May 2002 11:10:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6AA.EF44EEF0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6AA.EF44EEF0 Content-Type: text/plain; charset="iso-8859-1" Either could work. I think the reason time is more interesting is that usually you want to guarantee some response within a fixed time. Retransmission numbers don't reflect how long the client may have been waiting (though there is some reasonable mapping based on the retransmission algorithm). - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:12 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: Elapsed Time option > 22.9. Elapsed Time > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_ELAPSED_TIME | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | elapsed-time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > option-code OPTION_ELAPSED_TIME (8) > > option-len 2. > > elapsed-time The amount of time since the client began its > current DHCP transaction. This time is expressed in > hundredths of a second (10^-2 seconds). Would it make sense to change this option to carry the retransmission number rather than an actual time? I.e., backup servers would respond only on (say) a retransmission? I understand this to be a holdover from DHC. But if the goal is to provide backup servers info on when they should respond, the retransmission count might be more useful than the elapsed time. Thoughts? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6AA.EF44EEF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Elapsed Time option

Either could work.

I think the reason time is more interesting is that = usually you want to guarantee some response within a fixed time. = Retransmission numbers don't reflect how long the client may have been = waiting (though there is some reasonable mapping based on the = retransmission algorithm).

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:12 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: Elapsed Time = option

> 22.9. Elapsed Time

>       = 0            = ;       = 1            = ;       = 2            = ;       3
>       0 1 2 3 4 5 = 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>      = |      = OPTION_ELAPSED_TIME      = |           = option-len          = |
>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
>      = |          = elapsed-time         |
>      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>
>       = option-code   OPTION_ELAPSED_TIME (8)
>
>       = option-len    2.
>
>       = elapsed-time The amount of time since the client began its
>          = ;           current = DHCP transaction. This time is expressed in
>          = ;           = hundredths of a second (10^-2 seconds).

Would it make sense to change this option to carry = the retransmission
number rather than an actual time? I.e., backup = servers would respond
only on (say) a retransmission?

I understand this to be a holdover from DHC. But if = the goal is to
provide backup servers info on when they should = respond, the
retransmission count might be more useful than the = elapsed time.

Thoughts?

Thomas

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

------_=_NextPart_001_01C1F6AA.EF44EEF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 12:16:29 2002 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 MAA15177 for ; Wed, 8 May 2002 12:16:29 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA11731 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:16:36 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11390; Wed, 8 May 2002 12:12:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11365 for ; Wed, 8 May 2002 12:12:48 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14988 for ; Wed, 8 May 2002 12:12:40 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g48GBlS09672; Wed, 8 May 2002 09:11:47 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g48GCj600356; Wed, 8 May 2002 11:12:45 -0500 (CDT) Date: Wed, 8 May 2002 11:12:45 -0500 Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: dhcwg@ietf.org To: Thomas Narten From: Ted Lemon In-Reply-To: <200205081512.g48FCT419328@rotala.raleigh.ibm.com> Message-Id: <6E94CA24-629E-11D6-A5AB-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > I understand this to be a holdover from DHC. But if the goal is to > provide backup servers info on when they should respond, the > retransmission count might be more useful than the elapsed time. It's true that a count would serve the functional purpose, but the retransmission time is easy to generate, serves the same purpose, and provides additional information. So why use the less functional retransmission count? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 12:18:57 2002 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 MAA15376 for ; Wed, 8 May 2002 12:18:57 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12012 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:19:04 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11780; Wed, 8 May 2002 12:16:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11702 for ; Wed, 8 May 2002 12:16:34 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15170 for ; Wed, 8 May 2002 12:16:21 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g48GFwi15308 for ; Wed, 8 May 2002 11:15:58 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48GFwE27993 for ; Wed, 8 May 2002 11:15:58 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed May 08 11:15:58 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:15:58 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3BF@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Wed, 8 May 2002 11:15:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6AB.A020A8E0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6AB.A020A8E0 Content-Type: text/plain; charset="iso-8859-1" I don't have a major issue if we dropped Confirm. It is just one of the ways a client could determine whether it moved; it really isn't a requirement to have within the DHCP specification. Do note however that since RAs don't have a unique link ID (yet?) and a RA might contain no prefixes (just have the "M" flag set), and in this case Confirm could be useful. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:07 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: movement detection and Confirm message > 18.1.2. Creation and transmission of Confirm messages > > Whenever a client may have moved to a new link, its IPv6 addresses > and other configuration information may no longer be valid. Examples > of times when a client may have moved to a new link include: > > o The client reboots > > o The client is physically disconnected from a wired connection > > o The client returns from sleep mode > > o The client using a wireless technology changes access points > > In any situation when a client may have moved to a new link, the > client MUST initiate a Confirm/Reply message exchange. The client Hmm. I wonder if movement detection should just be dropped from DHC. The problem of determining whether you have reconnected to a new link is a generic problem, not just one that DHC has. If you have routers, for example, you could use RAs to determine that you have moved, which would then retrigger DHC (as appropriate). I could imagine an RA option that included a unique identifier for the link (this might be useful for mobility in general). Or, you could just see of the router you were using has changed (its link-local address is an identifier). Or, use the set of on-link prefixes on the RA. If they are the same as before, you presumably haven't moved. Having the client send DHC messages to the server to determine whether it has moved seems like a fair amount of overhead and sub optimal. Also, if one dropped the movement detection from DHC, would this allow you to do away with the Confirm? I.e., if a client detects that it has moved, then just have it redo the normal DHC exchanges. That would seem simpler. Plus, if a node has actually moved, the confirm will fail, and the normal DHC exchanges have to be used anyway. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6AB.A020A8E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: movement detection and Confirm = message

I don't have a major issue if we dropped = Confirm.

It is just one of the ways a client could determine = whether it moved; it really isn't a requirement to have within the DHCP = specification.

Do note however that since RAs don't have a unique = link ID (yet?) and a RA might contain no prefixes (just have the = "M" flag set), and in this case Confirm could be = useful.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:07 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: movement detection and = Confirm message

> 18.1.2. Creation and transmission of Confirm = messages
>
>    Whenever a client may have = moved to a new link, its IPv6 addresses
>    and other configuration = information may no longer be valid. Examples
>    of times when a client may = have moved to a new link include:
>
>      o The client = reboots
>
>      o The client is = physically disconnected from a wired connection
>
>      o The client = returns from sleep mode
>
>      o The client = using a wireless technology changes access points
>
>    In any situation when a = client may have moved to a new link, the
>    client MUST initiate a = Confirm/Reply message exchange. The client

Hmm. I wonder if movement detection should just be = dropped from
DHC. The problem of determining whether you have = reconnected to a new
link is a generic problem, not just one that DHC = has. If you have
routers, for example, you could use RAs to determine = that you have
moved, which would then retrigger DHC (as = appropriate). I could
imagine an RA option that included a unique = identifier for the link
(this might be useful for mobility in general). Or, = you could just see
of the router you were using has changed (its = link-local address is an
identifier). Or, use the set of on-link prefixes on = the RA. If they
are the same as before, you presumably haven't = moved. Having the
client send DHC messages to the server to determine = whether it has
moved seems like a fair amount of overhead and sub = optimal.

Also, if one dropped the movement detection from DHC, = would this allow
you to do away with the Confirm? I.e., if a client = detects that it has
moved, then just have it redo the normal DHC = exchanges. That would
seem simpler. Plus, if a node has actually moved, = the confirm will
fail, and the normal DHC exchanges have to be used = anyway.

Thomas

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

------_=_NextPart_001_01C1F6AB.A020A8E0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 12:22:00 2002 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 MAA15577 for ; Wed, 8 May 2002 12:22:00 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12163 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:22:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12074; Wed, 8 May 2002 12:20:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12057 for ; Wed, 8 May 2002 12:20:17 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15442 for ; Wed, 8 May 2002 12:20:10 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g48GJli17747 for ; Wed, 8 May 2002 11:19:47 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48GJkE29712 for ; Wed, 8 May 2002 11:19:46 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 08 11:19:43 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:19:43 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3C0@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: sending Information-request via multicast Date: Wed, 8 May 2002 11:19:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6AC.2785EA20" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6AC.2785EA20 Content-Type: text/plain; charset="iso-8859-1" Yes, this same issue has given us some concern in 3G standardization. Link-local multicast is always safe to use (but does require a Relay). The general multicast issue for non-link local still haven't been fully resolved (at least to my understanding), so using a site scoped multicast address is potentially a problem until general multicast support is wide-spread. I'd recommend we require the use of the link-local multicast and remove the ability to send the Information-Request to the site scoped multicast. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:08 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: sending Information-request via multicast > If the client has an IPv6 address of sufficient scope, the > client MAY choose to send the Information-request message to the > All_DHCP_Servers multicast address. This MAY leaves things very ambiguous. When should they do this? When not? It would be much better to have a clear algorithm the client always follows. Otherwise, you'll get different implementations doing different things, which is probably not good for interoperability. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6AC.2785EA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: sending Information-request via = multicast

Yes, this same issue has given us some concern in 3G = standardization.

Link-local multicast is always safe to use (but does = require a Relay). The general multicast issue for non-link local still = haven't been fully resolved (at least to my understanding), so using a = site scoped multicast address is potentially a problem until general = multicast support is wide-spread.

I'd recommend we require the use of the link-local = multicast and remove the ability to send the Information-Request to the = site scoped multicast.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:08 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: sending = Information-request via multicast

>    If the client has an IPv6 = address of sufficient scope, the
>    client MAY choose to send the = Information-request message to the
>    All_DHCP_Servers multicast = address.

This MAY leaves things very ambiguous. When should = they do this? When
not? It would be much better to have a clear = algorithm the client
always follows. Otherwise, you'll get different = implementations doing
different things, which is probably not good for = interoperability.

Thomas

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

------_=_NextPart_001_01C1F6AC.2785EA20-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 12:31:21 2002 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 MAA15823 for ; Wed, 8 May 2002 12:31:21 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA12919 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 12:31:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12364; Wed, 8 May 2002 12:27:38 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA12340 for ; Wed, 8 May 2002 12:27:35 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15743 for ; Wed, 8 May 2002 12:27:27 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g48GRYl07293 for ; Wed, 8 May 2002 11:27:34 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48GRYE02946 for ; Wed, 8 May 2002 11:27:34 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 08 11:27:33 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 11:27:33 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3C2@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: response to a release message Date: Wed, 8 May 2002 11:27:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6AD.3DF5F970" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6AD.3DF5F970 Content-Type: text/plain; charset="iso-8859-1" Yes, I think this needs to be fixed as well. My suggestion is as follows. In the Reply: - the server always sends a Status Code option of Success outside of any IA-type options. [I would agrue why bother sending this, but if people want it, we'll send it.] - for each IAID that the server has no binding information, the server should add the IA-type option and encapsulate a Status Code option w/NoBinding. No other options should be encapsulated within the IA-type option. The main point is that a client must stop retransmitting the Release (*and Decline*) once a reply is received. The fact that the server had no record of a binding isn't really important - it is just informational for the client (and can happen anyway in cases where the Release/Decline is retransmitted and all addresses for the IA were released/declined). - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:14 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: response to a release message > After all the addresses have been processed, the server generates a > Reply message and includes a Status Code option with value Success > and a Server Identifier option with the server's DUID. The server > MUST NOT include any other options in the Reply message. > If the server cannot find a binding for the client, the server > sends a Reply message that includes a Status Code option with value > NoBinding. I can't quite tell what is supposed to happen if there are mixture of successes and failures. If there are failures, are multiple IAs returned indicating which ones were released successfully and which were not? The text seems to say no, no other options other than that Status Code. Seems like a simple success/fail for *all* the addresses will leave the client unsure of what state the various addresses are in. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6AD.3DF5F970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: response to a release message

Yes, I think this needs to be fixed as well.

My suggestion is as follows. In the Reply:

- the server always sends a Status Code option of = Success outside of any IA-type options. [I would agrue why bother = sending this, but if people want it, we'll send it.]

- for each IAID that the server has no binding = information, the server should add the IA-type option and encapsulate a = Status Code option w/NoBinding. No other options should be encapsulated = within the IA-type option.

The main point is that a client must stop = retransmitting the Release (*and Decline*) once a reply is received. = The fact that the server had no record of a binding isn't really = important - it is just informational for the client (and can happen = anyway in cases where the Release/Decline is retransmitted and all = addresses for the IA were released/declined).

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:14 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: response to a release = message

>    After all the addresses have = been processed, the server generates a
>    Reply message and includes a = Status Code option with value Success
>    and a Server Identifier = option with the server's DUID. The server
>    MUST NOT include any other = options in the Reply message.

>    If the server cannot find a = binding for the client, the server
>    sends a Reply message that = includes a Status Code option with value
>    NoBinding.

I can't quite tell what is supposed to happen if = there are mixture of
successes and failures. If there are failures, are = multiple IAs
returned indicating which ones were released = successfully and which
were not? The text seems to say no, no other options = other than that
Status Code.

Seems like a simple success/fail for *all* the = addresses will leave
the client unsure of what state the various = addresses are in.

Thomas

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

------_=_NextPart_001_01C1F6AD.3DF5F970-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 14:06:26 2002 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 OAA19089 for ; Wed, 8 May 2002 14:06:26 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA18991 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 14:06:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18846; Wed, 8 May 2002 14:03:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18819 for ; Wed, 8 May 2002 14:03:19 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18999 for ; Wed, 8 May 2002 14:03:06 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g48I3El20607 for ; Wed, 8 May 2002 13:03:14 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48I3Ds08867 for ; Wed, 8 May 2002 13:03:13 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 08 13:03:13 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 13:03:13 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3C3@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Interface-ID option Date: Wed, 8 May 2002 13:03:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6BA.9CD9BD70" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6BA.9CD9BD70 Content-Type: text/plain; charset="iso-8859-1" Thomas: The link-address field is always used by the server to determine what link the client is on. The interface-id is for use by the relay to help it return the response from the server to the client. The reasons for having this include: - It could be that the link-address field isn't specific enough. Perhaps there are a bunch of circuits all with one prefix (the link-address) but the response must be sent to the client over the correct circuit. Hence, the circuit information can be stored by the relay in the interface-id option. - Even if the link-address is sufficient, the interface-id could be used as an optimization by the relay. So: >If it is >included, but there is no valid link-address (which I understand is >the reason for defining this particular option), how does the server >know which addresses to assign the client? I.e., how does the server >know on which link the client is? No, there must always be a valid link-address. It just isn't specific enough. > The relay agent puts the client's address in the link-address field > regardless of whether the relay agent includes an Interface-id option > in the Relay-forward message. Agreed. This is wrong and needs to be fixed. It should say: The relay agent puts a global or site-scoped address with a prefix assigned to the link on which the client should be assigned an address in the link-address field regardless of whether the relay agent includes an Interface-id option in the Relay-forward message. (This is essentially the text in 20.1). >Shouldn't the first MAY be a MUST? I.e., the link-address field >contains no useful information. No. The server only needs to the link-address to do address assignment in general. There could be instances where a specific relay/server arrangement exists and the server might want to consider the Interface-ID value (for classing, access control, etc). >Any reaosn not to make this 32 bits? the IPv6 API already has 32-bit >interface IDs. Is there any reason to make it larger? I think it best to keep it variable-length since relays may use this for optimization reasons. For example, in 3G specs we were thinking of allowing the PDP-Context number on the GGSN to be carried in this field (this speeds the return of the reply to the client). While this might fit into 32-bits, why force it? - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:10 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: Interface-ID option > If the relay agent cannot use the address in the link-address field > to identify the interface through which the response to the client > will be forwarded, the relay agent MUST include an Interface-id > option (see section 22.19) in the Relay-forward message. The server I think the interface-id option may be underspecified. If it is included, but there is no valid link-address (which I understand is the reason for defining this particular option), how does the server know which addresses to assign the client? I.e., how does the server know on which link the client is? > The relay agent puts the client's address in the link-address field > regardless of whether the relay agent includes an Interface-id option > in the Relay-forward message. This doesn't seem right to me. I thought that the link-address is supposed to hold the address of the relay agent. Seems wrong to put the client's address in it. The link-address field is what the server uses to figure out which link the client is on (right?). Also, since the client's address is a link-local address, this field doesn't seem to contain useful information for the server in this case. > Servers MAY use the Interface-ID for parameter assignment policies. > The Interface-ID SHOULD be considered an opaque value, with policies > based on exact string match only; that is, the Interface-ID SHOULD > NOT be internally parsed by the server. Shouldn't the first MAY be a MUST? I.e., the link-address field contains no useful information. Also, not sure the above is sufficient. Unless the interface-identifier is somehow stable, it's not clear how the server policy could take it into account. There are no words suggesting the interface-identifier needs to be stable. > interface-id An opaque value of arbitrary length generated > by the relay agent to identify one of the > relay agent's interfaces Any reaosn not to make this 32 bits? the IPv6 API already has 32-bit interface IDs. Is there any reason to make it larger? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6BA.9CD9BD70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Interface-ID option

Thomas:

The link-address field is always used by the server = to determine what link the client is on.

The interface-id is for use by the relay to help it = return the response from the server to the client.

The reasons for having this include:
- It could be that the link-address field isn't = specific enough. Perhaps there are a bunch of circuits all with one = prefix (the link-address) but the response must be sent to the client = over the correct circuit. Hence, the circuit information can be stored = by the relay in the interface-id option.

- Even if the link-address is sufficient, the = interface-id could be used as an optimization by the relay.

So:

>If it is
>included, but there is no valid link-address = (which I understand is
>the reason for defining this particular option), = how does the server
>know which addresses to assign the client? I.e., = how does the server
>know on which link the client is?

No, there must always be a valid link-address. It = just isn't specific enough.

>    The relay agent puts the = client's address in the link-address field
>    regardless of whether the = relay agent includes an Interface-id option
>    in the Relay-forward = message.

Agreed. This is wrong and needs to be fixed. It = should say:

   The relay agent puts a global or = site-scoped address with a prefix
   assigned to the link on which the = client should be assigned an
   address in the link-address field = regardless of whether the relay
   agent includes an Interface-id option = in the Relay-forward message.

(This is essentially the text in 20.1).

>Shouldn't the first MAY be a MUST? I.e., the = link-address field
>contains no useful information.

No. The server only needs to the link-address to do = address assignment in general. There could be instances where a = specific relay/server arrangement exists and the server might want to = consider the Interface-ID value (for classing, access control, = etc).

>Any reaosn not to make this 32 bits? the IPv6 API = already has 32-bit
>interface IDs. Is there any reason to make it = larger?

I think it best to keep it variable-length since = relays may use this for optimization reasons. For example, in 3G specs = we were thinking of allowing the PDP-Context number on the GGSN to be = carried in this field (this speeds the return of the reply to the = client). While this might fit into 32-bits, why force it?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:10 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: Interface-ID = option

>    If the relay agent cannot use = the address in the link-address field
>    to identify the interface = through which the response to the client
>    will be forwarded, the relay = agent MUST include an Interface-id
>    option (see section 22.19) in = the Relay-forward message. The server

I think the interface-id option may be = underspecified. If it is
included, but there is no valid link-address (which = I understand is
the reason for defining this particular option), how = does the server
know which addresses to assign the client? I.e., how = does the server
know on which link the client is?

>    The relay agent puts the = client's address in the link-address field
>    regardless of whether the = relay agent includes an Interface-id option
>    in the Relay-forward = message.

This doesn't seem right to me. I thought that the = link-address is
supposed to hold the address of the relay agent. = Seems wrong to put
the client's address in it. The link-address field = is what the server
uses to figure out which link the client is on = (right?). Also, since
the client's address is a link-local address, this = field doesn't seem
to contain useful information for the server in this = case.

>    Servers MAY use the = Interface-ID for parameter assignment policies.
>    The Interface-ID SHOULD be = considered an opaque value, with policies
>    based on exact string match = only; that is, the Interface-ID SHOULD
>    NOT be internally parsed by = the server.

Shouldn't the first MAY be a MUST? I.e., the = link-address field
contains no useful information.

Also, not sure the above is sufficient. Unless = the
interface-identifier is somehow stable, it's not = clear how the server
policy could take it into account. There are no = words suggesting the
interface-identifier needs to be stable.

>       = interface-id         An opaque = value of arbitrary length generated
>          = ;            = ;      by the relay agent to identify one of = the
>          = ;            = ;      relay agent's interfaces

Any reaosn not to make this 32 bits? the IPv6 API = already has 32-bit
interface IDs. Is there any reason to make it = larger?

Thomas

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

------_=_NextPart_001_01C1F6BA.9CD9BD70-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 14:23:45 2002 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 OAA19502 for ; Wed, 8 May 2002 14:23:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA19669 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 14:23:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19473; Wed, 8 May 2002 14:20:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA19407 for ; Wed, 8 May 2002 14:20:17 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19395 for ; Wed, 8 May 2002 14:20:08 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g48IJgi24329 for ; Wed, 8 May 2002 13:19:42 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48IJgs18517 for ; Wed, 8 May 2002 13:19:42 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed May 08 13:19:41 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 13:19:41 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3C4@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Temporary addresses Date: Wed, 8 May 2002 13:19:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6BC.E7A613B0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6BC.E7A613B0 Content-Type: text/plain; charset="iso-8859-1" I don't have a problem in allowing IA_TAs to be in Renew/Rebind. It wasn't clear from our previous discussions on this subject whether we needed that capability or not. One question is whether to modify the IA_TA option to be basically the same format as the IA option and include T1/T2 times. I would say NO. Instead, for IA_TAs, it is up to the client to initiate a Renew (and eventually Rebind) should it want to extend the lifetimes. Normally, the lifetimes are not extended (unless the client needs to do so). I think this matches the RFC 3041 behavior? The changes should be fairly minor to accommodate this. More text on when to get a new set of temp addresses also makes sense (as you proposed). A new set of temp addresses will require a new IA_TA IAID. The following text: > A server MUST return the same set of temporary address for the same > IA_TA (as identified by the IAID) as long as those addresses are > still valid. After the lifetimes of the addresses in an IA_TA have > expired, the IAID may be reused to identify a new IA_TA with new > temporary addresses. was in reference to a Request. We wanted to be clear on what happens should a server receive a Request with the same IAID in a IA_TA option that it already sent a Reply to. This could happen, for example, because of retransmissions or if the client "crashes" before receiving the initial Reply and reuses the same IAID when booting perhaps several hours later. Anyway, the point was that in a Request, if the IA_TA IAID is the for an existing binding, the server should return that existing binding if the lifetimes are still reasonable. We might think about whether we should change "are still valid" to "are still preferred"? - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 08, 2002 11:12 AM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: Temporary addresses > A server MUST return the same set of temporary address for the same > IA_TA (as identified by the IAID) as long as those addresses are > still valid. After the lifetimes of the addresses in an IA_TA have > expired, the IAID may be reused to identify a new IA_TA with new > temporary addresses. I don't think the above is what we want. A Client should be able to renew/extend lifetimes for temp addresses *if* they want. But in general, they won't. (Note this is also allowed in 3041 in the sense that this is left open as a possibility -- I don't see a need for DHC to preclude this from being done) Ralph asked: > The basic question is "can a client ask and a server agree to extend > the lifetimes on temp addresses". If lifetimes on temp addresses can > be extended, how are they different from non-temp addresses? Good > question to discuss in WG. They are different in that applications can specifically request that temp addresses be used for communication, *or* that temp addresses NOT be used. Thus, there has to be a way to distinguish between temp and non-temp addresses. Also, I believe that a node might be using several sets of temp addresses simultaneously. Normally, that would mean one set that is "preferred", but there could be a number of others that are "deprecated", meaning not to be used for new communication, but still available to the applications that are already using them. If an application is still using a temp address, it may need to extend the valid Lifetime to prevent the address from going away. This also raises a different point. There should be more text about when to get a new set of temp addresses. I.e., one could point to 3041 for guidance on when to get a new one and use similar rules. I.e., unlike permanent addresses, the normal action when a temporary address becomes deprecated is to request a new (i.e., different) one. The old one still remains for a while, but is being phased out. In contrast, for public/global addresses, the normal action is to renew the *same* address and extend its preferred lifetime. > An identity association for temporary addresses option MUST NOT > appear in a Renew or Rebind message. This option MAY appear in a > Confirm message if the lifetimes on the temporary addresses in the > associated IA have not expired. If the client wants to extend a binding (perhaps an application is still using that address) it should not be prohibited by the protocol from doing so. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6BC.E7A613B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Temporary addresses

I don't have a problem in allowing IA_TAs to be in = Renew/Rebind. It wasn't clear from our previous discussions on this = subject whether we needed that capability or not.

One question is whether to modify the IA_TA option to = be basically the same format as the IA option and include T1/T2 times. = I would say NO. Instead, for IA_TAs, it is up to the client to initiate = a Renew (and eventually Rebind) should it want to extend the lifetimes. = Normally, the lifetimes are not extended (unless the client needs to do = so). I think this matches the RFC 3041 behavior?

The changes should be fairly minor to accommodate = this.

More text on when to get a new set of temp addresses = also makes sense (as you proposed). A new set of temp addresses will = require a new IA_TA IAID.

The following text:

>    A server MUST return the same = set of temporary address for the same
>    IA_TA (as identified by the = IAID) as long as those addresses are
>    still valid. After the = lifetimes of the addresses in an IA_TA have
>    expired, the IAID may be = reused to identify a new IA_TA with new
>    temporary addresses.

was in reference to a Request. We wanted to be clear = on what happens should a server receive a Request with the same IAID in = a IA_TA option that it already sent a Reply to. This could happen, for = example, because of retransmissions or if the client = "crashes" before receiving the initial Reply and reuses the = same IAID when booting perhaps several hours later. Anyway, the point = was that in a Request, if the IA_TA IAID is the for an existing = binding, the server should return that existing binding if the = lifetimes are still reasonable. We might think about whether we should = change "are still valid" to "are still = preferred"?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 08, 2002 11:12 AM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: Temporary = addresses

I don't think the above is what we want. A Client = should be able to
renew/extend lifetimes for temp addresses *if* they = want. But in
general, they won't. (Note this is also allowed in = 3041 in the sense
that this is left open as a possibility -- I don't = see a need for DHC
to preclude this from being done)

Ralph asked:

> The basic question is "can a client ask and = a server agree to extend
> the lifetimes on temp addresses". If = lifetimes on temp addresses can
> be extended, how are they different from = non-temp addresses? Good
> question to discuss in WG.

They are different in that applications can = specifically request that
temp addresses be used for communication, *or* that = temp addresses NOT
be used. Thus, there has to be a way to distinguish = between temp and
non-temp addresses. Also, I believe that a node = might be using several
sets of temp addresses simultaneously. Normally, = that would mean one
set that is "preferred", but there could = be a number of others that
are "deprecated", meaning not to be used = for new communication, but
still available to the applications that are already = using them. If an
application is still using a temp address, it may = need to extend the
valid Lifetime to prevent the address from going = away.

This also raises a different point. There should be = more text about
when to get a new set of temp addresses. I.e., one = could point to 3041
for guidance on when to get a new one and use = similar rules. I.e.,
unlike permanent addresses, the normal action when a = temporary address
becomes deprecated is to request a new (i.e., = different) one. The old
one still remains for a while, but is being phased = out. In contrast,
for public/global addresses, the normal action is to = renew the *same*
address and extend its preferred lifetime.

>    An identity association for = temporary addresses option MUST NOT
>    appear in a Renew or Rebind = message. This option MAY appear in a
>    Confirm message if the = lifetimes on the temporary addresses in the
>    associated IA have not = expired.

If the client wants to extend a binding (perhaps an = application is
still using that address) it should not be = prohibited by the
protocol from doing so.

Thomas

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

------_=_NextPart_001_01C1F6BC.E7A613B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 17:09:42 2002 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 RAA23984 for ; Wed, 8 May 2002 17:09:41 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA28265 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 17:09:50 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28215; Wed, 8 May 2002 17:08:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01873 for ; Tue, 7 May 2002 02:39:26 -0400 (EDT) Received: from mail03.vsnl.net (mail03.vsnl.net [203.197.12.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28758 for ; Tue, 7 May 2002 02:39:16 -0400 (EDT) Received: from Sudheesh ([203.115.109.66]) by mail03.vsnl.net (Netscape Messaging Server 4.15) with ESMTP id GVQAHH00.BT3 for ; Tue, 7 May 2002 12:09:17 +0530 Message-ID: <003801c1f592$1fb265a0$de00000a@Sudheesh> From: "Sudheesh" To: Date: Tue, 7 May 2002 12:10:36 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Coding a DHCP client using JDHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Hi, I'm trying to code a complete DHCP client using JDHCP . I would like to know if it is possible to get the physical address of a system with Java code. I have checked the JDHCP package, but haven't found any help with this. I would also like to know how to bind the physical address with the yaddress in the DHCP response I got. thanks in advance Sudheesh _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 17:11:20 2002 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 RAA24058 for ; Wed, 8 May 2002 17:11:19 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA28360 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 17:11:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA28298; Wed, 8 May 2002 17:09:56 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA08313 for ; Wed, 8 May 2002 03:01:00 -0400 (EDT) Received: from mail.imp.ch (root@mail.imp.ch [157.161.1.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27747 for ; Wed, 8 May 2002 03:00:52 -0400 (EDT) Received: from harem.imp.ch (harem.imp.ch [157.161.4.8]) by mail.imp.ch (8.11.6/8.11.6) with ESMTP id g4870rx35269; Wed, 8 May 2002 09:00:53 +0200 (CEST) Received: from localhost (patg@localhost) by harem.imp.ch (8.11.2/8.11.2) with ESMTP id g4870qj573696; Wed, 8 May 2002 09:00:52 +0200 (MES) X-Authentication-Warning: harem.imp.ch: patg owned process doing -bs Date: Wed, 8 May 2002 09:00:52 +0200 From: Patrick Guelat To: Steve Gonczi cc: "Cosmo, Patrick" , Subject: RE: [dhcwg] Interpretation of Option 60 (Vendor Class ID) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Steve, I agree with you that there is no implication on the character set to be used. But the term 'string' implies for me that it `could' be zero terminated, i.e. that it's ok to treat zero as a termination character in that case. If this is not the case, 'string' should be changed to 'array' imho. -Patrick -- Patrick Guelat, ImproWare AG Network Services, CH-4133 Pratteln Mail: patg@imp.ch - Phone: +41 61 826 93 00 (ext: 13) On Tue, 7 May 2002, Steve Gonczi wrote: > Interpretation of Option 60 (Vendor Class ID)IMHO it is meant to be an array > of unsigned bytes. > > The authors would have spelled out any formatting restrictions, such as a > specific > character set, or required zero termination if they had that in mind. > > You will see that they did so in other cases. ( e.g.: section 9.9). > > Because the authors did not restrict the allowed octet values in any way, we > can not safely > use a zero termination convention. ( embedded zeros are allowed by the > definition) > > /sG > -----Original Message----- > From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of > Cosmo, Patrick > Sent: Tuesday, May 07, 2002 9:41 AM > To: dhcwg@ietf.org > Subject: [dhcwg] Interpretation of Option 60 (Vendor Class ID) > > RFC 2132 states that option 60 "is a string of n octets". We are having a > little debate about how to interpret this and would like to know how others, > and the working group, interpret this option. > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 17:45:38 2002 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 RAA24646 for ; Wed, 8 May 2002 17:45:38 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00317 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 17:45:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00129; Wed, 8 May 2002 17:44:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00105 for ; Wed, 8 May 2002 17:44:01 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24559 for ; Wed, 8 May 2002 17:43:47 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g48LhOi09971 for ; Wed, 8 May 2002 16:43:24 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g48LhOx00300 for ; Wed, 8 May 2002 16:43:24 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed May 08 16:43:23 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 16:43:23 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3CE@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" , Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Wed, 8 May 2002 16:43:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6D9.5ED443F0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org 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_01C1F6D9.5ED443F0 Content-Type: text/plain; charset="iso-8859-1" Perhaps we can reword 18.1.2 to not make this required (MUST)? For example, if the client has another means of determining whether it is still on the same link (such as it receives a RA) and wants to use that technique (since it might do that for stateless autoconfigured addresses), there is no requirement that it use Confirm (if it determines that it is on a new link)? Perhaps stated more clearly ... if the client has determined through some other means that it has moved to a new link, it need not use Confirm. Otherwise, a client SHOULD use a Confirm/Reply message exchange when it believes it may have moved to a new link. I didn't find anything in the Stateless Autoconfiguration RFC that covers this case, but it would seem to me that if a client has determined (through RAs?) that it is on a new link, it would want to reset the ManagedFlag & OtherConfigFlag based on the RAs received on that new link. Hence, a Confirm might not even make sense if that new link is using Stateless since there will be no DHCP servers to respond (and if it followed the specification as we currently have it written, it would use the old configuration information). - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, May 08, 2002 11:37 AM To: Thomas Narten Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message What we've described in this section is precisely how the most functional DHCPv4 clients operate today - e.g., the Apple DHCPv4 client does link change detection, and in practice the user experience is much better than what you get with the ISC dhcp client, which does not do link change detection. The confirm message is necessary. Using RA messages to do link change detection is great, and we talked about it, but as you say, it requires an additional RA option on whose presence we cannot count at this time. So I would say we should leave this just the way it is. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6D9.5ED443F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: movement detection and Confirm = message

Perhaps we can reword 18.1.2 to not make this = required (MUST)?

For example, if the client has another means of = determining whether it is still on the same link (such as it receives a = RA) and wants to use that technique (since it might do that for = stateless autoconfigured addresses), there is no requirement that it = use Confirm (if it determines that it is on a new link)?

Perhaps stated more clearly ... if the client has = determined through some other means that it has moved to a new link, it = need not use Confirm. Otherwise, a client SHOULD use a Confirm/Reply = message exchange when it believes it may have moved to a new = link.

I didn't find anything in the Stateless = Autoconfiguration RFC that covers this case, but it would seem to me = that if a client has determined (through RAs?) that it is on a new = link, it would want to reset the ManagedFlag & OtherConfigFlag = based on the RAs received on that new link. Hence, a Confirm might not = even make sense if that new link is using Stateless since there will be = no DHCP servers to respond (and if it followed the specification as we = currently have it written, it would use the old configuration = information).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Wednesday, May 08, 2002 11:37 AM
To: Thomas Narten
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: movement detection = and Confirm message

What we've described in this section is precisely how = the most functional
DHCPv4 clients operate today - e.g., the Apple = DHCPv4 client does link
change detection, and in practice the user = experience is much better than
what you get with the ISC dhcp client, which does = not do link change
detection. The confirm message is = necessary. Using RA messages to do
link change detection is great, and we talked about = it, but as you say, it
requires an additional RA option on whose presence = we cannot count at this
time.

So I would say we should leave this just the way it = is.

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

------_=_NextPart_001_01C1F6D9.5ED443F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From daemon@optimus.ietf.org Wed May 8 17:50:48 2002 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 RAA24757 for ; Wed, 8 May 2002 17:50:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA00652 for dhcwg-archive@odin.ietf.org; Wed, 8 May 2002 17:50:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00488; Wed, 8 May 2002 17:47:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00461 for ; Wed, 8 May 2002 17:46:58 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24689 for ; Wed, 8 May 2002 17:46:49 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g48LjrS10411; Wed, 8 May 2002 14:45:53 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g48Lkq600544; Wed, 8 May 2002 16:46:52 -0500 (CDT) Date: Wed, 8 May 2002 16:46:51 -0500 Subject: Re: [dhcwg] Interpretation of Option 60 (Vendor Class ID) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: Steve Gonczi