From mailman-owner@ietf.org Wed May 1 06:21:47 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 GAA16135 for ; Wed, 1 May 2002 06:21:47 -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 GAA29692 for ; Wed, 1 May 2002 06:21:49 -0400 (EDT) Date: Wed, 1 May 2002 06:21:49 -0400 (EDT) Message-Id: <200205011021.GAA29692@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: dhc-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for dhc-archive@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive@lists.ietf.org From dhcwg-admin@ietf.org Thu May 2 05:50:23 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 FAA05366; Thu, 2 May 2002 05:50: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 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 dhcwg-admin@ietf.org Thu May 2 19:03:13 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 TAA18953; Thu, 2 May 2002 19:03:13 -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 dhcwg-admin@ietf.org Fri May 3 07:28:10 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 HAA09570; Fri, 3 May 2002 07:28:10 -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 dhcwg-admin@ietf.org Mon May 6 10:59:16 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 KAA22268; Mon, 6 May 2002 10:59: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 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 dhcwg-admin@ietf.org Tue May 7 05:31: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 FAA00880; Tue, 7 May 2002 05:31:53 -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 dhcwg-admin@ietf.org Tue May 7 08:38: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 IAA05018; Tue, 7 May 2002 08:38: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 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 dhcwg-admin@ietf.org Tue May 7 08:41: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 IAA05195; Tue, 7 May 2002 08:41:51 -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 dhcwg-admin@ietf.org Tue May 7 08:57: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 IAA05803; Tue, 7 May 2002 08:57: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 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 dhcwg-admin@ietf.org Tue May 7 09:35: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 JAA07431; Tue, 7 May 2002 09:35: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 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 dhcwg-admin@ietf.org Tue May 7 10:50: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 KAA10613; Tue, 7 May 2002 10:50: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 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 dhcwg-admin@ietf.org Tue May 7 11:30:28 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 LAA12538; Tue, 7 May 2002 11:30: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 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 dhcwg-admin@ietf.org Tue May 7 12:01: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 MAA13831; Tue, 7 May 2002 12:01:51 -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 dhcwg-admin@ietf.org Tue May 7 12:55: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 MAA15562; Tue, 7 May 2002 12:55:53 -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 dhcwg-admin@ietf.org Tue May 7 15:42:35 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 PAA21967; Tue, 7 May 2002 15:42: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 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 dhcwg-admin@ietf.org Tue May 7 19:52:06 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 TAA27306; Tue, 7 May 2002 19:52: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 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 dhcwg-admin@ietf.org Wed May 8 00:18: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 AAA02870; Wed, 8 May 2002 00:18:29 -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 dhcwg-admin@ietf.org Wed May 8 10:01: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 KAA07598; Wed, 8 May 2002 10:01:12 -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 dhcwg-admin@ietf.org Wed May 8 10:07: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 KAA07920; Wed, 8 May 2002 10:07:53 -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 dhcwg-admin@ietf.org Wed May 8 10:59:46 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 KAA10641; Wed, 8 May 2002 10:59: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 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 dhcwg-admin@ietf.org Wed May 8 11:03:31 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 LAA10853; Wed, 8 May 2002 11:03: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 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 dhcwg-admin@ietf.org Wed May 8 11:03: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 LAA10879; Wed, 8 May 2002 11:03:53 -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 dhcwg-admin@ietf.org Wed May 8 11:06: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 LAA10978; Wed, 8 May 2002 11:06: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 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 dhcwg-admin@ietf.org Wed May 8 11:08:06 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 LAA11026; Wed, 8 May 2002 11:08: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 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 dhcwg-admin@ietf.org Wed May 8 11:08: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 LAA11053; Wed, 8 May 2002 11:08: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 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 dhcwg-admin@ietf.org Wed May 8 11:08:32 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 LAA11104; Wed, 8 May 2002 11:08:32 -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 dhcwg-admin@ietf.org Wed May 8 11:09: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 LAA11216; Wed, 8 May 2002 11:09: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 dhcwg-admin@ietf.org Wed May 8 11:10:13 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 LAA11345; 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 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 dhcwg-admin@ietf.org Wed May 8 11:11: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 LAA11491; Wed, 8 May 2002 11:11: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 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 dhcwg-admin@ietf.org Wed May 8 11:12: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 LAA11530; Wed, 8 May 2002 11:12: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 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 dhcwg-admin@ietf.org Wed May 8 11:12:47 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 LAA11612; Wed, 8 May 2002 11:12:47 -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 dhcwg-admin@ietf.org Wed May 8 11:13:06 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 LAA11679; Wed, 8 May 2002 11:13: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 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 dhcwg-admin@ietf.org Wed May 8 11:13: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 LAA11749; Wed, 8 May 2002 11:13: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 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 dhcwg-admin@ietf.org Wed May 8 11:14: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 LAA11832; Wed, 8 May 2002 11:14: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 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 dhcwg-admin@ietf.org Wed May 8 11:32: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 LAA12808; Wed, 8 May 2002 11:32: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 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 dhcwg-admin@ietf.org Wed May 8 11:34:16 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 LAA12919; Wed, 8 May 2002 11:34: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 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 dhcwg-admin@ietf.org Wed May 8 11:39:10 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 LAA13345; Wed, 8 May 2002 11:39: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 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 dhcwg-admin@ietf.org Wed May 8 11:48: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 LAA13884; Wed, 8 May 2002 11:48: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 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 dhcwg-admin@ietf.org Wed May 8 12:00:23 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 MAA14288; Wed, 8 May 2002 12:00: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 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 dhcwg-admin@ietf.org Wed May 8 12:05:50 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 MAA14525; Wed, 8 May 2002 12:05: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 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 dhcwg-admin@ietf.org Wed May 8 12:09: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 MAA14678; Wed, 8 May 2002 12:09: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 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 dhcwg-admin@ietf.org Wed May 8 12:10:02 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 MAA14747; Wed, 8 May 2002 12:10:02 -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 dhcwg-admin@ietf.org Wed May 8 12:10: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 MAA14771; Wed, 8 May 2002 12:10:05 -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 dhcwg-admin@ietf.org Wed May 8 12:12: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 MAA14961; Wed, 8 May 2002 12:12:12 -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 dhcwg-admin@ietf.org Wed May 8 12:13: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 MAA15007; Wed, 8 May 2002 12:13:17 -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 dhcwg-admin@ietf.org Wed May 8 12:18:04 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 MAA15317; Wed, 8 May 2002 12:18:03 -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 dhcwg-admin@ietf.org Wed May 8 12:20:46 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 MAA15492; Wed, 8 May 2002 12:20: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 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 dhcwg-admin@ietf.org Wed May 8 12:28:58 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 MAA15768; Wed, 8 May 2002 12:28:58 -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 dhcwg-admin@ietf.org Wed May 8 14:04:32 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 OAA19018; Wed, 8 May 2002 14:04:32 -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 dhcwg-admin@ietf.org Wed May 8 14:21: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 OAA19405; Wed, 8 May 2002 14:21:12 -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


>    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-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 8 17:08:43 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 RAA23942; Wed, 8 May 2002 17:08:43 -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 dhcwg-admin@ietf.org Wed May 8 17:10: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 RAA24001; Wed, 8 May 2002 17:10: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 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 dhcwg-admin@ietf.org Wed May 8 17:44:44 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 RAA24578; Wed, 8 May 2002 17:44: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 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 dhcwg-admin@ietf.org Wed May 8 17:47: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 RAA24701; Wed, 8 May 2002 17:47:33 -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 , "Cosmo, Patrick" , To: Patrick Guelat From: Ted Lemon In-Reply-To: Message-Id: <1B41C9AC-62CD-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 At this point, there is no way to undo the misunderstanding about option 60. You can't count on it being ASCII text. If you get an option from a client that might be a string, and might be zero-terminated, that doesn't mean you should ever pass it to strcmp(). The presence of zero-termination in rfc2131 is a mistake. It shouldn't be there. It's documenting the behavior of certain broken clients, which is not something an RFC should do, and it does it in a way that encourages new implementors to implement their clients in a broken way, which is really bad. If you are implementing a client, do not ever zero-terminate. Then you won't have to worry about this. If you are implementing a server, and the user supplies you with ASCII text, then when comparing that ASCII text with the option's value, if the last byte in the option is zero, you can decrement the length of the option value sent by the client before doing the comparison. If the user supplies you with binary data, you have to do a binary comparison - if there's supposed to be a zero at the end, the user has to supply it. There's no reason to make this any more complicated than it already is. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 8 17:53: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 RAA24801; Wed, 8 May 2002 17:53:12 -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 RAA00770; Wed, 8 May 2002 17:52:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA00738 for ; Wed, 8 May 2002 17:52:46 -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 RAA24796 for ; Wed, 8 May 2002 17:52:37 -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 g48LphS10430; Wed, 8 May 2002 14:51:43 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g48Lqg600560; Wed, 8 May 2002 16:52:42 -0500 (CDT) Date: Wed, 8 May 2002 16:52:42 -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: Thomas Narten , dhcwg@ietf.org To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3CE@EAMBUNT705> 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 Probably the right way to do this is to say that if the client has reason to believe, based on the listed reasons or any other reasons, that it is on a different link, but that it cannot be sure it is on a different link, it SHOULD send a Confirm message. If it is _sure_ that it is on another link (e.g., based on an RA), it SHOULD send a Solicit message. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 8 19:52: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 TAA26452; Wed, 8 May 2002 19:52: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 TAA06024; Wed, 8 May 2002 19:51: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 TAA06000 for ; Wed, 8 May 2002 19:51:55 -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 TAA26418 for ; Wed, 8 May 2002 19:51:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27848 for ; Wed, 8 May 2002 19:51:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508193307.03149740@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 19:38:17 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhcpv6-24: randomization delay before invoking DHC In-Reply-To: <200205081500.g48F0Qw19144@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 comment (below) raised a question in my mind. Is the state of the managedFlag always go to FALSE or is it maintained across systems restarts? That is, does a host always come up in stateless mode and then switch to stateful upon receipt of the first RA. If the client does always come up in stateless mode, does the following text cause the first Solicit to be delayed until at least the receipt of the first RA? 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). At 11:00 AM 5/8/2002 -0400, Thomas Narten wrote: >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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 8 19:52: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 TAA26475; Wed, 8 May 2002 19:52: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 TAA06072; Wed, 8 May 2002 19:52:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA06043 for ; Wed, 8 May 2002 19:52:01 -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 TAA26420 for ; Wed, 8 May 2002 19:51:52 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27852; Wed, 8 May 2002 19:51:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508193825.03139d18@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 19:44:30 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhcpv6-24: Rapid Commit Cc: rdroms@cisco.com In-Reply-To: <200205081505.g48F5XQ19207@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 At 11:05 AM 5/8/2002 -0400, Thomas Narten wrote: >This is a new addition relative to -23. I'm still trying to understand >what its actual value is. The value is to allow a two message exchange for address assignment in certain situations. > 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? One scenario in which this is useful is when a service provider implements a DHCP server in its edge router. There is reduced need for server redundancy - if the router isn't running, the subscriber can't use the network, anyway. The subscriber CPE talks to one server, the one in the router. >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). Guidance is probably appropriate... > > 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? The authors did discuss allowing a server respond with an Advertise to a Solicit/Rapid Commit. In that way, the client could proceed with a four message exchange with no penalty. In practice, although we haven't captured this well in the doc, I expect that DHCP clients in general purpose computers will always use the four message exchange. Specialized devices - for example, CPEs and phones - will use Rapid Commit in scenarios where the DHCP service is deployed to take advantage of Rapid Commit. >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? Clarification required... >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 dhcwg-admin@ietf.org Wed May 8 19:52: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 TAA26506; Wed, 8 May 2002 19:52:33 -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 TAA05852; Wed, 8 May 2002 19:51: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 TAA05823 for ; Wed, 8 May 2002 19:51:20 -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 TAA26379 for ; Wed, 8 May 2002 19:51:11 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27813; Wed, 8 May 2002 19:50:34 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508191124.030e5278@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 19:19:33 -0400 To: Thomas Narten From: Ralph Droms Subject: Re: [dhcwg] dhcpv6-24: comparing client parameters and server state Cc: dhcwg@ietf.org, rdroms@cisco.com In-Reply-To: <200205081507.g48F7M819234@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 At 11:07 AM 5/8/2002 -0400, Thomas Narten wrote: > > 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... OK - the clarification should, I think, be that the server compares the addresses only and ignores the lease expiration time. >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. The Confirm message is multicast and received by potentially more than one server. I think each server only checks the IAs that it (the server) has a record of. >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 dhcwg-admin@ietf.org Wed May 8 19:53: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 TAA26544; Wed, 8 May 2002 19:53:57 -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 TAA05978; Wed, 8 May 2002 19:51: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 TAA05956 for ; Wed, 8 May 2002 19:51:50 -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 TAA26415 for ; Wed, 8 May 2002 19:51:41 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27844; Wed, 8 May 2002 19:51:16 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508193050.030e5278@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 19:32:06 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] dhcpv6-24: sending Information-request via multicast Cc: rdroms@cisco.com In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3C0@EAMBUNT705> 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 OK, given the lack of clarity and the reality that site-wide multicast is not always available, I think we should follow Bernie's suggestion (3rd para below). - Ralph At 11:19 AM 5/8/2002 -0500, Bernie Volz (EUD) wrote: >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 > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 8 19:54:44 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 TAA26569; Wed, 8 May 2002 19:54:43 -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 TAA05933; Wed, 8 May 2002 19:51:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA05908 for ; Wed, 8 May 2002 19:51:46 -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 TAA26413 for ; Wed, 8 May 2002 19:51:37 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27842; Wed, 8 May 2002 19:51:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508192815.00b6da90@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 19:30:06 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhcpv6-24: use of DNS names in DUIDs Cc: rdroms@cisco.com In-Reply-To: <200205081533.g48FXU519550@rotala.raleigh.ibm.com> References: 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 Comments in line - Ralph At 11:33 AM 5/8/2002 -0400, Thomas Narten wrote: > > 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. Adding the text makes sense... > > 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. Good catch - I think the use of ASCII is a legacy in the example; the example should be changed to use RFC1035 representation. >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 dhcwg-admin@ietf.org Wed May 8 19:54:47 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 TAA26592; Wed, 8 May 2002 19:54:47 -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 TAA05886; Wed, 8 May 2002 19:51: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 TAA05865 for ; Wed, 8 May 2002 19:51:38 -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 TAA26410 for ; Wed, 8 May 2002 19:51:29 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-536.cisco.com [10.21.98.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA27823; Wed, 8 May 2002 19:50:51 -0400 (EDT) Message-Id: <4.3.2.7.2.20020508191912.031513d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 May 2002 19:26:34 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Cc: rdroms@cisco.com In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3BF@EAMBUNT705> 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 We have three different messages that are used in three different situations: Confirm - client has detected it may have moved, sends Confirm to any available server to determine if configuration is still valid Renew - client unicasts to assigning server to extend lease on IA Rebind - client sends to any available server to extend lease on IA Thomas - rereading your original question, I'm not sure if you're suggesting that a client not try to detect if it has moved to a new link, or if it use a Renew instead of a Rebind when it detects it may have moved to a new link. I think from: >if a client detects that it has >moved, then just have it redo the normal DHC exchanges. you mean keep movement detection but use different DHCP messages. Exactly what did you have in mind for "normal DHCP exchange"? The idea behind Confirm is (as is the case in DHCPv4) if the client has not moved (e.g., the client has been power cycled), the client uses a two message exchange with any available server rather than a four message exchange. Perhaps Confirm overlaps with Rapid Commit? - Ralph At 11:15 AM 5/8/2002 -0500, Bernie Volz (EUD) wrote: >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 > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 8 21:45: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 VAA29201; Wed, 8 May 2002 21:45: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 VAA12021; Wed, 8 May 2002 21:45: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 VAA11965 for ; Wed, 8 May 2002 21:45:08 -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 VAA29185 for ; Wed, 8 May 2002 21:44:58 -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 g491iWi17822 for ; Wed, 8 May 2002 20:44:32 -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 g491iVr18506 for ; Wed, 8 May 2002 20:44:31 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed May 08 20:44:31 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 May 2002 20:44:31 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3D0@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Date: Wed, 8 May 2002 20:44:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F6FB.0FB26BE0" 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_01C1F6FB.0FB26BE0 Content-Type: text/plain; charset="iso-8859-1" Yes, that is my assumption - that the host has to wait for an RA. The Stateless Autoconfiguration RFC doesn't state this explicitly and also doesn't cover the case of a moving client (at least that I could find). It seems to me that if a host follows that specification, once the ManagedFlag is set to TRUE the only way it can ever be set to FALSE is via a reboot of the host. There always is the possibility that a host's policy could force the ManagedFlag to be TRUE always? Though why you'd want to do this is not clear to me. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, May 08, 2002 7:38 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Thomas comment (below) raised a question in my mind. Is the state of the managedFlag always go to FALSE or is it maintained across systems restarts? That is, does a host always come up in stateless mode and then switch to stateful upon receipt of the first RA. If the client does always come up in stateless mode, does the following text cause the first Solicit to be delayed until at least the receipt of the first RA? 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). At 11:00 AM 5/8/2002 -0400, Thomas Narten wrote: >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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F6FB.0FB26BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: randomization delay before invoking = DHC

Yes, that is my assumption - that the host has to = wait for an RA. The Stateless Autoconfiguration RFC doesn't state this = explicitly and also doesn't cover the case of a moving client (at least = that I could find). It seems to me that if a host follows that = specification, once the ManagedFlag is set to TRUE the only way it can = ever be set to FALSE is via a reboot of the host.

There always is the possibility that a host's policy = could force the ManagedFlag to be TRUE always? Though why you'd want to = do this is not clear to me.

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, May 08, 2002 7:38 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: randomization delay = before invoking DHC


Thomas comment (below) raised a question in my = mind.  Is the state of the
managedFlag always go to FALSE or is it maintained = across systems
restarts?  That is, does a host always come up = in stateless mode and then
switch to stateful upon receipt of the first = RA.  If the client does always
come up in stateless mode, does the following text = cause the first Solicit
to be delayed until at least the receipt of the = first RA?

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).


At 11:00 AM 5/8/2002 -0400, Thomas Narten = wrote:

>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


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

------_=_NextPart_001_01C1F6FB.0FB26BE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 01:46: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 BAA03766; Thu, 9 May 2002 01:46:47 -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 BAA01869; Thu, 9 May 2002 01:46:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA01843 for ; Thu, 9 May 2002 01:46:08 -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 BAA03749 for ; Thu, 9 May 2002 01:45:59 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn3-221.cisco.com [10.21.64.221]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA13342; Thu, 9 May 2002 01:45:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20020509013910.03139e20@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 May 2002 01:42:06 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Cc: rdroms@cisco.com In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3D0@EAMBUNT705> 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 This text from section 5.2 of RFC2462 would seem to preclude a host policy that allows ManagedFlag to be always true: ManagedFlag Copied from the M flag field (i.e., the "managed address configuration" flag) of the most recently received Router Advertisement message. The flag indicates whether or not addresses are to be configured using the stateful autoconfiguration mechanism. It starts out in a FALSE state. - Ralph At 08:44 PM 5/8/2002 -0500, Bernie Volz (EUD) wrote: >There always is the possibility that a host's policy could force the >ManagedFlag to be TRUE always? Though why you'd want to do this is not >clear to me. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 01:54:35 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 BAA03890; Thu, 9 May 2002 01:54: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 BAA02213; Thu, 9 May 2002 01:53:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA02187 for ; Thu, 9 May 2002 01:53:56 -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 BAA03881 for ; Thu, 9 May 2002 01:53:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn3-221.cisco.com [10.21.64.221]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id BAA13835; Thu, 9 May 2002 01:53:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20020509014238.03136ee8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 May 2002 01:52:44 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Cc: rdroms@cisco.com In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3D0@EAMBUNT705> 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 So, in this text from section 5.2 of RFC2462, we should assume "starts out" means "every time the system restarts/reboots"; a host does not retain the previous state of ManagedFlag across a restart: ManagedFlag Copied from the M flag field (i.e., the "managed address configuration" flag) of the most recently received Router Advertisement message. The flag indicates whether or not addresses are to be configured using the stateful autoconfiguration mechanism. It starts out in a FALSE state. Given that assumption, this text from section 5.5.3 of RFC2462 implies that a client waits for the first RA to change ManagedFlag from FALSE to TRUE: 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. Going back to Thomas' initial comment about the following sentence: 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) I believe that the problem can be fixed be rewriting the sentence in question as: 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 IPv6 Neighbor Discvoery causes the client to invoke the stateful address autoconfiguration protocol (see section 5.5.3 of RFC2462). That is, I think RFC2462 defines the times at which the client begins the DHCP process by sending a Solicit. The DHCP spec can then define the randomization to be applied to that starting time. - Ralph At 08:44 PM 5/8/2002 -0500, Bernie Volz (EUD) wrote: >Yes, that is my assumption - that the host has to wait for an RA. The >Stateless Autoconfiguration RFC doesn't state this explicitly and also >doesn't cover the case of a moving client (at least that I could find). It >seems to me that if a host follows that specification, once the >ManagedFlag is set to TRUE the only way it can ever be set to FALSE is via >a reboot of the host. > >There always is the possibility that a host's policy could force the >ManagedFlag to be TRUE always? Though why you'd want to do this is not >clear to me. > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Wednesday, May 08, 2002 7:38 PM >To: dhcwg@ietf.org >Subject: Re: [dhcwg] dhcpv6-24: randomization delay before invoking DHC > >Thomas comment (below) raised a question in my mind. Is the state of the >managedFlag always go to FALSE or is it maintained across systems >restarts? That is, does a host always come up in stateless mode and then >switch to stateful upon receipt of the first RA. If the client does always >come up in stateless mode, does the following text cause the first Solicit >to be delayed until at least the receipt of the first RA? > >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). > >At 11:00 AM 5/8/2002 -0400, Thomas Narten wrote: > > >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/mailm > an/listinfo/dhcwg > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 08:06:23 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 IAA16758; Thu, 9 May 2002 08:06: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 IAA20816; Thu, 9 May 2002 08:05: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 IAA20791 for ; Thu, 9 May 2002 08:05:45 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16747 for ; Thu, 9 May 2002 08:05:36 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49C4Gb05287; Thu, 9 May 2002 08:04:16 -0400 Message-Id: <200205091204.g49C4Gb05287@cichlid.adsl.duke.edu> To: Ole Troan cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of anycast In-Reply-To: Message from Ole Troan of "Wed, 08 May 2002 16:46:17 BST." <7t5d6w6wsl2.fsf@mrwint.cisco.com> Date: Thu, 09 May 2002 08:04:16 -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 Ole Troan writes: > >> 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, See RFC 2491 and 2492. Multicast is supported. At least in the case of SVC/PVC. Not clear that anyone uses anything else (i.e., pure NBMA cloud). > Frame Relay RFC2491) Ditto. > ISDN/PSTN Always modeled as a p-2-p link, so mcast is trivially defined. > MPLS MPLS is a funny one. I don't think it is typically viewed as an NBMA cloud. Also, MPLS is used within the core, by routers, and NOT at the edges, so I'd think DHC is not really applicable in general here. > 6to4 Not clear that this is applicable. The router defining 6to4 is an IPv4 box on the interface and uses DHCPv4. It does provide IPv6 support, but this is explicitely in an environment where IPv6 is not supported by the upstream. So DHCPv6 doesn't seem applicable; it it was, why would one even be using 6to4? > ISATAP. Not clear this is applicable. > 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. This is not at all clear to me. 99% of the applicability of DHCv6 will be traditional media, i.e., Ethernets. Another thought. The IPv6 over foo documents provide specifics for how to run IPv6 over that media. In some cases, those documents can override defaults for running IPv6 over a media in general. For example, one can change the number of times one retransmits in DAD. The default is 1, but a specific document can make that 0 or 2, etc. Perhaps one could take the approach that DHC uses link-local multicast by default, unless the specific link-layer over FOO document says use anycast. This is cleaner than saying "use anycast over NBMA" because its clearly specified on a case-by-case basis. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 08:09:47 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 IAA16814; Thu, 9 May 2002 08:09:47 -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 IAA20933; Thu, 9 May 2002 08:09:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA20911 for ; Thu, 9 May 2002 08:09:29 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16811 for ; Thu, 9 May 2002 08:09:20 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49C89o05305; Thu, 9 May 2002 08:08:09 -0400 Message-Id: <200205091208.g49C89o05305@cichlid.adsl.duke.edu> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: randomization delay before invoking DHC In-Reply-To: Message from Ralph Droms of "Wed, 08 May 2002 19:38:17 EDT." <4.3.2.7.2.20020508193307.03149740@funnel.cisco.com> Date: Thu, 09 May 2002 08:08:08 -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 Ralph Droms writes: > Thomas comment (below) raised a question in my mind. Is the state > of the managedFlag always go to FALSE or is it maintained across > systems restarts? That is, does a host always come up in stateless > mode and then switch to stateful upon receipt of the first RA. If > the client does always come up in stateless mode, does the following > text cause the first Solicit to be delayed until at least the > receipt of the first RA? My take. When a node reboots, the first thing it *always* does is solicit an RA. When it gets the response RA, it has new information that overrides the old information. So the old information isn't relevant. That information either says invoke DHC or don't. If it *doesn't* get an RA, that implies there are no routers. But the ND (or addrconf?) spec already says that if there are no routers, then you invoke stateful. So I think no special words are needed, reasonable behavior is already defined elsewhere. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 08:30:28 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 IAA17356; Thu, 9 May 2002 08:30: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 IAA21614; Thu, 9 May 2002 08:29:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA21585 for ; Thu, 9 May 2002 08:29:25 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17306 for ; Thu, 9 May 2002 08:29:16 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49CS5L05366; Thu, 9 May 2002 08:28:05 -0400 Message-Id: <200205091228.g49CS5L05366@cichlid.adsl.duke.edu> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: randomization delay before invoking DHC In-Reply-To: Message from Ralph Droms of "Thu, 09 May 2002 01:52:44 EDT." <4.3.2.7.2.20020509014238.03136ee8@funnel.cisco.com> Date: Thu, 09 May 2002 08:28:04 -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 > I believe that the problem can be fixed be rewriting the sentence in > question as: > 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 IPv6 Neighbor Discvoery causes the client to > invoke the stateful address autoconfiguration protocol (see > section 5.5.3 of RFC2462). > That is, I think RFC2462 defines the times at which the client begins the > DHCP process by sending a Solicit. The DHCP spec can then define the > randomization to be applied to that starting time. Works for me. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 08:35: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 IAA17576; Thu, 9 May 2002 08:35: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 IAA22302; Thu, 9 May 2002 08:34:57 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA22278 for ; Thu, 9 May 2002 08:34:55 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17552 for ; Thu, 9 May 2002 08:34:46 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49CXZl05388; Thu, 9 May 2002 08:33:35 -0400 Message-Id: <200205091233.g49CXZl05388@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Rapid Commit In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 08 May 2002 11:03:41 CDT." <66F66129A77AD411B76200508B65AC69B4D3BB@EAMBUNT705> Date: Thu, 09 May 2002 08:33:35 -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 > - A client should be able to send this option always if it supports > it. Why even have a special option requesting it? It would be nice if the client always did the same thing, with the servers (and how they are configured) determining whether the Rapid Commit is enabled and to be used. It seems odd to me that the *client* decides when it wants the Rapid Commit. Isn't the appropriateness of tihs determined by the envirnment to which the client connects? > - 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. Why not a MUST, not SHOULD? If the client requests a Rapid Commit, it should be prepared to implement it fully. > - 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. This indicates to me this should be under server control, not client (as in the client decides whether to request it). Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 08:42:13 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 IAA17867; Thu, 9 May 2002 08:42:13 -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 IAA22585; Thu, 9 May 2002 08: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 IAA22567 for ; Thu, 9 May 2002 08:41:43 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17849 for ; Thu, 9 May 2002 08:41:33 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49Ce2F05411; Thu, 9 May 2002 08:40:02 -0400 Message-Id: <200205091240.g49Ce2F05411@cichlid.adsl.duke.edu> To: Ted Lemon cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Rapid Commit In-Reply-To: Message from Ted Lemon of "Wed, 08 May 2002 11:09:06 CDT." Date: Thu, 09 May 2002 08:40:02 -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 > 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. Hmm. Note that the bandwidth cost is *NOT* determined by the client type (e.g., cell phone), but the kind of links that are employed. It is misleading and potentially inaccurate to say all cell phones will be on bandwidth limited networks. Also, here I assume you mean bandwidth, not latency. In order to complete the analysis, one must also take into account what happens if the Rapid Commit isn't implemented (more messages?) or if multiple Reply's are received (and then followup releases are needed...) > Also, rapid commit introduces less latency to the address > configuration process, which can be very significant in some cases. This isn't clear to me based on the text in the ID. If Rapid Commit isn't supported, there are more messages exchanged. This means more wasted bandwidth. But if the semantics are that servers can respond with either Reply or Advertise, I think the above concerns can be better dealt with. > 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. We may have addresses to burn, but it now also means that a site doesn't really know which addresses are being used. I.e., If there are two servers, up to 1/2 of the assigned addresses may not actually be in use. Will sys admins like this model? I'm not sure. > 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. Make sense to me. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 08:44:32 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 IAA17997; Thu, 9 May 2002 08:44:32 -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 IAA22712; Thu, 9 May 2002 08:43: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 IAA22683 for ; Thu, 9 May 2002 08:43:30 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17950 for ; Thu, 9 May 2002 08:43:19 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49Cg9105424; Thu, 9 May 2002 08:42:09 -0400 Message-Id: <200205091242.g49Cg9105424@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 08 May 2002 11:15:52 CDT." <66F66129A77AD411B76200508B65AC69B4D3BF@EAMBUNT705> Date: Thu, 09 May 2002 08:42:09 -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 > 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. Right. > 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. I think that future work might better handle this. One approach might be to leave the Confirm stuff in for now, and if better or more general ways of detecting movement are defined, drop the config stuff in a revision. On the other hand, once its in the spec, servers will have to implement it forever, so taking it out only effects clients... Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 08:49:58 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 IAA18208; Thu, 9 May 2002 08:49:58 -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 IAA23104; Thu, 9 May 2002 08:47: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 IAA23082 for ; Thu, 9 May 2002 08:47:14 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18082 for ; Thu, 9 May 2002 08:47:05 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49ChUH05436; Thu, 9 May 2002 08:43:30 -0400 Message-Id: <200205091243.g49ChUH05436@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: "'Ted Lemon'" , dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 08 May 2002 16:43:20 CDT." <66F66129A77AD411B76200508B65AC69B4D3CE@EAMBUNT705> Date: Thu, 09 May 2002 08:43: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 > 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). This isn't covered very well in the existing ND specs. But the general topic has received a lot of attention in the Mobile IP space. For obvious reasons, they are very interested in detecting movements quickly. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:02: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 JAA18826; Thu, 9 May 2002 09:02: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 JAA23988; Thu, 9 May 2002 09:00:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA23960 for ; Thu, 9 May 2002 09:00:56 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18713 for ; Thu, 9 May 2002 09:00:46 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49CxZ805478; Thu, 9 May 2002 08:59:35 -0400 Message-Id: <200205091259.g49CxZ805478@cichlid.adsl.duke.edu> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message In-Reply-To: Message from Ralph Droms of "Wed, 08 May 2002 19:26:34 EDT." <4.3.2.7.2.20020508191912.031513d0@funnel.cisco.com> Date: Thu, 09 May 2002 08:59:35 -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 > Confirm - client has detected it may have moved, sends > Confirm to any available server to determine > if configuration is still valid > Renew - client unicasts to assigning server to extend > lease on IA > Rebind - client sends to any available server to extend > lease on IA Including the above in the overview would be very helpful. It's not clearly described there, and the above description really helps me to understand why/how the messages differ. > Thomas - rereading your original question, I'm not sure if you're > suggesting that a client not try to detect if it has moved to a new link, > or if it use a Renew instead of a Rebind when it detects it may have moved > to a new link. I believe a client should definitely try to detect when it has moved. What I was wondering about is whether DHC should be specifying *how* it does movement detection (since this is a general topic), and whether DHC should provide explicit mechanisms (beyond other existing message types) that help the client determine if it has moved. Seems to me the Confirm is (maybe?) just an optimization. Couldn't the client just send a Renew to the assigning server? I gather that one advantage of the Confirm is that it is sent to all servers, so one will respond quickly. If the client sends a Renew to a specific server, but the client has moved, the Renew will presumably time out, which takes a lot longer. But in terms of the amount of work a server has to do when processing Confirm vs. Renew, the work is pretty much the same, I would think. I assume that this is the motivation for Confirm. Question: when one sends a confirm, does only the server that has that information respond, or are all servers expected to respond? The text says: > In any situation when a client may have moved to a new link, the > client MUST initiate a Confirm/Reply message exchange. The client > includes any IAs, along with the addresses associated with those IAs, > in its Confirm message. Any responding servers will indicate the > acceptability of the addresses with the status in the Reply message > it returns to the client. But how do other servers know that they are to respond positively? I would expect that only server that originally allocated the addresses to be able to respond positively that the config is valid. Maybe the text isn't explicit enough about what a server does when it gets a Confirm. Does it just check that the addresses are on the link as indicated by the link-address field in the relayed packet? This would be sufficient to verify that client hasn't moved. If it needs to verify that the actual addresses have been assigned it's not clear that any server can do that. This makes me wonder if this is really very much better than just using Renew (if only one server can respond anyway). The text says (under server processing): > If the server finds that the information for the client does not > match what is in the binding for that client or the configuration > information is not valid, the server sends a Reply message containing > a Status Code option with the value ConfNoMatch. I think more text would be good to make it clear that a server can also respond positively even if it can't verify the actual binding. Likewise, a positive response in that case DOSE NOT actually confirm the binding, just that the node hasn't moved. Make sense? > I think from: > >if a client detects that it has > >moved, then just have it redo the normal DHC exchanges. > you mean keep movement detection but use different DHCP messages. Exactly > what did you have in mind for "normal DHCP exchange"? Renew, Rebind and or just restarting with solicit. > The idea behind > Confirm is (as is the case in DHCPv4) if the client has not moved (e.g., > the client has been power cycled), the client uses a two message exchange > with any available server rather than a four message exchange. This assumes that *any* server is in a position to respond definitively. This is not immediately clear to me per above. > Perhaps Confirm overlaps with Rapid Commit? Hmm. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:11: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 JAA19338; Thu, 9 May 2002 09:11: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 JAA24566; Thu, 9 May 2002 09:08: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 JAA24497 for ; Thu, 9 May 2002 09:08:22 -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 JAA19122 for ; Thu, 9 May 2002 09:08:13 -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 g49D7qi23418 for ; Thu, 9 May 2002 08:07:52 -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 g49D7p508412 for ; Thu, 9 May 2002 08:07:51 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu May 09 08:07:50 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 08:07:50 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3D6@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , Ole Troan Cc: Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast Date: Thu, 9 May 2002 08:07:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F75A.8537ABA0" 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_01C1F75A.8537ABA0 Content-Type: text/plain; charset="iso-8859-1" Thomas: >Perhaps one could take the approach that DHC uses link-local multicast >by default, unless the specific link-layer over FOO document says use >anycast. This is cleaner than saying "use anycast over NBMA" because >its clearly specified on a case-by-case basis. The only issue with this is that DHCP usually runs as an application and is therefore only able to access that information which the lower layers (via APIs) make available. Determining whether multicast is supported or not is pretty standard from the socket API. However, determining that a particular interface is a specific media type may be difficult. Therefore, there is some value in providing a clear direction here that is also relatively easy to implement. If all interface types provide multicast (either inherently or via some type of emulation), there is little need to ever use the anycast address and so what harm is there in specifying it. What we probably should say is that the client MUST use the multicast address if the interface on which it is sending the message supports multicast. Otherwise, it may use the anycast address. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, May 09, 2002 8:04 AM To: Ole Troan Cc: Ralph Droms; dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of anycast Ole Troan writes: > >> 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, See RFC 2491 and 2492. Multicast is supported. At least in the case of SVC/PVC. Not clear that anyone uses anything else (i.e., pure NBMA cloud). > Frame Relay RFC2491) Ditto. > ISDN/PSTN Always modeled as a p-2-p link, so mcast is trivially defined. > MPLS MPLS is a funny one. I don't think it is typically viewed as an NBMA cloud. Also, MPLS is used within the core, by routers, and NOT at the edges, so I'd think DHC is not really applicable in general here. > 6to4 Not clear that this is applicable. The router defining 6to4 is an IPv4 box on the interface and uses DHCPv4. It does provide IPv6 support, but this is explicitely in an environment where IPv6 is not supported by the upstream. So DHCPv6 doesn't seem applicable; it it was, why would one even be using 6to4? > ISATAP. Not clear this is applicable. > 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. This is not at all clear to me. 99% of the applicability of DHCv6 will be traditional media, i.e., Ethernets. Another thought. The IPv6 over foo documents provide specifics for how to run IPv6 over that media. In some cases, those documents can override defaults for running IPv6 over a media in general. For example, one can change the number of times one retransmits in DAD. The default is 1, but a specific document can make that 0 or 2, etc. Perhaps one could take the approach that DHC uses link-local multicast by default, unless the specific link-layer over FOO document says use anycast. This is cleaner than saying "use anycast over NBMA" because its clearly specified on a case-by-case basis. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F75A.8537ABA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: use of anycast

Thomas:

>Perhaps one could take the approach that DHC uses = link-local multicast
>by default, unless the specific link-layer over = FOO document says use
>anycast. This is cleaner than saying "use = anycast over NBMA" because
>its clearly specified on a case-by-case = basis.

The only issue with this is that DHCP usually runs as = an application and is therefore only able to access that information = which the lower layers (via APIs) make available.

Determining whether multicast is supported or not is = pretty standard from the socket API. However, determining that a = particular interface is a specific media type may be = difficult.

Therefore, there is some value in providing a clear = direction here that is also relatively easy to implement.

If all interface types provide multicast (either = inherently or via some type of emulation), there is little need to ever = use the anycast address and so what harm is there in specifying = it.

What we probably should say is that the client MUST = use the multicast address if the interface on which it is sending the = message supports multicast. Otherwise, it may use the anycast = address.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Thursday, May 09, 2002 8:04 AM
To: Ole Troan
Cc: Ralph Droms; dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: use of anycast =


Ole Troan <ot@cisco.com> writes:

> >> 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,

See RFC 2491 and 2492. Multicast is supported. At = least in the case of
SVC/PVC. Not clear that anyone uses anything else = (i.e., pure NBMA
cloud).

> Frame Relay RFC2491)

Ditto.

> ISDN/PSTN

Always modeled as a p-2-p link, so mcast is trivially = defined.

> MPLS

MPLS is a funny one. I don't think it is typically = viewed as an NBMA
cloud. Also, MPLS is used within the core, by = routers, and NOT at the
edges, so I'd think DHC is not really applicable in = general here.

> 6to4

Not clear that this is applicable. The router = defining 6to4 is an IPv4
box on the interface and uses DHCPv4. It does = provide IPv6 support,
but this is explicitely in an environment where IPv6 = is not supported
by the upstream. So DHCPv6 doesn't seem applicable; = it it was, why
would one even be using 6to4?

> ISATAP.

Not clear this is applicable.

> 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.

This is not at all clear to me.

99% of the applicability of DHCv6 will be traditional = media, i.e.,
Ethernets.

Another thought. The IPv6 over foo documents provide = specifics for how
to run IPv6 over that media. In some cases, those = documents can
override defaults for running IPv6 over a media in = general. For
example, one can change the number of times one = retransmits in
DAD. The default is 1, but a specific document can = make that 0 or 2,
etc.

Perhaps one could take the approach that DHC uses = link-local multicast
by default, unless the specific link-layer over FOO = document says use
anycast. This is cleaner than saying "use = anycast over NBMA" because
its clearly specified on a case-by-case = basis.

Thomas

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

------_=_NextPart_001_01C1F75A.8537ABA0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:25:23 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 JAA20074; Thu, 9 May 2002 09:25: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 JAA25275; Thu, 9 May 2002 09:24: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 JAA25244 for ; Thu, 9 May 2002 09:24:22 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19993 for ; Thu, 9 May 2002 09:24:12 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49DMwp05608; Thu, 9 May 2002 09:22:58 -0400 Message-Id: <200205091322.g49DMwp05608@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: Ole Troan , Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of anycast In-Reply-To: Message from "Bernie Volz (EUD)" of "Thu, 09 May 2002 08:07:49 CDT." <66F66129A77AD411B76200508B65AC69B4D3D6@EAMBUNT705> Date: Thu, 09 May 2002 09:22:58 -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 > The only issue with this is that DHCP usually runs as an application > and is therefore only able to access that information which the > lower layers (via APIs) make available. Understood. > Determining whether multicast is supported or not is pretty standard > from the socket API. However, determining that a particular > interface is a specific media type may be difficult. OK. > Therefore, there is some value in providing a clear direction here > that is also relatively easy to implement. Agreed. > If all interface types provide multicast (either inherently or via > some type of emulation), there is little need to ever use the > anycast address and so what harm is there in specifying it. The harm is that a) we may define something that isn't useful (which may cause problems when deployed because some implementations choose use the feature even if it doesn't work as intended). b) clients may choose to send to anycast addresses, but if servers aren't configured to deal with them, we don't get interoperability, so specifying that clients MAY do something really implies (to me) that server SHOULD (or maybe even MUST) be prepared to handle such packets from clients. If the client can't expect a server to handle something, there is little point in clients implementing the feature either. My general opinion: if its not clear something is useful, and it's not obvious what the details should be, including the feature distracts from the overall goal of getting the spec done. The more one can remove, the fewer details that have to be gotten right. > What we probably should say is that the client MUST use the > multicast address if the interface on which it is sending the > message supports multicast. Otherwise, it may use the anycast > address. This is OK with me. Just so long as it's clear that the anycast usage is only link-local and is only for reaching servers (and relay agents) on the same link. This seems like a straightforward thing to get right. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:25: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 JAA20106; Thu, 9 May 2002 09:25: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 JAA25320; Thu, 9 May 2002 09:24: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 JAA25289 for ; Thu, 9 May 2002 09:24:28 -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 JAA20001 for ; Thu, 9 May 2002 09:24:19 -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 g49DORl09110 for ; Thu, 9 May 2002 08:24:27 -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 g49DOR517901 for ; Thu, 9 May 2002 08:24:27 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu May 09 08:24:26 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 08:24:26 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3D7@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Thu, 9 May 2002 08:24:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F75C.D6E135A0" 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_01C1F75C.D6E135A0 Content-Type: text/plain; charset="iso-8859-1" Thomas: My desire for the Confirm would be as follows: - Client can send a Confirm to help in movement detection. It shouldn't be required for the client to do this since it may have other means of doing this. - A server that does implement Confirm handles the message in three ways: 1. If it has the binding for the client and the addresses are valid, it can send a Reply with the success indication. This would be the case if the client hasn't really moved. 2. If it doesn't have a binding but in comparing the addresses provided in the Confirm, the server can determine that the prefixes for the addresses are NOT valid for the link, the server can Reply to the client that the addresses are bad. 3. The server discards the Confirm since it can not verify that the addresses are truely valid for the client. (We could allow another Reply from the server that would indicate to the client that the prefixes appear to be valid, but it can't confirm the actual addresses. However, this isn't really necessary since no response to the Confirm essentially means that and it could give false information at times; that is why it would be best not to have servers do this.) - While I think servers SHOULD implement Confirm, they don't have to. If they don't, they won't enhance movement detection but since there are other mechanisms that can help with this, it is not required. - Confirm processing is much different than a Renew/Rebind. There is much less work involved on the server - it is only verifying the information. A Confirm can NOT be used to extend address lifetimes/leases. IMHO, it should only be used to help the client determine whether it moved. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, May 09, 2002 9:00 AM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message > Confirm - client has detected it may have moved, sends > Confirm to any available server to determine > if configuration is still valid > Renew - client unicasts to assigning server to extend > lease on IA > Rebind - client sends to any available server to extend > lease on IA Including the above in the overview would be very helpful. It's not clearly described there, and the above description really helps me to understand why/how the messages differ. > Thomas - rereading your original question, I'm not sure if you're > suggesting that a client not try to detect if it has moved to a new link, > or if it use a Renew instead of a Rebind when it detects it may have moved > to a new link. I believe a client should definitely try to detect when it has moved. What I was wondering about is whether DHC should be specifying *how* it does movement detection (since this is a general topic), and whether DHC should provide explicit mechanisms (beyond other existing message types) that help the client determine if it has moved. Seems to me the Confirm is (maybe?) just an optimization. Couldn't the client just send a Renew to the assigning server? I gather that one advantage of the Confirm is that it is sent to all servers, so one will respond quickly. If the client sends a Renew to a specific server, but the client has moved, the Renew will presumably time out, which takes a lot longer. But in terms of the amount of work a server has to do when processing Confirm vs. Renew, the work is pretty much the same, I would think. I assume that this is the motivation for Confirm. Question: when one sends a confirm, does only the server that has that information respond, or are all servers expected to respond? The text says: > In any situation when a client may have moved to a new link, the > client MUST initiate a Confirm/Reply message exchange. The client > includes any IAs, along with the addresses associated with those IAs, > in its Confirm message. Any responding servers will indicate the > acceptability of the addresses with the status in the Reply message > it returns to the client. But how do other servers know that they are to respond positively? I would expect that only server that originally allocated the addresses to be able to respond positively that the config is valid. Maybe the text isn't explicit enough about what a server does when it gets a Confirm. Does it just check that the addresses are on the link as indicated by the link-address field in the relayed packet? This would be sufficient to verify that client hasn't moved. If it needs to verify that the actual addresses have been assigned it's not clear that any server can do that. This makes me wonder if this is really very much better than just using Renew (if only one server can respond anyway). The text says (under server processing): > If the server finds that the information for the client does not > match what is in the binding for that client or the configuration > information is not valid, the server sends a Reply message containing > a Status Code option with the value ConfNoMatch. I think more text would be good to make it clear that a server can also respond positively even if it can't verify the actual binding. Likewise, a positive response in that case DOSE NOT actually confirm the binding, just that the node hasn't moved. Make sense? > I think from: > >if a client detects that it has > >moved, then just have it redo the normal DHC exchanges. > you mean keep movement detection but use different DHCP messages. Exactly > what did you have in mind for "normal DHCP exchange"? Renew, Rebind and or just restarting with solicit. > The idea behind > Confirm is (as is the case in DHCPv4) if the client has not moved (e.g., > the client has been power cycled), the client uses a two message exchange > with any available server rather than a four message exchange. This assumes that *any* server is in a position to respond definitively. This is not immediately clear to me per above. > Perhaps Confirm overlaps with Rapid Commit? Hmm. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F75C.D6E135A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: movement detection and Confirm message =

Thomas:

My desire for the Confirm would be as follows:

- Client can send a Confirm to help in movement = detection. It shouldn't be required for the client to do this since it = may have other means of doing this.

- A server that does implement Confirm handles the = message in three ways:
1. If it has the binding for the client and the = addresses are valid, it can send a Reply with the success indication. = This would be the case if the client hasn't really moved.

2. If it doesn't have a binding but in comparing the = addresses provided in the Confirm, the server can determine that the = prefixes for the addresses are NOT valid for the link, the server can = Reply to the client that the addresses are bad.

3. The server discards the Confirm since it can not = verify that the addresses are truely valid for the client.

(We could allow another Reply from the server that = would indicate to the client that the prefixes appear to be valid, but = it can't confirm the actual addresses. However, this isn't really = necessary since no response to the Confirm essentially means that and = it could give false information at times; that is why it would be best = not to have servers do this.)

- While I think servers SHOULD implement Confirm, = they don't have to. If they don't, they won't enhance movement = detection but since there are other mechanisms that can help with this, = it is not required.

- Confirm processing is much different than a = Renew/Rebind. There is much less work involved on the server - it is = only verifying the information. A Confirm can NOT be used to extend = address lifetimes/leases. IMHO, it should only be used to help the = client determine whether it moved.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Thursday, May 09, 2002 9:00 AM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: movement detection = and Confirm message



> Confirm - client has detected it may have moved, = sends
>          = ;  Confirm to any available server to determine
>          = ;  if configuration is still valid
> Renew   - client unicasts to = assigning server to extend
>          = ;  lease on IA
> Rebind  - client sends to any available = server to extend
>          = ;  lease on IA

Including the above in the overview would be very = helpful. It's not
clearly described there, and the above description = really helps me to
understand why/how the messages differ.

> Thomas - rereading your original question, I'm = not sure if you're
> suggesting that a client not try to detect if = it has moved to a new link,
> or if it use a Renew instead of a Rebind when = it detects it may have moved
> to a new link.

I believe a client should definitely try to detect = when it has
moved. What I was wondering about is whether DHC = should be specifying
*how* it does movement detection (since this is a = general topic), and
whether DHC should provide explicit mechanisms = (beyond other existing
message types) that help the client determine if it = has moved.

Seems to me the Confirm is (maybe?) just an = optimization. Couldn't the
client just send a Renew to the assigning = server?

I gather that one advantage of the Confirm is that it = is sent to all
servers, so one will respond quickly. If the client = sends a Renew to a
specific server, but the client has moved, the Renew = will presumably
time out, which takes a lot longer. But in terms of = the amount of work
a server has to do when processing Confirm vs. = Renew, the work is
pretty much the same, I would think.  I assume = that this is the
motivation for Confirm.

Question: when one sends a confirm, does only the = server that has that
information respond, or are all servers expected to = respond?

The text says:

>    In any situation when a client = may have moved to a new link, the
>    client MUST initiate a = Confirm/Reply message exchange.  The client
>    includes any IAs, along with = the addresses associated with those IAs,
>    in its Confirm message.  = Any responding servers will indicate the
>    acceptability of the = addresses with the status in the Reply message
>    it returns to the = client.


But how do other servers know that they are to = respond positively? I
would expect that only server that originally = allocated the addresses
to be able to respond positively that the config is = valid. Maybe the
text isn't explicit enough about what a server does = when it gets a
Confirm. Does it just check that the  addresses = are on the link as
indicated by the link-address field in the relayed = packet? This would
be sufficient to verify that client hasn't moved. If = it needs to
verify that the actual addresses have been = assigned  it's not clear
that any server can do that. This makes me wonder if = this is really
very much better than just  using Renew (if = only one server can
respond anyway).

The text says (under server processing):

>    If the server finds that the = information for the client does not
>    match what is in the binding = for that client or the configuration
>    information is not valid, the = server sends a Reply message containing
>    a Status Code option with the = value ConfNoMatch.

I think more text would be good to make it clear that = a server can also
respond positively even if it can't verify the = actual
binding. Likewise, a positive response in that case = DOSE NOT actually
confirm the binding, just that the node hasn't = moved.

Make sense?

> I think from:

> >if a client detects that it has
> >moved, then just have it redo the normal = DHC exchanges.

> you mean keep movement detection but use = different DHCP messages.  Exactly
> what did you have in mind for "normal DHCP = exchange"?

Renew, Rebind and or just restarting with = solicit.

> The idea behind
> Confirm is (as is the case in DHCPv4) if the = client has not moved (e.g.,
> the client has been power cycled), the client = uses a two message exchange
> with any available server rather than a four = message exchange.

This assumes that *any* server is in a position to = respond
definitively. This is not immediately clear to me = per above.

> Perhaps Confirm overlaps with Rapid = Commit?

Hmm.

Thomas

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

------_=_NextPart_001_01C1F75C.D6E135A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:27:44 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 JAA20287; Thu, 9 May 2002 09:27: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 JAA25486; Thu, 9 May 2002 09:26: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 JAA25461 for ; Thu, 9 May 2002 09:26:42 -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 JAA20219 for ; Thu, 9 May 2002 09:26:28 -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 g49DQal10323 for ; Thu, 9 May 2002 08:26:36 -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 g49DQa113979 for ; Thu, 9 May 2002 08:26:36 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu May 09 08:26:35 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 08:26:35 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3D8@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , "Bernie Volz (EUD)" Cc: Ole Troan , Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast Date: Thu, 9 May 2002 08:26:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F75D.22BA04C0" 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_01C1F75D.22BA04C0 Content-Type: text/plain; charset="iso-8859-1" >> What we probably should say is that the client MUST use the >> multicast address if the interface on which it is sending the >> message supports multicast. Otherwise, it may use the anycast >> address. > >This is OK with me. Just so long as it's clear that the anycast usage >is only link-local and is only for reaching servers (and relay agents) >on the same link. This seems like a straightforward thing to get >right. Sounds fine to me. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, May 09, 2002 9:23 AM To: Bernie Volz (EUD) Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of anycast > The only issue with this is that DHCP usually runs as an application > and is therefore only able to access that information which the > lower layers (via APIs) make available. Understood. > Determining whether multicast is supported or not is pretty standard > from the socket API. However, determining that a particular > interface is a specific media type may be difficult. OK. > Therefore, there is some value in providing a clear direction here > that is also relatively easy to implement. Agreed. > If all interface types provide multicast (either inherently or via > some type of emulation), there is little need to ever use the > anycast address and so what harm is there in specifying it. The harm is that a) we may define something that isn't useful (which may cause problems when deployed because some implementations choose use the feature even if it doesn't work as intended). b) clients may choose to send to anycast addresses, but if servers aren't configured to deal with them, we don't get interoperability, so specifying that clients MAY do something really implies (to me) that server SHOULD (or maybe even MUST) be prepared to handle such packets from clients. If the client can't expect a server to handle something, there is little point in clients implementing the feature either. My general opinion: if its not clear something is useful, and it's not obvious what the details should be, including the feature distracts from the overall goal of getting the spec done. The more one can remove, the fewer details that have to be gotten right. > What we probably should say is that the client MUST use the > multicast address if the interface on which it is sending the > message supports multicast. Otherwise, it may use the anycast > address. This is OK with me. Just so long as it's clear that the anycast usage is only link-local and is only for reaching servers (and relay agents) on the same link. This seems like a straightforward thing to get right. Thomas ------_=_NextPart_001_01C1F75D.22BA04C0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] dhcpv6-24: use of anycast

>> What we probably should say is that the client MUST use the
>> multicast address if the interface on which it is sending the
>> message supports multicast. Otherwise, it may use the anycast
>> address.
>
>This is OK with me. Just so long as it's clear that the anycast usage
>is only link-local and is only for reaching servers (and relay agents)
>on the same link. This seems like a straightforward thing to get
>right.

Sounds fine to me.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Thursday, May 09, 2002 9:23 AM
To: Bernie Volz (EUD)
Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: use of anycast


> The only issue with this is that DHCP usually runs as an application
> and is therefore only able to access that information which the
> lower layers (via APIs) make available.

Understood.

> Determining whether multicast is supported or not is pretty standard
> from the socket API. However, determining that a particular
> interface is a specific media type may be difficult.

OK.

> Therefore, there is some value in providing a clear direction here
>  that is also relatively easy to implement.

Agreed.

> If all interface types provide multicast (either inherently or via
> some type of emulation), there is little need to ever use the
> anycast address and so what harm is there in specifying it.

The harm is that a) we may define something that isn't useful (which
may cause problems when deployed because some implementations choose
use the feature even if it doesn't work as intended). b) clients may
choose to send to anycast addresses, but if servers aren't configured
to deal with them, we don't get interoperability, so specifying that
clients MAY do something really implies (to me) that server SHOULD (or
maybe even MUST) be prepared to handle such packets from clients. If
the client  can't expect a server to handle something, there is little
point in clients implementing the feature either.

My general opinion: if its not clear something is useful, and it's not
obvious what the details should be, including the feature distracts
from the overall goal of getting the spec done. The more one can
remove, the fewer details that have to be gotten right.

> What we probably should say is that the client MUST use the
> multicast address if the interface on which it is sending the
> message supports multicast. Otherwise, it may use the anycast
> address.

This is OK with me. Just so long as it's clear that the anycast usage
is only link-local and is only for reaching servers (and relay agents)
on the same link. This seems like a straightforward thing to get
right.

Thomas

------_=_NextPart_001_01C1F75D.22BA04C0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:29:23 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 JAA20391; Thu, 9 May 2002 09:29: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 JAA25646; Thu, 9 May 2002 09:29:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA25629 for ; Thu, 9 May 2002 09:29:05 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20377 for ; Thu, 9 May 2002 09:28:55 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49DRkC05701; Thu, 9 May 2002 09:27:46 -0400 Message-Id: <200205091327.g49DRkC05701@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Interface-ID option In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 08 May 2002 13:03:09 CDT." <66F66129A77AD411B76200508B65AC69B4D3C3@EAMBUNT705> Date: Thu, 09 May 2002 09:27:45 -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 > > 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 clarifies the confusion I had. > >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? Fine with me. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:34:44 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 JAA20719; Thu, 9 May 2002 09:34: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 JAA26305; Thu, 9 May 2002 09:33: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 JAA26236 for ; Thu, 9 May 2002 09:33:05 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20585 for ; Thu, 9 May 2002 09:32:55 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49DVjX05718; Thu, 9 May 2002 09:31:45 -0400 Message-Id: <200205091331.g49DVjX05718@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 08 May 2002 13:19:34 CDT." <66F66129A77AD411B76200508B65AC69B4D3C4@EAMBUNT705> Date: Thu, 09 May 2002 09:31:45 -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 > 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? I think we could do it either way. I think it is fine for the client to decide (if it wants to) whether (ever) to renew a temporary address. > 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. That is what I understand. > 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. OK. This makes sense. This would be the same for temp and non-temp addresses. Right? Is the same text present in the non-temp case (I don't recall right off)? > 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"? No, I think "valid" is right. If the address is valid, it is still assigned the client, and it would be incorrect for the server to return a different address (in general). Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:34:58 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 JAA20744; Thu, 9 May 2002 09:34:57 -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 JAA26440; Thu, 9 May 2002 09:34:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26415 for ; Thu, 9 May 2002 09:34:45 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20707 for ; Thu, 9 May 2002 09:34:36 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49DXQs05732; Thu, 9 May 2002 09:33:26 -0400 Message-Id: <200205091333.g49DXQs05732@cichlid.adsl.duke.edu> To: Ted Lemon cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option In-Reply-To: Message from Ted Lemon of "Wed, 08 May 2002 11:12:45 CDT." <6E94CA24-629E-11D6-A5AB-00039367340A@nominum.com> Date: Thu, 09 May 2002 09:33:26 -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 Ted Lemon writes: > > 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? Would there be any value in including both? The problem with just including the time is that servers need to guess whether a client has been waiting "too long". Or, is it the case that when the client sends out its initial Solicit, the value MUST be zero? If so, it might be good to specify this. If this were the case, I agree that including the time is probably sufficient. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:44: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 JAA21193; Thu, 9 May 2002 09:44:19 -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 JAA26873; Thu, 9 May 2002 09:43: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 JAA26853 for ; Thu, 9 May 2002 09:43:37 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21166 for ; Thu, 9 May 2002 09:43:27 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g49DgF205830; Thu, 9 May 2002 09:42:15 -0400 Message-Id: <200205091342.g49DgF205830@cichlid.adsl.duke.edu> To: "Bernie Volz (EUD)" cc: Ralph Droms , dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message In-Reply-To: Message from "Bernie Volz (EUD)" of "Thu, 09 May 2002 08:24:25 CDT." <66F66129A77AD411B76200508B65AC69B4D3D7@EAMBUNT705> Date: Thu, 09 May 2002 09:42:14 -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 > - Client can send a Confirm to help in movement detection. It > shouldn't be required for the client to do this since it may have > other means of doing this. OK > - A server that does implement Confirm handles the message in three ways: > 1. If it has the binding for the client and the addresses are valid, >it can send a Reply with the success indication. This would be the >case if the client hasn't really moved. OK > 2. If it doesn't have a binding but in comparing the addresses >provided in the Confirm, the server can determine that the prefixes >for the addresses are NOT valid for the link, the server can Reply to >the client that the addresses are bad. I.e., with a NotOnLink. > 3. The server discards the Confirm since it can not verify that the >addresses are truely valid for the client. Hmm. If a client has moved to a completely new site, will servers in general respond "NotOnLink" or will they think "I don't know"? And if the latter, and they don't respond, won't the client retransmit and won't it take a while to time out? I would assume its important for Confirm to be quick. > (We could allow another Reply from the server that would indicate to > the client that the prefixes appear to be valid, but it can't > confirm the actual addresses. However, this isn't really necessary > since no response to the Confirm essentially means that and it could > give false information at times; that is why it would be best not to > have servers do this.) I agree its not necessary, so long as the semantics of the response make it clear the client can only assume it hasn't moved and needs to not change the state of its bindings in anyway (i.e., it should not restart the T1/T2 timers, for example) > - While I think servers SHOULD implement Confirm, they don't have >to. If they don't, they won't enhance movement detection but since >there are other mechanisms that can help with this, it is not >required. Hmm. If this message is OPTIONAL to implement, this needs to be made clear in the spec. I assumed it was mandatory. I think it should be mandatory. If it is not, there is little point in clients implementing it. I.e., it doesn't make sense for clients to implement basic features that servers aren't required to implement. This leads to bad interoperability. > - Confirm processing is much different than a Renew/Rebind. There is >much less work involved on the server - it is only verifying the >information. A Confirm can NOT be used to extend address >lifetimes/leases. IMHO, it should only be used to help the client >determine whether it moved. OK. Thanks, Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:45:35 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 JAA21298; Thu, 9 May 2002 09:45:35 -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 JAA26950; Thu, 9 May 2002 09:44:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA26924 for ; Thu, 9 May 2002 09:44:06 -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 JAA21185 for ; Thu, 9 May 2002 09:43:56 -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 g49DhZi11779 for ; Thu, 9 May 2002 08:43:35 -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 g49DhZ528396 for ; Thu, 9 May 2002 08:43:35 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu May 09 08:43:34 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 08:43:34 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3DA@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , Ted Lemon Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option Date: Thu, 9 May 2002 08:43:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F75F.826EFC70" 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_01C1F75F.826EFC70 Content-Type: text/plain; charset="iso-8859-1" >Or, is it the case that when the client sends out its initial >Solicit, the value MUST be zero? If so, it might be good to >specify this. That was my assumption. The time should reflect when a transaction is started. So, to be a bit more clear: - Time is 0 when first Solicit is sent. Time continues to increase as Solicits are retransmitted. The one open question is what to do with the time when the client sends a Request. In the DHCPv4 specification (if I read it correctly), the secs for DHCPv4 Request should not increase with retransmissions as that was to assure that the Relay uses the same logic in what servers it sends the messages to (in case it used the secs to send to a different set of servers). I don't know if this is needed and my feeling is that we should NOT reset the time when the Request transmissions start (the time should reflect the time since the FIRST Solicit). If the server should fail to get a Reply to the Request and restarts the Solicit, time should not be reset. - Time is 0 when first Renew/Rebind is sent. Increases with each retransmission until timeout or Reply. - Time is 0 when first Decline/Release is sent. Increases with each retransmission until timeout or Reply. - Time is 0 when first Information-Request is sent. Increases with each retransmission until timeout or Reply. Note that the elapsed time increasing or changing is likely not that critical during Request/Reply, Renew/Reply, Decline/Reply, Release/Reply as these are interactions with a specific server. It is really only valueable when a request is being sent to many servers. Perhaps we should point this out and say that the Elapsed Time Option is not needed if the Server Identifier Option is included in a client message? - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, May 09, 2002 9:33 AM To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option Ted Lemon writes: > > 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? Would there be any value in including both? The problem with just including the time is that servers need to guess whether a client has been waiting "too long". Or, is it the case that when the client sends out its initial Solicit, the value MUST be zero? If so, it might be good to specify this. If this were the case, I agree that including the time is probably sufficient. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F75F.826EFC70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Elapsed Time option

>Or, is it the case that when the client  = sends out its initial
>Solicit, the value MUST be zero? If so, it might = be good to
>specify this.

That was my assumption. The time should reflect when = a transaction is started. So, to be a bit more clear:

- Time is 0 when first Solicit is sent. Time = continues to increase as Solicits are retransmitted.

The one open question is what to do with the time = when the client sends a Request. In the DHCPv4 specification (if I read = it correctly), the secs for DHCPv4 Request should not increase with = retransmissions as that was to assure that the Relay uses the same = logic in what servers it sends the messages to (in case it used the = secs to send to a different set of servers). I don't know if this is = needed and my feeling is that we should NOT reset the time when the = Request transmissions start (the time should reflect the time since the = FIRST Solicit).

If the server should fail to get a Reply to the = Request and restarts the Solicit, time should not be reset.

- Time is 0 when first Renew/Rebind is sent. = Increases with each retransmission until timeout or Reply.

- Time is 0 when first Decline/Release is sent. = Increases with each retransmission until timeout or Reply.

- Time is 0 when first Information-Request is sent. = Increases with each retransmission until timeout or Reply.

Note that the elapsed time increasing or changing is = likely not that critical during Request/Reply, Renew/Reply, = Decline/Reply, Release/Reply as these are interactions with a specific = server. It is really only valueable when a request is being sent to = many servers. Perhaps we should point this out and say that the Elapsed = Time Option is not needed if the Server Identifier Option is included = in a client message?

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Thursday, May 09, 2002 9:33 AM
To: Ted Lemon
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option =


Ted Lemon <Ted.Lemon@nominum.com> = writes:

> > 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?

Would there be any value in including both?

The problem with just including the time is that = servers need to guess
whether a client has been waiting "too = long". Or, is it the case that
when the client  sends out its initial Solicit, = the value MUST be
zero? If so, it might be good to specify this. If = this were the case,
I agree that including the time is probably = sufficient.

Thomas

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

------_=_NextPart_001_01C1F75F.826EFC70-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 09:53: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 JAA21733; Thu, 9 May 2002 09:53:54 -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 JAA27289; Thu, 9 May 2002 09:52:39 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27264 for ; Thu, 9 May 2002 09:52:38 -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 JAA21615 for ; Thu, 9 May 2002 09:52:28 -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 g49Dqbl25265 for ; Thu, 9 May 2002 08:52:37 -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 g49Dqb123956 for ; Thu, 9 May 2002 08:52:37 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu May 09 08:52:36 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 08:52:36 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3DB@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Temporary addresses Date: Thu, 9 May 2002 08:52:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F760.C62F8A50" 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_01C1F760.C62F8A50 Content-Type: text/plain; charset="iso-8859-1" >> > 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. > >OK. This makes sense. This would be the same for temp and non-temp >addresses. Right? Is the same text present in the non-temp case (I >don't recall right off)? Yes, it really should be the same and I think it is implied in other statements relating to addresses in an IA (that can not be removed until the valid lifetime has expired). We do say (for the IA option): "When the lifetimes of all of the addresses in an IA have expired, the IA can be considered as having expired." The one issue with Temporary Addresses is that a server implementor could assume "hey, they're temporary and assigned once and ..." so why save the binding information (they have to flag the address as in use until the valid lifetime expires, but that doesn't mean they'd have to remember which client was using it and for which binding). So, it was important to indicate that the server must remember this because of retransmissions (and now renewals since that wasn't in -24). >No, I think "valid" is right. Agreed. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, May 09, 2002 9:32 AM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses > 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? I think we could do it either way. I think it is fine for the client to decide (if it wants to) whether (ever) to renew a temporary address. > 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. That is what I understand. > 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. OK. This makes sense. This would be the same for temp and non-temp addresses. Right? Is the same text present in the non-temp case (I don't recall right off)? > 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"? No, I think "valid" is right. If the address is valid, it is still assigned the client, and it would be incorrect for the server to return a different address (in general). Thomas ------_=_NextPart_001_01C1F760.C62F8A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [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.
>
>> 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.
>
>OK. This makes sense. This would be the same for = temp and non-temp
>addresses. Right? Is the same text present in = the non-temp case (I
>don't recall right off)?

Yes, it really should be the same and I think it is = implied in other statements relating to addresses in an IA (that can = not be removed until the valid lifetime has expired).

We do say (for the IA option): "When the = lifetimes of all of the addresses in an IA have expired, the IA can be = considered as having expired."

The one issue with Temporary Addresses is that a = server implementor could assume "hey, they're temporary and = assigned once and ..." so why save the binding information (they = have to flag the address as in use until the valid lifetime expires, = but that doesn't mean they'd have to remember which client was using it = and for which binding). So, it was important to indicate that the = server must remember this because of retransmissions (and now renewals = since that wasn't in -24).

>No, I think "valid" is right.

Agreed.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Thursday, May 09, 2002 9:32 AM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses =


> 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?

I think we could do it either way. I think it is fine = for the client
to decide (if it wants to) whether (ever) to renew a = temporary address.

> 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.

That is what I understand.

> 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.

OK. This makes sense. This would be the same for temp = and non-temp
addresses. Right? Is the same text present in the = non-temp case (I
don't recall right off)?

> 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"?

No, I think "valid" is right. If the = address is valid, it is still
assigned the client, and it would be incorrect for = the server to
return a different address (in general).

Thomas

------_=_NextPart_001_01C1F760.C62F8A50-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 12:46: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 MAA29094; Thu, 9 May 2002 12:46: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 MAA08308; Thu, 9 May 2002 12:45:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08284 for ; Thu, 9 May 2002 12:45:45 -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 MAA29046 for ; Thu, 9 May 2002 12:45:36 -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 g49GhNS13344; Thu, 9 May 2002 09:43:23 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g49GiO600681; Thu, 9 May 2002 11:44:24 -0500 (CDT) Date: Thu, 9 May 2002 11:44:24 -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: <200205091333.g49DXQs05732@cichlid.adsl.duke.edu> Message-Id: <04D88EC0-636C-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 > The problem with just including the time is that servers need to guess > whether a client has been waiting "too long". Or, is it the case that > when the client sends out its initial Solicit, the value MUST be > zero? If so, it might be good to specify this. If this were the case, > I agree that including the time is probably sufficient. Ah, I see the problem now. Yes, we should make this explicit. As to the practical matter of "how long is too long," we address this in DHCPv4 by letting the server administrator decide. AFAIK, this solution has proven satisfactory - I haven't heard any complaints about it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 12:47:50 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 MAA29162; Thu, 9 May 2002 12:47: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 MAA08371; Thu, 9 May 2002 12:47: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 MAA08351 for ; Thu, 9 May 2002 12:47:22 -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 MAA29133 for ; Thu, 9 May 2002 12:47:13 -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 g49GkIS13356; Thu, 9 May 2002 09:46:18 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g49GlJ600685; Thu, 9 May 2002 11:47:19 -0500 (CDT) Date: Thu, 9 May 2002 11:47:19 -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: "Bernie Volz (EUD)" , Ralph Droms , dhcwg@ietf.org To: Thomas Narten From: Ted Lemon In-Reply-To: <200205091342.g49DgF205830@cichlid.adsl.duke.edu> Message-Id: <6CFD3458-636C-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 > Hmm. If this message is OPTIONAL to implement, this needs to be made > clear in the spec. I assumed it was mandatory. I think it should be > mandatory. If it is not, there is little point in clients implementing > it. I.e., it doesn't make sense for clients to implement basic > features that servers aren't required to implement. This leads to bad > interoperability. This is a case where the market will quickly punish servers that don't implement it that should. We aren't even insisting that address allocation is mandatory, AFAIK, so saying that confirm is mandatory seems inconsistent. That is, it is fine to implement a DHCPv6 server that only responds to information requests and that does not allocate IP addresses. A DHCP server configured to just provide information might not even have enough information to determine whether or not a client is on the link on which its addresses are valid. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 12:56:10 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 MAA29721; Thu, 9 May 2002 12:56:10 -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 MAA09120; Thu, 9 May 2002 12:55:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA09091 for ; Thu, 9 May 2002 12:55:28 -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 MAA29658 for ; Thu, 9 May 2002 12:55:19 -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 g49GsOS13373; Thu, 9 May 2002 09:54:24 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g49GtP600689; Thu, 9 May 2002 11:55:25 -0500 (CDT) Date: Thu, 9 May 2002 11:55:25 -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: "'Thomas Narten'" , dhcwg@ietf.org To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3DA@EAMBUNT705> Message-Id: <8EAED7CA-636D-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 > If the server should fail to get a Reply to the Request and restarts the > Solicit, time should not be reset. > > - Time is 0 when first Renew/Rebind is sent. Increases with each > retransmission until timeout or Reply. > > - Time is 0 when first Decline/Release is sent. Increases with each > retransmission until timeout or Reply. > > - Time is 0 when first Information-Request is sent. Increases with each > retransmission until timeout or Reply. > I think if you let the relay agent make relaying decisions based on the time sent by the client, you're in big trouble. Picture this: client sends solicit A, t=0 relay sends solicit to server A client sends solicit B, t=100 relay sends solicit to server B server A responds to solicit A with advertise A client sends Request A, t=100 relay sends Request A to server B server B drops Request A on the floor repeat until bored The only reliable way to fix this is to have the server send the time it received from the client in the solicit back to the client in the advertise, and for the client to use that time in every subsequent Request, regardless of how long it has to retry. This is complicated to specify, and complicated to implement. Do we really want this? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 13:33: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 NAA01754; Thu, 9 May 2002 13:33:29 -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 NAA11943; Thu, 9 May 2002 13:32: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 NAA11913 for ; Thu, 9 May 2002 13:32:31 -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 NAA01711 for ; Thu, 9 May 2002 13:32: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 g49HVxi13102 for ; Thu, 9 May 2002 12:31:59 -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 g49HVxY10000 for ; Thu, 9 May 2002 12:31:59 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu May 09 12:31:58 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 12:31:58 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3E1@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" Cc: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option Date: Thu, 9 May 2002 12:31:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F77F.66BD3DF0" 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_01C1F77F.66BD3DF0 Content-Type: text/plain; charset="iso-8859-1" Ted: Exactly correct. And in fact from my reading of the DHCPv4 specification, this is required by it. Here's the text from RFC 2131: To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message MUST use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as the original DHCPDISCOVER message. I did forget to mention that we might just need to do that - have the server return the elapsed time option to the client! I don't have any issue in changing things from DHCPv4 ... I was just assuming we MIGHT want to use that model since it has been tried and proven? I also agree that having the relay base the forwarding on the elapsed time is likely bad - but again, that was assumed to happen with DHCPv4!! - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Thursday, May 09, 2002 12:55 PM To: Bernie Volz (EUD) Cc: 'Thomas Narten'; dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option > If the server should fail to get a Reply to the Request and restarts the > Solicit, time should not be reset. > > - Time is 0 when first Renew/Rebind is sent. Increases with each > retransmission until timeout or Reply. > > - Time is 0 when first Decline/Release is sent. Increases with each > retransmission until timeout or Reply. > > - Time is 0 when first Information-Request is sent. Increases with each > retransmission until timeout or Reply. > I think if you let the relay agent make relaying decisions based on the time sent by the client, you're in big trouble. Picture this: client sends solicit A, t=0 relay sends solicit to server A client sends solicit B, t=100 relay sends solicit to server B server A responds to solicit A with advertise A client sends Request A, t=100 relay sends Request A to server B server B drops Request A on the floor repeat until bored The only reliable way to fix this is to have the server send the time it received from the client in the solicit back to the client in the advertise, and for the client to use that time in every subsequent Request, regardless of how long it has to retry. This is complicated to specify, and complicated to implement. Do we really want this? ------_=_NextPart_001_01C1F77F.66BD3DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Elapsed Time option

Ted:

Exactly correct. And in fact from my reading of the = DHCPv4 specification, this is required by it. Here's the text from RFC = 2131:

     To help
     ensure that any BOOTP relay = agents forward the DHCPREQUEST message
     to the same set of DHCP = servers that received the original
     DHCPDISCOVER message, the = DHCPREQUEST message MUST use the same
     value in the DHCP message = header's 'secs' field and be sent to the
     same IP broadcast address = as the original DHCPDISCOVER message.

I did forget to mention that we might just need to do = that - have the server return the elapsed time option to the = client!

I don't have any issue in changing things from DHCPv4 = ... I was just assuming we MIGHT want to use that model since it has = been tried and proven?

I also agree that having the relay base the = forwarding on the elapsed time is likely bad - but again, that was = assumed to happen with DHCPv4!!

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Thursday, May 09, 2002 12:55 PM
To: Bernie Volz (EUD)
Cc: 'Thomas Narten'; dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option =


> If the server should fail to get a Reply to the = Request and restarts the
> Solicit, time should not be reset.
>
> - Time is 0 when first Renew/Rebind is sent. = Increases with each
> retransmission until timeout or Reply.
>
> - Time is 0 when first Decline/Release is sent. = Increases with each
> retransmission until timeout or Reply.
>
> - Time is 0 when first Information-Request is = sent. Increases with each
> retransmission until timeout or Reply.
>

I think if you let the relay agent make relaying = decisions based on the
time sent by the client, you're in big = trouble.   Picture this:

client sends solicit A, t=3D0
relay sends solicit to server A
client sends solicit B, t=3D100
relay sends solicit to server B
server A responds to solicit A with advertise = A
client sends Request A, t=3D100
relay sends Request A to server B
server B drops Request A on the floor

repeat until bored

The only reliable way to fix this is to have the = server send the time it
received from the client in the solicit back to the = client in the advertise,
  and for the client to use that time in every = subsequent Request,
regardless of how long it has to retry.   = This is complicated to specify,
and complicated to implement.   Do we = really want this?

------_=_NextPart_001_01C1F77F.66BD3DF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 13:38:47 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 NAA02008; Thu, 9 May 2002 13:38:47 -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 NAA12227; Thu, 9 May 2002 13:36: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 NAA12198 for ; Thu, 9 May 2002 13:36:13 -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 NAA01868 for ; Thu, 9 May 2002 13:36:04 -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 g49HZgi15193 for ; Thu, 9 May 2002 12:35:42 -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 g49HZf317307 for ; Thu, 9 May 2002 12:35:41 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu May 09 12:35:13 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 12:35:13 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3E2@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" Cc: "'Thomas Narten'" , "'dhcwg@ietf.org'" Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option Date: Thu, 9 May 2002 12:35:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F77F.DAE98990" 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_01C1F77F.DAE98990 Content-Type: text/plain; charset="iso-8859-1" Oh, I should add that in -24 we have: --- 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). A client SHOULD include an Elapsed Time option in messages to indicate how long the client has been trying to complete a DHCP transaction. Servers and Relay Agents use the data value in this ^^^^^^^^^^^^^^^^ option as input to policy controlling how a server responds to a client message. For example, the elapsed time option allows a secondary DHCP server to respond to a request when a primary server hasn't answered in a reasonable time. --- I would say to keep things simple, we explicitly DISALLOW relays from using this field?? - Bernie -----Original Message----- From: Bernie Volz (EUD) Sent: Thursday, May 09, 2002 1:32 PM To: 'Ted Lemon' Cc: 'Thomas Narten'; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option Ted: Exactly correct. And in fact from my reading of the DHCPv4 specification, this is required by it. Here's the text from RFC 2131: To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message MUST use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as the original DHCPDISCOVER message. I did forget to mention that we might just need to do that - have the server return the elapsed time option to the client! I don't have any issue in changing things from DHCPv4 ... I was just assuming we MIGHT want to use that model since it has been tried and proven? I also agree that having the relay base the forwarding on the elapsed time is likely bad - but again, that was assumed to happen with DHCPv4!! - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Thursday, May 09, 2002 12:55 PM To: Bernie Volz (EUD) Cc: 'Thomas Narten'; dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option > If the server should fail to get a Reply to the Request and restarts the > Solicit, time should not be reset. > > - Time is 0 when first Renew/Rebind is sent. Increases with each > retransmission until timeout or Reply. > > - Time is 0 when first Decline/Release is sent. Increases with each > retransmission until timeout or Reply. > > - Time is 0 when first Information-Request is sent. Increases with each > retransmission until timeout or Reply. > I think if you let the relay agent make relaying decisions based on the time sent by the client, you're in big trouble. Picture this: client sends solicit A, t=0 relay sends solicit to server A client sends solicit B, t=100 relay sends solicit to server B server A responds to solicit A with advertise A client sends Request A, t=100 relay sends Request A to server B server B drops Request A on the floor repeat until bored The only reliable way to fix this is to have the server send the time it received from the client in the solicit back to the client in the advertise, and for the client to use that time in every subsequent Request, regardless of how long it has to retry. This is complicated to specify, and complicated to implement. Do we really want this? ------_=_NextPart_001_01C1F77F.DAE98990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Elapsed Time option

Oh, I should add that in -24 we have:

---

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
          &nb= sp;         current DHCP = transaction.  This time is expressed in
          &nb= sp;         hundredths of a = second (10^-2 seconds).

   A client SHOULD include an Elapsed Time = option in messages to
   indicate how long the client has been = trying to complete a DHCP
   transaction.  Servers and Relay = Agents use the data value in this
          &nb= sp;           &nb= sp;  ^^^^^^^^^^^^^^^^
   option as input to policy controlling = how a server responds to a
   client message.  For example, the = elapsed time option allows a
   secondary DHCP server to respond to a = request when a primary server
   hasn't answered in a reasonable = time.


---

I would say to keep things simple, we explicitly = DISALLOW relays from using this field??

- Bernie

-----Original Message-----
From: Bernie Volz (EUD)
Sent: Thursday, May 09, 2002 1:32 PM
To: 'Ted Lemon'
Cc: 'Thomas Narten'; dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option =


Ted:

Exactly correct. And in fact from my reading of the = DHCPv4 specification, this is required by it. Here's the text from RFC = 2131:

     To help
     ensure that any BOOTP relay = agents forward the DHCPREQUEST message
     to the same set of DHCP = servers that received the original
     DHCPDISCOVER message, the = DHCPREQUEST message MUST use the same
     value in the DHCP message = header's 'secs' field and be sent to the
     same IP broadcast address = as the original DHCPDISCOVER message.

I did forget to mention that we might just need to do = that - have the server return the elapsed time option to the = client!

I don't have any issue in changing things from DHCPv4 = ... I was just assuming we MIGHT want to use that model since it has = been tried and proven?

I also agree that having the relay base the = forwarding on the elapsed time is likely bad - but again, that was = assumed to happen with DHCPv4!!

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Thursday, May 09, 2002 12:55 PM
To: Bernie Volz (EUD)
Cc: 'Thomas Narten'; dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option =


> If the server should fail to get a Reply to the = Request and restarts the
> Solicit, time should not be reset.
>
> - Time is 0 when first Renew/Rebind is sent. = Increases with each
> retransmission until timeout or Reply.
>
> - Time is 0 when first Decline/Release is sent. = Increases with each
> retransmission until timeout or Reply.
>
> - Time is 0 when first Information-Request is = sent. Increases with each
> retransmission until timeout or Reply.
>

I think if you let the relay agent make relaying = decisions based on the
time sent by the client, you're in big = trouble.   Picture this:

client sends solicit A, t=3D0
relay sends solicit to server A
client sends solicit B, t=3D100
relay sends solicit to server B
server A responds to solicit A with advertise = A
client sends Request A, t=3D100
relay sends Request A to server B
server B drops Request A on the floor

repeat until bored

The only reliable way to fix this is to have the = server send the time it
received from the client in the solicit back to the = client in the advertise,
  and for the client to use that time in every = subsequent Request,
regardless of how long it has to retry.   = This is complicated to specify,
and complicated to implement.   Do we = really want this?

------_=_NextPart_001_01C1F77F.DAE98990-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 13:47: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 NAA02304; Thu, 9 May 2002 13:47:21 -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 NAA12675; Thu, 9 May 2002 13:43:37 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12648 for ; Thu, 9 May 2002 13:43:35 -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 NAA02210 for ; Thu, 9 May 2002 13:43:26 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g49HgVS13530; Thu, 9 May 2002 10:42:31 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g49HhW602086; Thu, 9 May 2002 12:43:32 -0500 (CDT) Date: Thu, 9 May 2002 12:43:32 -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: "'Thomas Narten'" , dhcwg@ietf.org To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3E1@EAMBUNT705> Message-Id: <47CC76B8-6374-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 also agree that having the relay base the forwarding on the elapsed time > is likely bad - but again, that was assumed to happen with DHCPv4!! I think it's useful to have the relay be able to do this, but I'm not convinced that it's actually going to get used. There are relays that allow you to configure a delayed relay parameter, but do we know of any that are actually used this way? I don't personally know of anybody who' s doing this. I suspect that this is something that's a good idea in theory, but not in practice, and because of that, I think it might be a better choice to simply leave it out of the spec. The only reason to even *consider* putting it in the spec is that if it doesn't go in now, it will never be possible to do it - if clients and servers don't do the right thing from the outset, there's no way to retrofit this capability later. I'm just really skeptical that we're ever going to need this, and furthermore I'm skeptical that something like this is going to get implemented correctly, when nothing will break immediately if either the server implementation or the client implementation is incorrect. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 13:55: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 NAA02539; Thu, 9 May 2002 13:55: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 NAA13256; Thu, 9 May 2002 13:55:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13186 for ; Thu, 9 May 2002 13:54:59 -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 NAA02491 for ; Thu, 9 May 2002 13:54:50 -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 g49Hswl14683 for ; Thu, 9 May 2002 12:54:58 -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 g49HswY23050 for ; Thu, 9 May 2002 12:54:58 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu May 09 12:54:57 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 9 May 2002 12:54:57 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3E5@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" Cc: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option Date: Thu, 9 May 2002 12:54:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F782.9C71FE10" 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_01C1F782.9C71FE10 Content-Type: text/plain; charset="iso-8859-1" So, I'm confused as to where you want to go with this? If we want to be able to make this happen in the future, we have to have clear rules as to when the elapsed time starts for each transaction. We also likely have to make sure that the server sends the option back to the client such that the same value can be used in follow-on messages (really just in the Request(s) after an Advertise?). Another question is whether single server messages (such as Renew, Decline, Release) should even make use of this option? Also, we we do allow this option in the single server messages (those with a Server Identifier), what does mean for relays? - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Thursday, May 09, 2002 1:44 PM To: Bernie Volz (EUD) Cc: 'Thomas Narten'; dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option > I also agree that having the relay base the forwarding on the elapsed time > is likely bad - but again, that was assumed to happen with DHCPv4!! I think it's useful to have the relay be able to do this, but I'm not convinced that it's actually going to get used. There are relays that allow you to configure a delayed relay parameter, but do we know of any that are actually used this way? I don't personally know of anybody who' s doing this. I suspect that this is something that's a good idea in theory, but not in practice, and because of that, I think it might be a better choice to simply leave it out of the spec. The only reason to even *consider* putting it in the spec is that if it doesn't go in now, it will never be possible to do it - if clients and servers don't do the right thing from the outset, there's no way to retrofit this capability later. I'm just really skeptical that we're ever going to need this, and furthermore I'm skeptical that something like this is going to get implemented correctly, when nothing will break immediately if either the server implementation or the client implementation is incorrect. ------_=_NextPart_001_01C1F782.9C71FE10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Elapsed Time option

So, I'm confused as to where you want to go with = this?

If we want to be able to make this happen in the = future, we have to have clear rules as to when the elapsed time starts = for each transaction. We also likely have to make sure that the server = sends the option back to the client such that the same value can be = used in follow-on messages (really just in the Request(s) after an = Advertise?).

Another question is whether single server messages = (such as Renew, Decline, Release) should even make use of this = option?


Also, we we do allow this option in the single server = messages (those with a Server Identifier), what does mean for = relays?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Thursday, May 09, 2002 1:44 PM
To: Bernie Volz (EUD)
Cc: 'Thomas Narten'; dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option =


> I also agree that having the relay base the = forwarding on the elapsed time
> is likely bad - but again, that was assumed to = happen with DHCPv4!!

I think it's useful to have the relay be able to do = this, but I'm not
convinced that it's actually going to get = used.   There are relays that
allow you to configure a delayed relay parameter, = but do we know of any
that are actually used this way?   I don't = personally know of anybody who'
s doing this.   I suspect that this is = something that's a good idea in
theory, but not in practice, and because of that, I = think it might be a
better choice to simply leave it out of the = spec.

The only reason to even *consider* putting it in the = spec is that if it
doesn't go in now, it will never be possible to do = it - if clients and
servers don't do the right thing from the outset, = there's no way to
retrofit this capability later.   I'm just = really skeptical that we're ever
going to need this, and furthermore I'm skeptical = that something like this
is going to get implemented correctly, when nothing = will break immediately
if either the server implementation or the client = implementation is
incorrect.

------_=_NextPart_001_01C1F782.9C71FE10-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 14:21:27 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 OAA03588; Thu, 9 May 2002 14:21: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 OAA15103; Thu, 9 May 2002 14:20: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 OAA15082 for ; Thu, 9 May 2002 14:20:36 -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 OAA03542 for ; Thu, 9 May 2002 14:20:27 -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 g49IJWS13643; Thu, 9 May 2002 11:19:32 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g49IKX602265; Thu, 9 May 2002 13:20:33 -0500 (CDT) Date: Thu, 9 May 2002 13:20:32 -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: "'Thomas Narten'" , "'dhcwg@ietf.org'" To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3E2@EAMBUNT705> Message-Id: <7320C0FB-6379-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 would say to keep things simple, we explicitly DISALLOW relays from > using this field?? > I'd go along with this if nobody else objects. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 14:23: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 OAA03803; Thu, 9 May 2002 14:23:33 -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 OAA15248; Thu, 9 May 2002 14:22: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 OAA15219 for ; Thu, 9 May 2002 14:22:23 -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 OAA03672 for ; Thu, 9 May 2002 14:22:13 -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 g49ILIS13650; Thu, 9 May 2002 11:21:18 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g49IMJ602271; Thu, 9 May 2002 13:22:19 -0500 (CDT) Date: Thu, 9 May 2002 13:22:19 -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: "'Thomas Narten'" , dhcwg@ietf.org To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3E5@EAMBUNT705> 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 If relays aren't using the time to decide to which server to relay, it's safe for servers to use it, because they're the end recipients of it. The only problem that comes in is when the relay might censor some messages to some servers at different times based on how long the client has been trying to send the message. So I think this field is useful as long as relays don't use it to decide to which server a message is sent. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 9 14:35:03 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 OAA04421; Thu, 9 May 2002 14:34: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 OAA16422; Thu, 9 May 2002 14:33: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 OAA16398 for ; Thu, 9 May 2002 14:33:13 -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 OAA04301 for ; Thu, 9 May 2002 14:33:04 -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 g49IW9S13688; Thu, 9 May 2002 11:32:10 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g49IXA602276; Thu, 9 May 2002 13:33:10 -0500 (CDT) Date: Thu, 9 May 2002 13:33:10 -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: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3E3@EAMBUNT705> Message-Id: <368D6962-637B-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 > The DHC WG Meeting Minutes that Ralph published stated that the WG did > want to have load balancing for relays. I specifically asked about this > issue and I was promoting that we don't do it. What is your recollection? I don't remember, but that doesn't sound incorrect. (I think that's as wishy-washy an answer as I can give, but I'm open to suggestions... :') > If we extend load balancing to relays, and load balancing includes the > ability to use the "elapsed-time", aren't we really asking for trouble? Maybe I'm making this too complicated. If the relay agent always _expands_ the set of servers to which it relays the packet as the retry time increases, it's safe. It's only unsafe in the case where the set of servers (A) to which the relay agent relays at time=t is _disjoint_ with the set of servers (B) to which the relay agent relays at time=t+1. As long as set A is a subset of set B, we're fine. This is probably something that we can specify pretty safely. > I would like to keep relays very simple in DHCPv6 and make them simply > forward the packets. All of the work should be done by servers, IMHO. I think this is a good motivation, and I don't mind going this route. Here's what I suggest: we specify that the time in the retry time field in a Request message that immediately follows an Advertise message should be the time since the first Solicit was sent, not the time since the first Request message was sent. This covers our patooties in the event that we change our mind on the Relay agent issue later. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 10 02:18: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 CAA08485; Fri, 10 May 2002 02:18:25 -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 CAA26538; Fri, 10 May 2002 02:17: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 CAA26473 for ; Fri, 10 May 2002 02:17:32 -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 CAA08449; Fri, 10 May 2002 02:17:23 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-32.cisco.com [10.21.96.32]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id CAA25739; Fri, 10 May 2002 02:16:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20020510002625.00b65c78@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 10 May 2002 02:03:19 -0400 To: Pekka Savola From: Ralph Droms Subject: Re: [dhcwg] Re: Last Call: Dynamic Host Configuration Protocol for IPv6 (DHCPv6) to Proposed Standard Cc: iesg@ietf.org, dhcwg@ietf.org In-Reply-To: References: <200205022245.SAA16989@ietf.org> 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 Pekka - thanks for your feedback on the DHCPv6 draft. I'm working on a document that describes the messages and options of DHCPv6 that would be required for DNS configuration. I expect to publish the document in a few days. - Ralph At 05:01 PM 5/6/2002 +0300, Pekka Savola wrote: >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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 10 11:33:10 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 LAA29012; Fri, 10 May 2002 11:33: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 LAA23736; Fri, 10 May 2002 11:32: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 LAA23674 for ; Fri, 10 May 2002 11:32:06 -0400 (EDT) Received: from palrel13.hp.com (palrel13.hp.com [156.153.255.238]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28934 for ; Fri, 10 May 2002 11:31:55 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel13.hp.com (Postfix) with ESMTP id D1CA74001A9; Fri, 10 May 2002 08:31:31 -0700 (PDT) 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 UAA09752; Fri, 10 May 2002 20:56:12 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Bernie Volz (EUD)'" , "'Ted Lemon'" Cc: "'Thomas Narten'" , Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option Date: Fri, 10 May 2002 21:03:15 +0530 Message-ID: <005a01c1f838$01428c00$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005B_01C1F866.1AFAC800" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-reply-to: <66F66129A77AD411B76200508B65AC69B4D3E2@EAMBUNT705> Importance: 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. ------=_NextPart_000_005B_01C1F866.1AFAC800 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit RE: [dhcwg] dhcpv6-24: Elapsed Time option I feel that this elapsed_time field can be better used by Relays. We should not restrict the relays not to use it. Request, Renew, Release, Decline - These messages are expected to be replied by the particular server which has assigned parameters, which is identified by server id field. So there is no need for the relay to divert to secondary server. In the case of Solicit and Information-request, the relay can use this option to decide up on sending it to secondary server or in load balancing. The problem that Ted referred if the elapsed_time is sent in request wont be there now, since client wont be using the elapsed_time in the request message... The possible scenario is... Client (SOLICIT (elapsed_time = 0)) --> Relay --> Set A of Servers No reply recevied <-- .......... .......... Client (SOLICIT (elapsed_time = 100)) --> Relay --> Set B of servers. Case a) -> 1 or more reply received.... client chooses one of the servers in the set and send REQUEST message case b)->no reply received till REQ_MAX_RC it can try with less prefered servers in set B who have replied. If still no reply received... it can proceed with solicit. the time elapsed will be the tolal time from the original SOLICIT sent.... Client (SOLICIT (elapsed_time = 300)) --> Relay --> Set C of servers Its purely configuration issue that whether Sets A B and C are independent (or) one is subset of other one, depending up on whether the relay is trying to do load balancing or trying to take care of failover. For confirm and rebind message, A should be subset of B, B in turn subset of C. Because, the client may have got IAs from more than one server and any of those servers should not be left out in subsequent sets.Again, this is purely configuration issue. And processing of elapsed time cannot be a big overhead to the relay. If the Elapsed_Time is used as last option in the client message, the processing will be easier. ~Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz (EUD) Sent: Thursday, May 09, 2002 11:05 PM To: 'Ted Lemon' Cc: 'Thomas Narten'; 'dhcwg@ietf.org' Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option Oh, I should add that in -24 we have: --- 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). A client SHOULD include an Elapsed Time option in messages to indicate how long the client has been trying to complete a DHCP transaction. Servers and Relay Agents use the data value in this ^^^^^^^^^^^^^^^^ option as input to policy controlling how a server responds to a client message. For example, the elapsed time option allows a secondary DHCP server to respond to a request when a primary server hasn't answered in a reasonable time. --- I would say to keep things simple, we explicitly DISALLOW relays from using this field?? - Bernie -----Original Message----- From: Bernie Volz (EUD) Sent: Thursday, May 09, 2002 1:32 PM To: 'Ted Lemon' Cc: 'Thomas Narten'; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Elapsed Time option Ted: Exactly correct. And in fact from my reading of the DHCPv4 specification, this is required by it. Here's the text from RFC 2131: To help ensure that any BOOTP relay agents forward the DHCPREQUEST message to the same set of DHCP servers that received the original DHCPDISCOVER message, the DHCPREQUEST message MUST use the same value in the DHCP message header's 'secs' field and be sent to the same IP broadcast address as the original DHCPDISCOVER message. I did forget to mention that we might just need to do that - have the server return the elapsed time option to the client! I don't have any issue in changing things from DHCPv4 ... I was just assuming we MIGHT want to use that model since it has been tried and proven? I also agree that having the relay base the forwarding on the elapsed time is likely bad - but again, that was assumed to happen with DHCPv4!! - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Thursday, May 09, 2002 12:55 PM To: Bernie Volz (EUD) Cc: 'Thomas Narten'; dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Elapsed Time option > If the server should fail to get a Reply to the Request and restarts the > Solicit, time should not be reset. > > - Time is 0 when first Renew/Rebind is sent. Increases with each > retransmission until timeout or Reply. > > - Time is 0 when first Decline/Release is sent. Increases with each > retransmission until timeout or Reply. > > - Time is 0 when first Information-Request is sent. Increases with each > retransmission until timeout or Reply. > I think if you let the relay agent make relaying decisions based on the time sent by the client, you're in big trouble. Picture this: client sends solicit A, t=0 relay sends solicit to server A client sends solicit B, t=100 relay sends solicit to server B server A responds to solicit A with advertise A client sends Request A, t=100 relay sends Request A to server B server B drops Request A on the floor repeat until bored The only reliable way to fix this is to have the server send the time it received from the client in the solicit back to the client in the advertise, and for the client to use that time in every subsequent Request, regardless of how long it has to retry. This is complicated to specify, and complicated to implement. Do we really want this? ------=_NextPart_000_005B_01C1F866.1AFAC800 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Elapsed Time option
 
I=20 feel that this elapsed_time field can be better used by=20 Relays.
We=20 should not restrict the relays not to use=20 it.
 
Request, Renew, Release, Decline - = These=20 messages are
expected to be replied by the particular = server which=20 has assigned parameters, which=20 is 
identified by server id field. So there is = no need=20 for the relay to
divert to secondary=20 server.
 
In=20 the case of Solicit and Information-request, the relay can use this=20
option to decide up on sending it to = secondary=20 server or in load balancing.
 
The=20 problem that Ted referred if the elapsed_time is sent in request wont = be=20 there
now, since client wont be using the = elapsed_time in=20 the request message...
 
The=20 possible scenario is...
 
Client (SOLICIT (elapsed_time =3D 0)) = --> Relay=20 --> Set A of Servers
 
No reply=20 = recevied           = ;        =20 <--
       &nbs= p;       =20 ..........
       &nbs= p;       =20 ..........
Client (SOLICIT=20 (elapsed_time =3D 100)) --> Relay --> Set B of=20 servers.
 
Case a) ->=20 1 or more reply received....
 
client chooses=20 one of the servers in the set and send REQUEST = message
 
case = b)->no reply received till REQ_MAX_RC=20
it=20 can try with less prefered servers in set B who have replied. If still = no=20 reply received...
 
it=20 can proceed with solicit. the time elapsed will be the tolal = time from the original SOLICIT=20 sent....
Client (SOLICIT (elapsed_time =3D 300)) = --> Relay -->=20 Set C of = servers
 
Its=20 purely configuration issue that whether Sets A B and C are independent = (or)
one=20 is subset of other one, depending up on whether the relay is trying to = do
load balancing or trying to take care of=20 failover.
 
For=20 confirm and rebind message, A should be subset of B, B in turn subset = of=20 C.
Because, the client may have got IAs from = more than=20 one server and any of those = servers
should not be left out in subsequent = sets.Again, this=20 is purely configuration = issue.
 
And=20 processing of elapsed time cannot be a big overhead to the relay. If = the=20 Elapsed_Time
is=20 used as last option in the client message, the processing will be = easier.=20
 
~Vijay
 
 
 
-----Original Message-----
From: = dhcwg-admin@ietf.org=20 [mailto:dhcwg-admin@ietf.org]On Behalf Of Bernie Volz=20 (EUD)
Sent: Thursday, May 09, 2002 11:05 PM
To: = 'Ted=20 Lemon'
Cc: 'Thomas Narten'; = 'dhcwg@ietf.org'
Subject: RE:=20 [dhcwg] dhcpv6-24: Elapsed Time option =

Oh, I should add that in -24 we have:

---

22.9. Elapsed Time

     =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3
      0 1 2 3 4 5 = 6 7 8 9 0=20 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
     = |     =20 OPTION_ELAPSED_TIME     =20 |          =20 option-len          = |=20
    =20 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
    =20 |         =20 elapsed-time         |=20
    =20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      = option-code  =20 OPTION_ELAPSED_TIME (8)

      = option-len   =20 2.

      elapsed-time  = The amount=20 of time since the client began its
          &nbs= p;        =20 current DHCP transaction.  This time is expressed in =
          &nbs= p;        =20 hundredths of a second (10^-2 seconds).

   A client SHOULD include an Elapsed Time = option in=20 messages to
   indicate how long = the client=20 has been trying to complete a DHCP
  =20 transaction.  Servers and Relay Agents use the data value in = this=20
          &nbs= p;            = ; =20 ^^^^^^^^^^^^^^^^
   option as = input to=20 policy controlling how a server responds to a
   client message.  For example, the elapsed = time option=20 allows a
   secondary DHCP server = to respond=20 to a request when a primary server
   hasn't=20 answered in a reasonable time.


---

I would say to keep things simple, we explicitly = DISALLOW=20 relays from using this field??

- Bernie

-----Original Message-----
From:=20 Bernie Volz (EUD)
Sent: Thursday, May 09, = 2002 1:32=20 PM
To: 'Ted Lemon'
Cc: 'Thomas=20 Narten'; dhcwg@ietf.org
Subject: RE: [dhcwg] = dhcpv6-24: Elapsed Time option


Ted:

Exactly correct. And in fact from my reading of the = DHCPv4=20 specification, this is required by it. Here's the text from RFC=20 2131:

     To help
     ensure that any BOOTP relay agents = forward the=20 DHCPREQUEST message
     = to the=20 same set of DHCP servers that received the original
     DHCPDISCOVER message, the = DHCPREQUEST message=20 MUST use the same
     = value in=20 the DHCP message header's 'secs' field and be sent to the =
     same IP broadcast address as the = original=20 DHCPDISCOVER message.

I did forget to mention that we might just need to = do that -=20 have the server return the elapsed time option to the = client!

I don't have any issue in changing things from = DHCPv4 ... I=20 was just assuming we MIGHT want to use that model since it has been = tried and=20 proven?

I also agree that having the relay base the = forwarding on the=20 elapsed time is likely bad - but again, that was assumed to happen = with=20 DHCPv4!!

- Bernie

-----Original Message-----
From: Ted=20 Lemon [mailto:Ted.Lemon@nominum.com]=20
Sent: Thursday, May 09, 2002 12:55 PM =
To: Bernie Volz (EUD)
Cc: 'Thomas = Narten';=20 dhcwg@ietf.org
Subject: Re: [dhcwg] = dhcpv6-24: Elapsed=20 Time option


> If the server should fail to get a Reply to the = Request=20 and restarts the
> Solicit, time should = not be=20 reset.
>
> - = Time is 0=20 when first Renew/Rebind is sent. Increases with each
> retransmission until timeout or Reply.
>
> - Time is 0 when first=20 Decline/Release is sent. Increases with each
>=20 retransmission until timeout or Reply.
>=20
> - Time is 0 when first Information-Request is = sent.=20 Increases with each
> retransmission = until timeout=20 or Reply.
>

I think if you let the relay agent make relaying = decisions=20 based on the
time sent by the client, you're = in big=20 trouble.   Picture this:

client sends solicit A, t=3D0
relay=20 sends solicit to server A
client sends = solicit B,=20 t=3D100
relay sends solicit to server = B
server A responds to solicit A with advertise A =
client sends Request A, t=3D100
relay sends=20 Request A to server B
server B drops Request = A on the=20 floor

repeat until bored

The only reliable way to fix this is to have the = server send=20 the time it
received from the client in the = solicit=20 back to the client in the advertise,
  = and for=20 the client to use that time in every subsequent Request, =
regardless of how long it has to retry.   This is = complicated=20 to specify,
and complicated to = implement.  =20 Do we really want this?

------=_NextPart_000_005B_01C1F866.1AFAC800-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 09:39: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 JAA16148; Sun, 12 May 2002 09:39: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 JAA19928; Sun, 12 May 2002 09:38: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 JAA19905 for ; Sun, 12 May 2002 09:38:01 -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 JAA16106 for ; Sun, 12 May 2002 09:37:49 -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 g4CDbxl18472 for ; Sun, 12 May 2002 08:37:59 -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 g4CDbxr05783 for ; Sun, 12 May 2002 08:37:59 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Sun May 12 08:37:58 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 12 May 2002 08:37:58 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3EB@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Bound, Jim'" , Thomas Narten , Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Sun, 12 May 2002 08:37:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F9BA.3A664A20" 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_01C1F9BA.3A664A20 Content-Type: text/plain; charset="iso-8859-1" Jim: >We have no way as a server to know prefixes so kill #2 as argument. Huh? How could it be set up to provide addresses on a link for which it doesn't know the prefixes? There may well be a "not authoritative" setting (using the ISC DHCP server configuration concepts) that would tell a server it may not have complete information for a link - and in this case the server could not send a "NotOnLink" response to a Confirm. - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Sunday, May 12, 2002 12:58 AM To: Bernie Volz (EUD); Thomas Narten; Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Bernie, We have no way as a server to know prefixes so kill #2 as argument. We CANNOT assume prefix length for any IPv6 address unless the client tells us and it does not now. Nor should it IMO. thanks /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, May 09, 2002 9:24 AM To: 'Thomas Narten'; Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Thomas: My desire for the Confirm would be as follows: - Client can send a Confirm to help in movement detection. It shouldn't be required for the client to do this since it may have other means of doing this. - A server that does implement Confirm handles the message in three ways: 1. If it has the binding for the client and the addresses are valid, it can send a Reply with the success indication. This would be the case if the client hasn't really moved. 2. If it doesn't have a binding but in comparing the addresses provided in the Confirm, the server can determine that the prefixes for the addresses are NOT valid for the link, the server can Reply to the client that the addresses are bad. 3. The server discards the Confirm since it can not verify that the addresses are truely valid for the client. (We could allow another Reply from the server that would indicate to the client that the prefixes appear to be valid, but it can't confirm the actual addresses. However, this isn't really necessary since no response to the Confirm essentially means that and it could give false information at times; that is why it would be best not to have servers do this.) - While I think servers SHOULD implement Confirm, they don't have to. If they don't, they won't enhance movement detection but since there are other mechanisms that can help with this, it is not required. - Confirm processing is much different than a Renew/Rebind. There is much less work involved on the server - it is only verifying the information. A Confirm can NOT be used to extend address lifetimes/leases. IMHO, it should only be used to help the client determine whether it moved. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, May 09, 2002 9:00 AM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message > Confirm - client has detected it may have moved, sends > Confirm to any available server to determine > if configuration is still valid > Renew - client unicasts to assigning server to extend > lease on IA > Rebind - client sends to any available server to extend > lease on IA Including the above in the overview would be very helpful. It's not clearly described there, and the above description really helps me to understand why/how the messages differ. > Thomas - rereading your original question, I'm not sure if you're > suggesting that a client not try to detect if it has moved to a new link, > or if it use a Renew instead of a Rebind when it detects it may have moved > to a new link. I believe a client should definitely try to detect when it has moved. What I was wondering about is whether DHC should be specifying *how* it does movement detection (since this is a general topic), and whether DHC should provide explicit mechanisms (beyond other existing message types) that help the client determine if it has moved. Seems to me the Confirm is (maybe?) just an optimization. Couldn't the client just send a Renew to the assigning server? I gather that one advantage of the Confirm is that it is sent to all servers, so one will respond quickly. If the client sends a Renew to a specific server, but the client has moved, the Renew will presumably time out, which takes a lot longer. But in terms of the amount of work a server has to do when processing Confirm vs. Renew, the work is pretty much the same, I would think. I assume that this is the motivation for Confirm. Question: when one sends a confirm, does only the server that has that information respond, or are all servers expected to respond? The text says: > In any situation when a client may have moved to a new link, the > client MUST initiate a Confirm/Reply message exchange. The client > includes any IAs, along with the addresses associated with those IAs, > in its Confirm message. Any responding servers will indicate the > acceptability of the addresses with the status in the Reply message > it returns to the client. But how do other servers know that they are to respond positively? I would expect that only server that originally allocated the addresses to be able to respond positively that the config is valid. Maybe the text isn't explicit enough about what a server does when it gets a Confirm. Does it just check that the addresses are on the link as indicated by the link-address field in the relayed packet? This would be sufficient to verify that client hasn't moved. If it needs to verify that the actual addresses have been assigned it's not clear that any server can do that. This makes me wonder if this is really very much better than just using Renew (if only one server can respond anyway). The text says (under server processing): > If the server finds that the information for the client does not > match what is in the binding for that client or the configuration > information is not valid, the server sends a Reply message containing > a Status Code option with the value ConfNoMatch. I think more text would be good to make it clear that a server can also respond positively even if it can't verify the actual binding. Likewise, a positive response in that case DOSE NOT actually confirm the binding, just that the node hasn't moved. Make sense? > I think from: > >if a client detects that it has > >moved, then just have it redo the normal DHC exchanges. > you mean keep movement detection but use different DHCP messages. Exactly > what did you have in mind for "normal DHCP exchange"? Renew, Rebind and or just restarting with solicit. > The idea behind > Confirm is (as is the case in DHCPv4) if the client has not moved (e.g., > the client has been power cycled), the client uses a two message exchange > with any available server rather than a four message exchange. This assumes that *any* server is in a position to respond definitively. This is not immediately clear to me per above. > Perhaps Confirm overlaps with Rapid Commit? Hmm. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F9BA.3A664A20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: movement detection and Confirm message =

Jim:

>We have no way as a server to know prefixes so = kill #2 as argument.

Huh? How could it be set up to provide addresses on a = link for which it doesn't know the prefixes? There may well be a = "not authoritative" setting (using the ISC DHCP server = configuration concepts) that would tell a server it may not have = complete information for a link - and in this case the server could not = send a "NotOnLink" response to a Confirm.

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Sunday, May 12, 2002 12:58 AM
To: Bernie Volz (EUD); Thomas Narten; Ralph = Droms
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: movement detection = and Confirm message


Bernie,

We have no way as a server to know prefixes so kill = #2 as argument.  We CANNOT assume prefix length for any IPv6 = address unless the client tells us and it does not now.  Nor = should it IMO.

thanks
/jim
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.erics= son.se]
Sent: Thursday, May 09, 2002 9:24 AM
To: 'Thomas Narten'; Ralph Droms
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: movement detection = and Confirm message


Thomas:
My desire for the Confirm would be as follows: =
- Client can send a Confirm to help in movement = detection. It shouldn't be required for the client to do this since it = may have other means of doing this.

- A server that does implement Confirm handles the = message in three ways:
1. If it has the binding for the client and the = addresses are valid, it can send a Reply with the success indication. = This would be the case if the client hasn't really moved.

2. If it doesn't have a binding but in comparing the = addresses provided in the Confirm, the server can determine that the = prefixes for the addresses are NOT valid for the link, the server can = Reply to the client that the addresses are bad.

3. The server discards the Confirm since it can not = verify that the addresses are truely valid for the client.
(We could allow another Reply from the server that = would indicate to the client that the prefixes appear to be valid, but = it can't confirm the actual addresses. However, this isn't really = necessary since no response to the Confirm essentially means that and = it could give false information at times; that is why it would be best = not to have servers do this.)

- While I think servers SHOULD implement Confirm, = they don't have to. If they don't, they won't enhance movement = detection but since there are other mechanisms that can help with this, = it is not required.

- Confirm processing is much different than a = Renew/Rebind. There is much less work involved on the server - it is = only verifying the information. A Confirm can NOT be used to extend = address lifetimes/leases. IMHO, it should only be used to help the = client determine whether it moved.

- Bernie
-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Thursday, May 09, 2002 9:00 AM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: movement detection = and Confirm message



> Confirm - client has detected it may have moved, = sends
>          = ;  Confirm to any available server to determine
>          = ;  if configuration is still valid
> Renew   - client unicasts to = assigning server to extend
>          = ;  lease on IA
> Rebind  - client sends to any available = server to extend
>          = ;  lease on IA
Including the above in the overview would be very = helpful. It's not
clearly described there, and the above description = really helps me to
understand why/how the messages differ.
> Thomas - rereading your original question, I'm = not sure if you're
> suggesting that a client not try to detect if = it has moved to a new link,
> or if it use a Renew instead of a Rebind when = it detects it may have moved
> to a new link.
I believe a client should definitely try to detect = when it has
moved. What I was wondering about is whether DHC = should be specifying
*how* it does movement detection (since this is a = general topic), and
whether DHC should provide explicit mechanisms = (beyond other existing
message types) that help the client determine if it = has moved.
Seems to me the Confirm is (maybe?) just an = optimization. Couldn't the
client just send a Renew to the assigning server? =
I gather that one advantage of the Confirm is that = it is sent to all
servers, so one will respond quickly. If the client = sends a Renew to a
specific server, but the client has moved, the Renew = will presumably
time out, which takes a lot longer. But in terms of = the amount of work
a server has to do when processing Confirm vs. = Renew, the work is
pretty much the same, I would think.  I assume = that this is the
motivation for Confirm.
Question: when one sends a confirm, does only the = server that has that
information respond, or are all servers expected to = respond?
The text says:
>    In any situation when a = client may have moved to a new link, the
>    client MUST initiate a = Confirm/Reply message exchange.  The client
>    includes any IAs, along with = the addresses associated with those IAs,
>    in its Confirm message.  = Any responding servers will indicate the
>    acceptability of the = addresses with the status in the Reply message
>    it returns to the client. =


But how do other servers know that they are to = respond positively? I
would expect that only server that originally = allocated the addresses
to be able to respond positively that the config is = valid. Maybe the
text isn't explicit enough about what a server does = when it gets a
Confirm. Does it just check that the  addresses = are on the link as
indicated by the link-address field in the relayed = packet? This would
be sufficient to verify that client hasn't moved. If = it needs to
verify that the actual addresses have been = assigned  it's not clear
that any server can do that. This makes me wonder if = this is really
very much better than just  using Renew (if = only one server can
respond anyway).
The text says (under server processing):
>    If the server finds that the = information for the client does not
>    match what is in the binding = for that client or the configuration
>    information is not valid, the = server sends a Reply message containing
>    a Status Code option with the = value ConfNoMatch.
I think more text would be good to make it clear = that a server can also
respond positively even if it can't verify the = actual
binding. Likewise, a positive response in that case = DOSE NOT actually
confirm the binding, just that the node hasn't = moved.
Make sense?
> I think from:
> >if a client detects that it has
> >moved, then just have it redo the normal = DHC exchanges.
> you mean keep movement detection but use = different DHCP messages.  Exactly
> what did you have in mind for "normal DHCP = exchange"?
Renew, Rebind and or just restarting with solicit. =
> The idea behind
> Confirm is (as is the case in DHCPv4) if the = client has not moved (e.g.,
> the client has been power cycled), the client = uses a two message exchange
> with any available server rather than a four = message exchange.
This assumes that *any* server is in a position to = respond
definitively. This is not immediately clear to me = per above.
> Perhaps Confirm overlaps with Rapid Commit? =
Hmm.
Thomas
_______________________________________________ =
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg =

------_=_NextPart_001_01C1F9BA.3A664A20-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 09:41: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 JAA16224; Sun, 12 May 2002 09:41:56 -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 JAA20028; Sun, 12 May 2002 09:41: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 JAA20002 for ; Sun, 12 May 2002 09:41:31 -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 JAA16211 for ; Sun, 12 May 2002 09:41:20 -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 g4CDf0i04920 for ; Sun, 12 May 2002 08:41:00 -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 g4CDf0r05896 for ; Sun, 12 May 2002 08:41:00 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Sun May 12 08:40:44 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 12 May 2002 08:40:44 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3EC@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Bound, Jim'" , Thomas Narten , "Bernie Volz (EUD)" Cc: Ole Troan , Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast Date: Sun, 12 May 2002 08:40:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F9BA.9CCB3180" 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_01C1F9BA.9CCB3180 Content-Type: text/plain; charset="iso-8859-1" Jim: Did you mistype here ... "This is not a good argument IMO for confirm."? What does anycast have to do with Confirm (well, the message might need to be anycast in NMBA networks but so would a Solicit, Information-Request, Rebind, ...). - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Sunday, May 12, 2002 12:58 AM To: Thomas Narten; Bernie Volz (EUD) Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast One thing I don't agree with is that its hard to figure out of you have multicast existent on an interface? All of us support some form of sysconf to do that. This is not a good argument IMO for confirm. (I am not against confirm) but to have it because of the API comment is not good). /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 09, 2002 9:23 AM > To: Bernie Volz (EUD) > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: use of anycast > > > > The only issue with this is that DHCP usually runs as an application > > and is therefore only able to access that information which the > > lower layers (via APIs) make available. > > Understood. > > > Determining whether multicast is supported or not is pretty standard > > from the socket API. However, determining that a particular > > interface is a specific media type may be difficult. > > OK. > > > Therefore, there is some value in providing a clear direction here > > that is also relatively easy to implement. > > Agreed. > > > If all interface types provide multicast (either inherently or via > > some type of emulation), there is little need to ever use the > > anycast address and so what harm is there in specifying it. > > The harm is that a) we may define something that isn't useful (which > may cause problems when deployed because some implementations choose > use the feature even if it doesn't work as intended). b) clients may > choose to send to anycast addresses, but if servers aren't configured > to deal with them, we don't get interoperability, so specifying that > clients MAY do something really implies (to me) that server SHOULD (or > maybe even MUST) be prepared to handle such packets from clients. If > the client can't expect a server to handle something, there is little > point in clients implementing the feature either. > > My general opinion: if its not clear something is useful, and it's not > obvious what the details should be, including the feature distracts > from the overall goal of getting the spec done. The more one can > remove, the fewer details that have to be gotten right. > > > What we probably should say is that the client MUST use the > > multicast address if the interface on which it is sending the > > message supports multicast. Otherwise, it may use the anycast > > address. > > This is OK with me. Just so long as it's clear that the anycast usage > is only link-local and is only for reaching servers (and relay agents) > on the same link. This seems like a straightforward thing to get > right. > > Thomas > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > ------_=_NextPart_001_01C1F9BA.9CCB3180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: use of anycast

Jim:

Did you mistype here ... "This is not a good = argument IMO for confirm."? What does anycast have to do with = Confirm (well, the message might need to be anycast in NMBA networks = but so would a Solicit, Information-Request, Rebind, ...).

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Sunday, May 12, 2002 12:58 AM
To: Thomas Narten; Bernie Volz (EUD)
Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: use of anycast =


One thing I don't agree with is that its hard to = figure out of you have multicast existent on an interface?  All of = us support some form of sysconf to do that.

This is not a good argument IMO for confirm.

(I am not against confirm) but to have it because of = the API comment is not good).

/jim

> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com]
> Sent: Thursday, May 09, 2002 9:23 AM
> To: Bernie Volz (EUD)
> Cc: Ole Troan; Ralph Droms; = dhcwg@ietf.org
> Subject: Re: [dhcwg] dhcpv6-24: use of anycast =
>
>
> > The only issue with this is that DHCP = usually runs as an application
> > and is therefore only able to access that = information which the
> > lower layers (via APIs) make = available.
>
> Understood.
>
> > Determining whether multicast is supported = or not is pretty standard
> > from the socket API. However, determining = that a particular
> > interface is a specific media type may be = difficult.
>
> OK.
>
> > Therefore, there is some value in = providing a clear direction here
> >  that is also relatively easy to = implement.
>
> Agreed.
>
> > If all interface types provide multicast = (either inherently or via
> > some type of emulation), there is little = need to ever use the
> > anycast address and so what harm is there = in specifying it.
>
> The harm is that a) we may define something = that isn't useful (which
> may cause problems when deployed because some = implementations choose
> use the feature even if it doesn't work as = intended). b) clients may
> choose to send to anycast addresses, but if = servers aren't configured
> to deal with them, we don't get = interoperability, so specifying that
> clients MAY do something really implies (to me) = that server SHOULD (or
> maybe even MUST) be prepared to handle such = packets from clients. If
> the client  can't expect a server to = handle something, there is little
> point in clients implementing the feature = either.
>
> My general opinion: if its not clear something = is useful, and it's not
> obvious what the details should be, including = the feature distracts
> from the overall goal of getting the spec done. = The more one can
> remove, the fewer details that have to be = gotten right.
>
> > What we probably should say is that the = client MUST use the
> > multicast address if the interface on = which it is sending the
> > message supports multicast. Otherwise, it = may use the anycast
> > address.
>
> This is OK with me. Just so long as it's clear = that the anycast usage
> is only link-local and is only for reaching = servers (and relay agents)
> on the same link. This seems like a = straightforward thing to get
> right.
>
> Thomas
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

------_=_NextPart_001_01C1F9BA.9CCB3180-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 09:45:49 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 JAA16359; Sun, 12 May 2002 09:45: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 JAA20191; Sun, 12 May 2002 09:45:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25423 for ; Sun, 12 May 2002 00:57:38 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28794 for ; Sun, 12 May 2002 00:57:25 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id E2A735945; Sun, 12 May 2002 00:57:36 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 00:57:36 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Date: Sun, 12 May 2002 00:57:36 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A5A@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Thread-Index: AcH2+1HxQ4cNzZsrQW6WAcEGqg3zhwB2OFCw From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Ralph Droms" , X-OriginalArrivalTime: 12 May 2002 04:57:36.0763 (UTC) FILETIME=[88F78CB0:01C1F971] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA25424 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 Bernie, It could be reset by RA to FALSE fyi. /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, May 08, 2002 9:45 PM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Yes, that is my assumption - that the host has to wait for an RA. The Stateless Autoconfiguration RFC doesn't state this explicitly and also doesn't cover the case of a moving client (at least that I could find). It seems to me that if a host follows that specification, once the ManagedFlag is set to TRUE the only way it can ever be set to FALSE is via a reboot of the host. There always is the possibility that a host's policy could force the ManagedFlag to be TRUE always? Though why you'd want to do this is not clear to me. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, May 08, 2002 7:38 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Thomas comment (below) raised a question in my mind. Is the state of the managedFlag always go to FALSE or is it maintained across systems restarts? That is, does a host always come up in stateless mode and then switch to stateful upon receipt of the first RA. If the client does always come up in stateless mode, does the following text cause the first Solicit to be delayed until at least the receipt of the first RA? 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). At 11:00 AM 5/8/2002 -0400, Thomas Narten wrote: >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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 09:46:06 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 JAA16395; Sun, 12 May 2002 09:46: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 JAA20236; Sun, 12 May 2002 09:45: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 AAA25428 for ; Sun, 12 May 2002 00:57:39 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28797 for ; Sun, 12 May 2002 00:57:27 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 0106E36F2; Sun, 12 May 2002 00:57:38 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 00:57:37 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Date: Sun, 12 May 2002 00:57:37 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A5B@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Thread-Index: AcH3Un1jvxSvqXFYQ/6DSsjRv9WhQQBghWEw From: "Bound, Jim" To: "Thomas Narten" , "Ralph Droms" Cc: X-OriginalArrivalTime: 12 May 2002 04:57:37.0857 (UTC) FILETIME=[899E7B10:01C1F971] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA25429 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 Exactly. /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 09, 2002 8:08 AM > To: Ralph Droms > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: randomization delay before > invoking DHC > > > Ralph Droms writes: > > > Thomas comment (below) raised a question in my mind. Is the state > > of the managedFlag always go to FALSE or is it maintained across > > systems restarts? That is, does a host always come up in stateless > > mode and then switch to stateful upon receipt of the first RA. If > > the client does always come up in stateless mode, does the following > > text cause the first Solicit to be delayed until at least the > > receipt of the first RA? > > My take. When a node reboots, the first thing it *always* does is > solicit an RA. When it gets the response RA, it has new information > that overrides the old information. So the old information isn't > relevant. That information either says invoke DHC or don't. > > If it *doesn't* get an RA, that implies there are no routers. But the > ND (or addrconf?) spec already says that if there are no routers, then > you invoke stateful. > > So I think no special words are needed, reasonable behavior is already > defined elsewhere. > > 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 dhcwg-admin@ietf.org Sun May 12 09:46: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 JAA16425; Sun, 12 May 2002 09:46: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 JAA20306; Sun, 12 May 2002 09:45:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25444 for ; Sun, 12 May 2002 00:57:41 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28803 for ; Sun, 12 May 2002 00:57:28 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 15DA45945; Sun, 12 May 2002 00:57:40 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 00:57:39 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: use of anycast Date: Sun, 12 May 2002 00:57:39 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A5D@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: use of anycast Thread-Index: AcH3XRrzzREPQob1TRq3wPOeSwhXlABeGi8Q From: "Bound, Jim" To: "Thomas Narten" , "Bernie Volz (EUD)" Cc: "Ole Troan" , "Ralph Droms" , X-OriginalArrivalTime: 12 May 2002 04:57:39.0935 (UTC) FILETIME=[8ADB8EF0:01C1F971] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA25446 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 One thing I don't agree with is that its hard to figure out of you have multicast existent on an interface? All of us support some form of sysconf to do that. This is not a good argument IMO for confirm. (I am not against confirm) but to have it because of the API comment is not good). /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 09, 2002 9:23 AM > To: Bernie Volz (EUD) > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: use of anycast > > > > The only issue with this is that DHCP usually runs as an application > > and is therefore only able to access that information which the > > lower layers (via APIs) make available. > > Understood. > > > Determining whether multicast is supported or not is pretty standard > > from the socket API. However, determining that a particular > > interface is a specific media type may be difficult. > > OK. > > > Therefore, there is some value in providing a clear direction here > > that is also relatively easy to implement. > > Agreed. > > > If all interface types provide multicast (either inherently or via > > some type of emulation), there is little need to ever use the > > anycast address and so what harm is there in specifying it. > > The harm is that a) we may define something that isn't useful (which > may cause problems when deployed because some implementations choose > use the feature even if it doesn't work as intended). b) clients may > choose to send to anycast addresses, but if servers aren't configured > to deal with them, we don't get interoperability, so specifying that > clients MAY do something really implies (to me) that server SHOULD (or > maybe even MUST) be prepared to handle such packets from clients. If > the client can't expect a server to handle something, there is little > point in clients implementing the feature either. > > My general opinion: if its not clear something is useful, and it's not > obvious what the details should be, including the feature distracts > from the overall goal of getting the spec done. The more one can > remove, the fewer details that have to be gotten right. > > > What we probably should say is that the client MUST use the > > multicast address if the interface on which it is sending the > > message supports multicast. Otherwise, it may use the anycast > > address. > > This is OK with me. Just so long as it's clear that the anycast usage > is only link-local and is only for reaching servers (and relay agents) > on the same link. This seems like a straightforward thing to get > right. > > 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 dhcwg-admin@ietf.org Sun May 12 09:46:23 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 JAA16468; Sun, 12 May 2002 09:46: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 JAA20265; Sun, 12 May 2002 09:45: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 AAA25433 for ; Sun, 12 May 2002 00:57:40 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28800 for ; Sun, 12 May 2002 00:57:27 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id BEBF58D64; Sun, 12 May 2002 00:57:38 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 00:57:38 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Sun, 12 May 2002 00:57:38 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A5C@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: movement detection and Confirm message Thread-Index: AcH3V4PJUN5PVx7lTziczGQXriaNzQBfXSSA From: "Bound, Jim" To: "Thomas Narten" , "Bernie Volz (EUD)" Cc: X-OriginalArrivalTime: 12 May 2002 04:57:38.0622 (UTC) FILETIME=[8A1335E0:01C1F971] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA25434 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 How about we drop it and permit Renew to to confirm if it wants to? /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 09, 2002 8:42 AM > To: Bernie Volz (EUD) > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: movement detection and > Confirm message > > > > 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. > > Right. > > > 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. > > I think that future work might better handle this. > > One approach might be to leave the Confirm stuff in for now, and if > better or more general ways of detecting movement are defined, drop > the config stuff in a revision. On the other hand, once its in the > spec, servers will have to implement it forever, so taking it out only > effects clients... > > 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 dhcwg-admin@ietf.org Sun May 12 09:46:32 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 JAA16497; Sun, 12 May 2002 09:46:32 -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 JAA20359; Sun, 12 May 2002 09:45:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25533 for ; Sun, 12 May 2002 00:58:18 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28838 for ; Sun, 12 May 2002 00:58:06 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 3A38136E3; Sun, 12 May 2002 00:58:17 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 00:58:17 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F971.A0AA9272" Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Sun, 12 May 2002 00:58:16 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A5E@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: movement detection and Confirm message Thread-Index: AcH3XRtQdUOucC+ORtiDfmRo5XfZ0ABeMGLw From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Thomas Narten" , "Ralph Droms" Cc: X-OriginalArrivalTime: 12 May 2002 04:58:17.0013 (UTC) FILETIME=[A0F53650:01C1F971] 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_001_01C1F971.A0AA9272 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bernie, We have no way as a server to know prefixes so kill #2 as argument. We = CANNOT assume prefix length for any IPv6 address unless the client tells = us and it does not now. Nor should it IMO. =20 thanks /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, May 09, 2002 9:24 AM To: 'Thomas Narten'; Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message=20 Thomas:=20 My desire for the Confirm would be as follows:=20 - Client can send a Confirm to help in movement detection. It shouldn't = be required for the client to do this since it may have other means of = doing this. - A server that does implement Confirm handles the message in three = ways:=20 1. If it has the binding for the client and the addresses are valid, it = can send a Reply with the success indication. This would be the case if = the client hasn't really moved. 2. If it doesn't have a binding but in comparing the addresses provided = in the Confirm, the server can determine that the prefixes for the = addresses are NOT valid for the link, the server can Reply to the client = that the addresses are bad. 3. The server discards the Confirm since it can not verify that the = addresses are truely valid for the client.=20 (We could allow another Reply from the server that would indicate to the = client that the prefixes appear to be valid, but it can't confirm the = actual addresses. However, this isn't really necessary since no response = to the Confirm essentially means that and it could give false = information at times; that is why it would be best not to have servers = do this.) - While I think servers SHOULD implement Confirm, they don't have to. If = they don't, they won't enhance movement detection but since there are = other mechanisms that can help with this, it is not required. - Confirm processing is much different than a Renew/Rebind. There is = much less work involved on the server - it is only verifying the = information. A Confirm can NOT be used to extend address = lifetimes/leases. IMHO, it should only be used to help the client = determine whether it moved. - Bernie=20 -----Original Message-----=20 From: Thomas Narten [ mailto:narten@us.ibm.com]=20 Sent: Thursday, May 09, 2002 9:00 AM=20 To: Ralph Droms=20 Cc: dhcwg@ietf.org=20 Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message=20 > Confirm - client has detected it may have moved, sends=20 > Confirm to any available server to determine=20 > if configuration is still valid=20 > Renew - client unicasts to assigning server to extend=20 > lease on IA=20 > Rebind - client sends to any available server to extend=20 > lease on IA=20 Including the above in the overview would be very helpful. It's not=20 clearly described there, and the above description really helps me to=20 understand why/how the messages differ.=20 > Thomas - rereading your original question, I'm not sure if you're=20 > suggesting that a client not try to detect if it has moved to a new = link,=20 > or if it use a Renew instead of a Rebind when it detects it may have = moved=20 > to a new link.=20 I believe a client should definitely try to detect when it has=20 moved. What I was wondering about is whether DHC should be specifying=20 *how* it does movement detection (since this is a general topic), and=20 whether DHC should provide explicit mechanisms (beyond other existing=20 message types) that help the client determine if it has moved.=20 Seems to me the Confirm is (maybe?) just an optimization. Couldn't the=20 client just send a Renew to the assigning server?=20 I gather that one advantage of the Confirm is that it is sent to all=20 servers, so one will respond quickly. If the client sends a Renew to a=20 specific server, but the client has moved, the Renew will presumably=20 time out, which takes a lot longer. But in terms of the amount of work=20 a server has to do when processing Confirm vs. Renew, the work is=20 pretty much the same, I would think. I assume that this is the=20 motivation for Confirm.=20 Question: when one sends a confirm, does only the server that has that=20 information respond, or are all servers expected to respond?=20 The text says:=20 > In any situation when a client may have moved to a new link, the=20 > client MUST initiate a Confirm/Reply message exchange. The client=20 > includes any IAs, along with the addresses associated with those = IAs,=20 > in its Confirm message. Any responding servers will indicate the=20 > acceptability of the addresses with the status in the Reply message = > it returns to the client.=20 But how do other servers know that they are to respond positively? I=20 would expect that only server that originally allocated the addresses=20 to be able to respond positively that the config is valid. Maybe the=20 text isn't explicit enough about what a server does when it gets a=20 Confirm. Does it just check that the addresses are on the link as=20 indicated by the link-address field in the relayed packet? This would=20 be sufficient to verify that client hasn't moved. If it needs to=20 verify that the actual addresses have been assigned it's not clear=20 that any server can do that. This makes me wonder if this is really=20 very much better than just using Renew (if only one server can=20 respond anyway).=20 The text says (under server processing):=20 > If the server finds that the information for the client does not=20 > match what is in the binding for that client or the configuration=20 > information is not valid, the server sends a Reply message = containing=20 > a Status Code option with the value ConfNoMatch.=20 I think more text would be good to make it clear that a server can also=20 respond positively even if it can't verify the actual=20 binding. Likewise, a positive response in that case DOSE NOT actually=20 confirm the binding, just that the node hasn't moved.=20 Make sense?=20 > I think from:=20 > >if a client detects that it has=20 > >moved, then just have it redo the normal DHC exchanges.=20 > you mean keep movement detection but use different DHCP messages. = Exactly=20 > what did you have in mind for "normal DHCP exchange"?=20 Renew, Rebind and or just restarting with solicit.=20 > The idea behind=20 > Confirm is (as is the case in DHCPv4) if the client has not moved = (e.g.,=20 > the client has been power cycled), the client uses a two message = exchange=20 > with any available server rather than a four message exchange.=20 This assumes that *any* server is in a position to respond=20 definitively. This is not immediately clear to me per above.=20 > Perhaps Confirm overlaps with Rapid Commit?=20 Hmm.=20 Thomas=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/dhcwg=20 ------_=_NextPart_001_01C1F971.A0AA9272 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: movement detection and Confirm = message
Bernie,

We have no way as a = server to=20 know prefixes so kill #2 as argument.  We CANNOT assume prefix = length for=20 any IPv6 address unless the client tells us and it does not now.  = Nor=20 should it IMO.
 
thanks
/jim
-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, May 09, = 2002=20 9:24 AM
To: 'Thomas Narten'; Ralph Droms
Cc:=20 dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: movement = detection=20 and Confirm message

Thomas:

My desire for the Confirm would be as = follows:

- Client can send a Confirm to help in movement = detection. It=20 shouldn't be required for the client to do this since it may have = other means=20 of doing this.

- A server that does implement Confirm handles the = message in=20 three ways:
1. If it has the binding for the = client=20 and the addresses are valid, it can send a Reply with the success = indication.=20 This would be the case if the client hasn't really moved.

2. If it doesn't have a binding but in comparing the = addresses=20 provided in the Confirm, the server can determine that the prefixes = for the=20 addresses are NOT valid for the link, the server can Reply to the = client that=20 the addresses are bad.

3. The server discards the Confirm since it can not = verify=20 that the addresses are truely valid for the client.

(We could allow another Reply from the server that = would=20 indicate to the client that the prefixes appear to be valid, but it = can't=20 confirm the actual addresses. However, this isn't really necessary = since no=20 response to the Confirm essentially means that and it could give false = information at times; that is why it would be best not to have servers = do=20 this.)

- While I think servers SHOULD implement Confirm, = they don't=20 have to. If they don't, they won't enhance movement detection but = since there=20 are other mechanisms that can help with this, it is not = required.

- Confirm processing is much different than a = Renew/Rebind.=20 There is much less work involved on the server - it is only verifying = the=20 information. A Confirm can NOT be used to extend address = lifetimes/leases.=20 IMHO, it should only be used to help the client determine whether it=20 moved.

- Bernie

-----Original Message-----
From:=20 Thomas Narten [mailto:narten@us.ibm.com] =
Sent: Thursday, May 09, 2002 9:00 AM
To: Ralph=20 Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: movement detection and = Confirm message=20



> Confirm - client has detected it may have = moved,=20 sends
>          =  =20 Confirm to any available server to determine
>          =  =20 if configuration is still valid
> = Renew  =20 - client unicasts to assigning server to extend
>          =  =20 lease on IA
> Rebind  - client sends = to any=20 available server to extend
>          =  =20 lease on IA

Including the above in the overview would be very = helpful.=20 It's not
clearly described there, and the = above=20 description really helps me to
understand = why/how the=20 messages differ.

> Thomas - rereading your original question, I'm = not sure=20 if you're
> suggesting that a client not = try to=20 detect if it has moved to a new link,
> = or if it=20 use a Renew instead of a Rebind when it detects it may have moved=20
> to a new link.

I believe a client should definitely try to detect = when it=20 has
moved. What I was wondering about is = whether DHC=20 should be specifying
*how* it does movement = detection=20 (since this is a general topic), and
whether = DHC=20 should provide explicit mechanisms (beyond other existing =
message types) that help the client determine if it has = moved.=20

Seems to me the Confirm is (maybe?) just an = optimization.=20 Couldn't the
client just send a Renew to the = assigning=20 server?

I gather that one advantage of the Confirm is that = it is sent=20 to all
servers, so one will respond quickly. = If the=20 client sends a Renew to a
specific server, = but the=20 client has moved, the Renew will presumably
time out,=20 which takes a lot longer. But in terms of the amount of work =
a server has to do when processing Confirm vs. Renew, the = work=20 is
pretty much the same, I would = think.  I assume=20 that this is the
motivation for = Confirm.

Question: when one sends a confirm, does only the = server that=20 has that
information respond, or are all = servers=20 expected to respond?

The text says:

>    In any situation when a = client may have=20 moved to a new link, the
>    client=20 MUST initiate a Confirm/Reply message exchange.  The = client=20
>    includes any IAs, along with = the=20 addresses associated with those IAs,
>    in its Confirm message.  Any = responding=20 servers will indicate the
>   =20 acceptability of the addresses with the status in the Reply = message=20
>    it returns to the = client.=20


But how do other servers know that they are to = respond=20 positively? I
would expect that only server = that=20 originally allocated the addresses
to be = able to=20 respond positively that the config is valid. Maybe the =
text isn't explicit enough about what a server does when it = gets=20 a
Confirm. Does it just check that the  = addresses=20 are on the link as
indicated by the = link-address field=20 in the relayed packet? This would
be = sufficient to=20 verify that client hasn't moved. If it needs to
verify=20 that the actual addresses have been assigned  it's not = clear=20
that any server can do that. This makes me wonder = if this is=20 really
very much better than just  = using Renew=20 (if only one server can
respond = anyway).

The text says (under server processing):

>    If the server finds that the=20 information for the client does not
>    match what is in the binding for that = client or=20 the configuration
>    = information=20 is not valid, the server sends a Reply message containing =
>    a Status Code option with the value=20 ConfNoMatch.

I think more text would be good to make it clear = that a server=20 can also
respond positively even if it can't = verify=20 the actual
binding. Likewise, a positive = response in=20 that case DOSE NOT actually
confirm the = binding, just=20 that the node hasn't moved.

Make sense?

> I think from:

> >if a client detects that it has =
> >moved, then just have it redo the normal DHC = exchanges.=20

> you mean keep movement detection but use = different DHCP=20 messages.  Exactly
> what did you = have in mind=20 for "normal DHCP exchange"?

Renew, Rebind and or just restarting with = solicit.

> The idea behind
> = Confirm is=20 (as is the case in DHCPv4) if the client has not moved (e.g., =
> the client has been power cycled), the client uses a two = message=20 exchange
> with any available server = rather than a=20 four message exchange.

This assumes that *any* server is in a position to=20 respond
definitively. This is not = immediately clear to=20 me per above.

> Perhaps Confirm overlaps with Rapid = Commit?

Hmm.

Thomas

_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------_=_NextPart_001_01C1F971.A0AA9272-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 09:46: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 JAA16519; Sun, 12 May 2002 09:46:33 -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 JAA20459; Sun, 12 May 2002 09:45: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 AAA25418 for ; Sun, 12 May 2002 00:57:36 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28791 for ; Sun, 12 May 2002 00:57:24 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 6425A8DD6; Sun, 12 May 2002 00:57:35 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 00:57:35 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: sending Information-request via multicast Date: Sun, 12 May 2002 00:57:34 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A59@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: sending Information-request via multicast Thread-Index: AcH27BY5cj/GjuFLStC+CJffjteujwB5+8qg From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 12 May 2002 04:57:35.0306 (UTC) FILETIME=[88193AA0:01C1F971] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA25419 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 I suggest a SHOULD. Lets not make it a MUST. Tomorrow we could have a good reason to send to site-local. In fact I believe we can remove the text all together? /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, May 08, 2002 7:32 PM > To: dhcwg@ietf.org > Cc: rdroms@cisco.com > Subject: RE: [dhcwg] dhcpv6-24: sending Information-request via > multicast > > > OK, given the lack of clarity and the reality that site-wide > multicast is > not always available, I think we should follow Bernie's > suggestion (3rd > para below). > > - Ralph > > At 11:19 AM 5/8/2002 -0500, Bernie Volz (EUD) wrote: > > >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.ie tf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 09:46: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 JAA16495; Sun, 12 May 2002 09:46: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 JAA20431; Sun, 12 May 2002 09:45: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 AAA25553 for ; Sun, 12 May 2002 00:58:20 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28843 for ; Sun, 12 May 2002 00:58:07 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id AF53C5945; Sun, 12 May 2002 00:58:18 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 00:58:18 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: use of anycast Date: Sun, 12 May 2002 00:58:18 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A5F@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: use of anycast Thread-Index: AcH3XWHgIzMDkxQOTMetp/aG8xu0KQBeK/aA From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Thomas Narten" Cc: "Ole Troan" , "Ralph Droms" , X-OriginalArrivalTime: 12 May 2002 04:58:18.0619 (UTC) FILETIME=[A1EA44B0:01C1F971] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA25554 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 Thomas, I am fine with this too. But what we are permitting the server to have an anycast address and the addr arch says don't do this? Will it not be kicked back again by the IESG because we did that? thanks /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, May 09, 2002 9:27 AM To: 'Thomas Narten'; Bernie Volz (EUD) Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast >> What we probably should say is that the client MUST use the >> multicast address if the interface on which it is sending the >> message supports multicast. Otherwise, it may use the anycast >> address. > >This is OK with me. Just so long as it's clear that the anycast usage >is only link-local and is only for reaching servers (and relay agents) >on the same link. This seems like a straightforward thing to get >right. Sounds fine to me. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, May 09, 2002 9:23 AM To: Bernie Volz (EUD) Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of anycast > The only issue with this is that DHCP usually runs as an application > and is therefore only able to access that information which the > lower layers (via APIs) make available. Understood. > Determining whether multicast is supported or not is pretty standard > from the socket API. However, determining that a particular > interface is a specific media type may be difficult. OK. > Therefore, there is some value in providing a clear direction here > that is also relatively easy to implement. Agreed. > If all interface types provide multicast (either inherently or via > some type of emulation), there is little need to ever use the > anycast address and so what harm is there in specifying it. The harm is that a) we may define something that isn't useful (which may cause problems when deployed because some implementations choose use the feature even if it doesn't work as intended). b) clients may choose to send to anycast addresses, but if servers aren't configured to deal with them, we don't get interoperability, so specifying that clients MAY do something really implies (to me) that server SHOULD (or maybe even MUST) be prepared to handle such packets from clients. If the client can't expect a server to handle something, there is little point in clients implementing the feature either. My general opinion: if its not clear something is useful, and it's not obvious what the details should be, including the feature distracts from the overall goal of getting the spec done. The more one can remove, the fewer details that have to be gotten right. > What we probably should say is that the client MUST use the > multicast address if the interface on which it is sending the > message supports multicast. Otherwise, it may use the anycast > address. This is OK with me. Just so long as it's clear that the anycast usage is only link-local and is only for reaching servers (and relay agents) on the same link. This seems like a straightforward thing to get right. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 09:48:02 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 JAA16596; Sun, 12 May 2002 09:48:02 -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 JAA20714; Sun, 12 May 2002 09:47: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 AAA25413 for ; Sun, 12 May 2002 00:57:36 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28788 for ; Sun, 12 May 2002 00:57:23 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 456FA35D1; Sun, 12 May 2002 00:57:34 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 00:57:34 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Date: Sun, 12 May 2002 00:57:33 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A58@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Thread-Index: AcH263RqOVCO9dXuS+e/MVZfMW2GugB6CwLg From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 12 May 2002 04:57:34.0212 (UTC) FILETIME=[87724C40:01C1F971] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id AAA25414 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 Most implementation always comes up stateless fyi. /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, May 08, 2002 7:38 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: randomization delay before > invoking DHC > > > Thomas comment (below) raised a question in my mind. Is the > state of the > managedFlag always go to FALSE or is it maintained across systems > restarts? That is, does a host always come up in stateless > mode and then > switch to stateful upon receipt of the first RA. If the > client does always > come up in stateless mode, does the following text cause the > first Solicit > to be delayed until at least the receipt of the first RA? > > 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). > > > At 11:00 AM 5/8/2002 -0400, Thomas Narten wrote: > > >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 > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 09:50:49 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 JAA16826; Sun, 12 May 2002 09:50: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 JAA20819; Sun, 12 May 2002 09:50: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 JAA20793 for ; Sun, 12 May 2002 09:50:13 -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 JAA16698 for ; Sun, 12 May 2002 09:50:02 -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 g4CDoBl19564 for ; Sun, 12 May 2002 08:50:11 -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 g4CDo1r06651 for ; Sun, 12 May 2002 08:50:11 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun May 12 08:49:35 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 12 May 2002 08:49:35 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3ED@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Bound, Jim'" , Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Date: Sun, 12 May 2002 08:48:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F9BB.AC43CE50" 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_01C1F9BB.AC43CE50 Content-Type: text/plain; charset="iso-8859-1" Jim: Yes, the flag can change from TRUE to FALSE, but the issue is when does stateful configuration stop (sorry I didn't state that more clearly last time): 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. So, once DHCP starts, this kind of implies that it never stops until a reboot of the system occurs. In -24 (17.1.2) we also have: A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client is configured with either MRC or MRD set to a value other than 0, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it SHOULD choose to restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link. So, if a client follows the SHOULD it would keep running the process. I guess one could assume that the client should stop transmitting Solicits if the ManagedFlag is false. - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Sunday, May 12, 2002 12:58 AM To: Bernie Volz (EUD); Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Bernie, It could be reset by RA to FALSE fyi. /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, May 08, 2002 9:45 PM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Yes, that is my assumption - that the host has to wait for an RA. The Stateless Autoconfiguration RFC doesn't state this explicitly and also doesn't cover the case of a moving client (at least that I could find). It seems to me that if a host follows that specification, once the ManagedFlag is set to TRUE the only way it can ever be set to FALSE is via a reboot of the host. There always is the possibility that a host's policy could force the ManagedFlag to be TRUE always? Though why you'd want to do this is not clear to me. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, May 08, 2002 7:38 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Thomas comment (below) raised a question in my mind. Is the state of the managedFlag always go to FALSE or is it maintained across systems restarts? That is, does a host always come up in stateless mode and then switch to stateful upon receipt of the first RA. If the client does always come up in stateless mode, does the following text cause the first Solicit to be delayed until at least the receipt of the first RA? 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). At 11:00 AM 5/8/2002 -0400, Thomas Narten wrote: >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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1F9BB.AC43CE50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: randomization delay before invoking = DHC

Jim:

Yes, the flag can change from TRUE to FALSE, but the = issue is when does stateful configuration stop (sorry I didn't state = that more clearly last time):

   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.

So, once DHCP starts, this kind of implies that it = never stops until a reboot of the system occurs.

In -24 (17.1.2) we also have:

   A DHCP client SHOULD choose MRC and MRD = to be 0.  If the DHCP client
   is configured with either MRC or MRD = set to a value other than
   0, it MUST stop trying to configure the = interface if the message
   exchange fails.  After the DHCP = client stops trying to configure the
   interface, it SHOULD choose to restart = the reconfiguration process
   after some external event, such as user = input, system restart, or
   when the client is attached to a new = link.

So, if a client follows the SHOULD it would keep = running the process.

I guess one could assume that the client should stop = transmitting Solicits if the ManagedFlag is false.

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Sunday, May 12, 2002 12:58 AM
To: Bernie Volz (EUD); Ralph Droms; = dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: randomization delay = before invoking DHC


Bernie,

It could be reset by RA to FALSE fyi.

/jim

-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.erics= son.se]
Sent: Wednesday, May 08, 2002 9:45 PM
To: 'Ralph Droms'; dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: randomization delay = before invoking DHC


Yes, that is my assumption - that the host has to = wait for an RA. The Stateless Autoconfiguration RFC doesn't state this = explicitly and also doesn't cover the case of a moving client (at least = that I could find). It seems to me that if a host follows that = specification, once the ManagedFlag is set to TRUE the only way it can = ever be set to FALSE is via a reboot of the host.

There always is the possibility that a host's policy = could force the ManagedFlag to be TRUE always? Though why you'd want to = do this is not clear to me.

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, May 08, 2002 7:38 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: randomization delay = before invoking DHC


Thomas comment (below) raised a question in my = mind.  Is the state of the
managedFlag always go to FALSE or is it maintained = across systems
restarts?  That is, does a host always come up = in stateless mode and then
switch to stateful upon receipt of the first = RA.  If the client does always
come up in stateless mode, does the following text = cause the first Solicit
to be delayed until at least the receipt of the = first RA?
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).


At 11:00 AM 5/8/2002 -0400, Thomas Narten wrote: =
>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 =


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

------_=_NextPart_001_01C1F9BB.AC43CE50-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 09:52: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 JAA16888; Sun, 12 May 2002 09:52:05 -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 JAA21064; Sun, 12 May 2002 09:51:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA21036 for ; Sun, 12 May 2002 09:51:47 -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 JAA16872 for ; Sun, 12 May 2002 09:51:35 -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 g4CDpjl19730 for ; Sun, 12 May 2002 08:51: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 g4CDpjr07017 for ; Sun, 12 May 2002 08:51:45 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun May 12 08:51:34 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 12 May 2002 08:51:34 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3EE@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Bound, Jim'" , Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Sun, 12 May 2002 08:51:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1F9BC.20A29BA0" 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_01C1F9BC.20A29BA0 Content-Type: text/plain; charset="iso-8859-1" But a Renew is only directed to the one server and it is down or not on the network, the client gets no response. What should it do? If it gets a Reply, it does know it is on the same network as before. If it gets no Reply, it knows only that it may not be on the same network OR that the original server is down. There, I think Renew isn't as useful as Confirm. - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Sunday, May 12, 2002 12:58 AM To: Thomas Narten; Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message How about we drop it and permit Renew to to confirm if it wants to? /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 09, 2002 8:42 AM > To: Bernie Volz (EUD) > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: movement detection and > Confirm message > > > > 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. > > Right. > > > 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. > > I think that future work might better handle this. > > One approach might be to leave the Confirm stuff in for now, and if > better or more general ways of detecting movement are defined, drop > the config stuff in a revision. On the other hand, once its in the > spec, servers will have to implement it forever, so taking it out only > effects clients... > > 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 ------_=_NextPart_001_01C1F9BC.20A29BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: movement detection and Confirm message =

But a Renew is only directed to the one server and it = is down or not on the network, the client gets no response. What should = it do?

If it gets a Reply, it does know it is on the same = network as before.

If it gets no Reply, it knows only that it may not be = on the same network OR that the original server is down.

There, I think Renew isn't as useful as = Confirm.

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Sunday, May 12, 2002 12:58 AM
To: Thomas Narten; Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: movement detection = and Confirm message


How about we drop it and permit Renew to to confirm = if it wants to?

/jim

> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com]
> Sent: Thursday, May 09, 2002 8:42 AM
> To: Bernie Volz (EUD)
> Cc: dhcwg@ietf.org
> Subject: Re: [dhcwg] dhcpv6-24: movement = detection and
> Confirm message
>
>
> > 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.
>
> Right.
>
> > 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.
>
> I think that future work might better handle = this.
>
> One approach might be to leave the Confirm = stuff in for now, and if
> better or more general ways of detecting = movement are defined, drop
> the config stuff in a revision. On the other = hand, once its in the
> spec, servers will have to implement it = forever, so taking it out only
> effects clients...
>
> 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

------_=_NextPart_001_01C1F9BC.20A29BA0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 10:44: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 KAA18569; Sun, 12 May 2002 10:44: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 KAA22857; Sun, 12 May 2002 10:43: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 KAA22831 for ; Sun, 12 May 2002 10:43: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 KAA18509 for ; Sun, 12 May 2002 10:42:58 -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 g4CEfqS24911; Sun, 12 May 2002 07:41:52 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4CEgxA00333; Sun, 12 May 2002 09:42:59 -0500 (CDT) Date: Sun, 12 May 2002 09:42:59 -0500 Subject: Re: [dhcwg] dhcpv6-24: use of anycast Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: , "Ralph Droms" , "Ole Troan" , "Bernie Volz (EUD)" , "Thomas Narten" To: "Bound, Jim" From: Ted Lemon In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A5D@tayexc13.americas.cpqcorp.net> Message-Id: <8DD54D80-65B6-11D6-BABF-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 am not against confirm) but to have it because of the API comment is > not good). I totally agree - we've burned ourselves in the past trying to justify things on the basis of broken APIs. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 10:46:10 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 KAA18622; Sun, 12 May 2002 10:46:10 -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 KAA22962; Sun, 12 May 2002 10:45: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 KAA22936 for ; Sun, 12 May 2002 10:45:51 -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 KAA18610 for ; Sun, 12 May 2002 10:45:39 -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 g4CEiWS24919; Sun, 12 May 2002 07:44:32 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4CEjdA00337; Sun, 12 May 2002 09:45:39 -0500 (CDT) Date: Sun, 12 May 2002 09:45:39 -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: , "Ralph Droms" , "Thomas Narten" , "Bernie Volz (EUD)" To: "Bound, Jim" From: Ted Lemon In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A5E@tayexc13.americas.cpqcorp.net> 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 server administrator will likely configure the DHCP server to know what the prefix lengths are for the subnets it serves, so in fact it will know prefix lengths, and we can use them. We shouldn't require the use of them in all cases, because the server administrator might _not_ configure the DHCP server with a complete list, but we can specify what to do if the DHCP server has them, and this will be of genuine use in real-world installations. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 10:47: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 KAA18679; Sun, 12 May 2002 10:47: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 KAA23006; Sun, 12 May 2002 10:46:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA22988 for ; Sun, 12 May 2002 10:46:47 -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 KAA18664 for ; Sun, 12 May 2002 10:46:35 -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 g4CEjaS24930; Sun, 12 May 2002 07:45:36 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4CEkhA00341; Sun, 12 May 2002 09:46:43 -0500 (CDT) Date: Sun, 12 May 2002 09:46:43 -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: "'Bound, Jim'" , Thomas Narten , Ralph Droms , dhcwg@ietf.org To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3EB@EAMBUNT705> Message-Id: <13AD54F0-65B7-11D6-BABF-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 > Huh? How could it be set up to provide addresses on a link for which it > doesn't know the prefixes? There may well be a "not authoritative" setting > (using the ISC DHCP server configuration concepts) that would tell a > server it may not have complete information for a link - and in this case > the server could not send a "NotOnLink" response to a Confirm. Right. Bernie put this much better than I did in my previous message. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 12:46:23 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 MAA21050; Sun, 12 May 2002 12:46: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 MAA26951; Sun, 12 May 2002 12:45: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 MAA26926 for ; Sun, 12 May 2002 12:45:44 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21021 for ; Sun, 12 May 2002 12:45:31 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4CGiqHU010167; Sun, 12 May 2002 09:44:52 -0700 (PDT) Date: Sun, 12 May 2002 12:44:52 -0400 (EDT) From: Ralph Droms To: "Bound, Jim" cc: "Bernie Volz (EUD)" , Thomas Narten , Ole Troan , Subject: RE: [dhcwg] dhcpv6-24: use of anycast In-Reply-To: <9C422444DE99BC46B3AD3C6EAFC9711B022D2A5F@tayexc13.americas.cpqcorp.net> 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 Jim makes a good good point about anycast. Given the current discussion about anycast addresses and hosts on the ipngwg mailing list, it would be premature to specify site-local anycast for DHCPv6. What about link-local only "anycast" - perhaps that's not really "anycast" because there's no routing? Instead of an anycast address, suppose we request the reservation of a link-scoped unicast address for DHCP? If we use a unicast address, only one relay agent or server on a link can be listening on that address, right? For point-to-point links that's not a problem - there can only be one relay agent or server at the other end of the point-to-point link. I'm still not clear about multiple-access links and multicast - are there any multiple access link technologies that don't provide or emulate multicast? Is there a precedent for the reservation of a link-scoped, well-known unicast address? Using a link-scoped unicast address, the first relay agent or server to bind to the address gets to use it. I'm not familiar with the IPv6 API; I assume that an application (with sufficient privilege) can make a request to assign a specific address to an interface. I guess the stack does DAD on the requested address and the request fails if the address is already in use? I'm not thrilled with my idea - it sounds fairly ugly. Does it break or bend fewer existing standards, or require the definition of fewer new standards than the use of an anycast address? Does the assignment of a well-known link-scoped unicast address for DHCP set a precedent we'd rather not set? The use of the unicast address could be further discouraged by including a restriction that relay agents and servers MUST NOT listen on the unicast address and clients MUST NOT send messages to the unicast address on a link that supports multicast. - Ralph On Sun, 12 May 2002, Bound, Jim wrote: > Thomas, > > I am fine with this too. But what we are permitting the server to have an anycast address and the addr arch says don't do this? Will it not be kicked back again by the IESG because we did that? > > thanks > /jim > > -----Original Message----- > From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > Sent: Thursday, May 09, 2002 9:27 AM > To: 'Thomas Narten'; Bernie Volz (EUD) > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > Subject: RE: [dhcwg] dhcpv6-24: use of anycast > > > >> What we probably should say is that the client MUST use the > >> multicast address if the interface on which it is sending the > >> message supports multicast. Otherwise, it may use the anycast > >> address. > > > >This is OK with me. Just so long as it's clear that the anycast usage > >is only link-local and is only for reaching servers (and relay agents) > >on the same link. This seems like a straightforward thing to get > >right. > Sounds fine to me. > - Bernie > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 09, 2002 9:23 AM > To: Bernie Volz (EUD) > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: use of anycast > > > > The only issue with this is that DHCP usually runs as an application > > and is therefore only able to access that information which the > > lower layers (via APIs) make available. > Understood. > > Determining whether multicast is supported or not is pretty standard > > from the socket API. However, determining that a particular > > interface is a specific media type may be difficult. > OK. > > Therefore, there is some value in providing a clear direction here > > that is also relatively easy to implement. > Agreed. > > If all interface types provide multicast (either inherently or via > > some type of emulation), there is little need to ever use the > > anycast address and so what harm is there in specifying it. > The harm is that a) we may define something that isn't useful (which > may cause problems when deployed because some implementations choose > use the feature even if it doesn't work as intended). b) clients may > choose to send to anycast addresses, but if servers aren't configured > to deal with them, we don't get interoperability, so specifying that > clients MAY do something really implies (to me) that server SHOULD (or > maybe even MUST) be prepared to handle such packets from clients. If > the client can't expect a server to handle something, there is little > point in clients implementing the feature either. > My general opinion: if its not clear something is useful, and it's not > obvious what the details should be, including the feature distracts > from the overall goal of getting the spec done. The more one can > remove, the fewer details that have to be gotten right. > > What we probably should say is that the client MUST use the > > multicast address if the interface on which it is sending the > > message supports multicast. Otherwise, it may use the anycast > > address. > This is OK with me. Just so long as it's clear that the anycast usage > is only link-local and is only for reaching servers (and relay agents) > on the same link. This seems like a straightforward thing to get > right. > Thomas > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 21:36:04 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 VAA08569; Sun, 12 May 2002 21:36:00 -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 VAA15827; Sun, 12 May 2002 21:35: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 VAA15801 for ; Sun, 12 May 2002 21:35:04 -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 VAA08362 for ; Sun, 12 May 2002 21:34:50 -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 g4D1YWi03703 for ; Sun, 12 May 2002 20:34:32 -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 g4D1YWr17808 for ; Sun, 12 May 2002 20:34:32 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Sun May 12 20:34:31 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 12 May 2002 20:34:31 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3EF@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , "Bound, Jim" Cc: Thomas Narten , Ole Troan , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast Date: Sun, 12 May 2002 20:34:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FA1E.52FE1270" 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_01C1FA1E.52FE1270 Content-Type: text/plain; charset="iso-8859-1" Ralph: I don't think the link-scoped unicast address is a good idea. What would the prefix for this be? If it is the standard link-local prefix, what about all the hosts today that don't have code to check for this value. I think we're best left with letting this issue be resolved by the first link that needs it (as Thomas originally suggested). So, perhaps we should simply say: "If the link supports multicast, the multicast address MUST be used. Otherwise, the link over IPv6 specification needs to specify what the DHCP Client must use." - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Sunday, May 12, 2002 12:45 PM To: Bound, Jim Cc: Bernie Volz (EUD); Thomas Narten; Ole Troan; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast Jim makes a good good point about anycast. Given the current discussion about anycast addresses and hosts on the ipngwg mailing list, it would be premature to specify site-local anycast for DHCPv6. What about link-local only "anycast" - perhaps that's not really "anycast" because there's no routing? Instead of an anycast address, suppose we request the reservation of a link-scoped unicast address for DHCP? If we use a unicast address, only one relay agent or server on a link can be listening on that address, right? For point-to-point links that's not a problem - there can only be one relay agent or server at the other end of the point-to-point link. I'm still not clear about multiple-access links and multicast - are there any multiple access link technologies that don't provide or emulate multicast? Is there a precedent for the reservation of a link-scoped, well-known unicast address? Using a link-scoped unicast address, the first relay agent or server to bind to the address gets to use it. I'm not familiar with the IPv6 API; I assume that an application (with sufficient privilege) can make a request to assign a specific address to an interface. I guess the stack does DAD on the requested address and the request fails if the address is already in use? I'm not thrilled with my idea - it sounds fairly ugly. Does it break or bend fewer existing standards, or require the definition of fewer new standards than the use of an anycast address? Does the assignment of a well-known link-scoped unicast address for DHCP set a precedent we'd rather not set? The use of the unicast address could be further discouraged by including a restriction that relay agents and servers MUST NOT listen on the unicast address and clients MUST NOT send messages to the unicast address on a link that supports multicast. - Ralph On Sun, 12 May 2002, Bound, Jim wrote: > Thomas, > > I am fine with this too. But what we are permitting the server to have an anycast address and the addr arch says don't do this? Will it not be kicked back again by the IESG because we did that? > > thanks > /jim > > -----Original Message----- > From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > Sent: Thursday, May 09, 2002 9:27 AM > To: 'Thomas Narten'; Bernie Volz (EUD) > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > Subject: RE: [dhcwg] dhcpv6-24: use of anycast > > > >> What we probably should say is that the client MUST use the > >> multicast address if the interface on which it is sending the > >> message supports multicast. Otherwise, it may use the anycast > >> address. > > > >This is OK with me. Just so long as it's clear that the anycast usage > >is only link-local and is only for reaching servers (and relay agents) > >on the same link. This seems like a straightforward thing to get > >right. > Sounds fine to me. > - Bernie > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 09, 2002 9:23 AM > To: Bernie Volz (EUD) > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: use of anycast > > > > The only issue with this is that DHCP usually runs as an application > > and is therefore only able to access that information which the > > lower layers (via APIs) make available. > Understood. > > Determining whether multicast is supported or not is pretty standard > > from the socket API. However, determining that a particular > > interface is a specific media type may be difficult. > OK. > > Therefore, there is some value in providing a clear direction here > > that is also relatively easy to implement. > Agreed. > > If all interface types provide multicast (either inherently or via > > some type of emulation), there is little need to ever use the > > anycast address and so what harm is there in specifying it. > The harm is that a) we may define something that isn't useful (which > may cause problems when deployed because some implementations choose > use the feature even if it doesn't work as intended). b) clients may > choose to send to anycast addresses, but if servers aren't configured > to deal with them, we don't get interoperability, so specifying that > clients MAY do something really implies (to me) that server SHOULD (or > maybe even MUST) be prepared to handle such packets from clients. If > the client can't expect a server to handle something, there is little > point in clients implementing the feature either. > My general opinion: if its not clear something is useful, and it's not > obvious what the details should be, including the feature distracts > from the overall goal of getting the spec done. The more one can > remove, the fewer details that have to be gotten right. > > What we probably should say is that the client MUST use the > > multicast address if the interface on which it is sending the > > message supports multicast. Otherwise, it may use the anycast > > address. > This is OK with me. Just so long as it's clear that the anycast usage > is only link-local and is only for reaching servers (and relay agents) > on the same link. This seems like a straightforward thing to get > right. > Thomas > ------_=_NextPart_001_01C1FA1E.52FE1270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: use of anycast

Ralph:

I don't think the link-scoped unicast address is a = good idea. What would the prefix for this be? If it is the standard = link-local prefix, what about all the hosts today that don't have code = to check for this value.

I think we're best left with letting this issue be = resolved by the first link that needs it (as Thomas originally = suggested).

So, perhaps we should simply say:

"If the link supports multicast, the multicast = address MUST be used. Otherwise, the link over IPv6 specification needs = to specify what the DHCP Client must use."

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Sunday, May 12, 2002 12:45 PM
To: Bound, Jim
Cc: Bernie Volz (EUD); Thomas Narten; Ole Troan; = dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: use of anycast =



Jim makes a good good point about anycast.  = Given the current
discussion about anycast addresses and hosts on the = ipngwg mailing
list, it would be premature to specify site-local = anycast for DHCPv6.

What about link-local only "anycast" - = perhaps that's not really
"anycast" because there's no = routing?

Instead of an anycast address, suppose we request the = reservation of a
link-scoped unicast address for DHCP?  If we = use a unicast address, only
one relay agent or server on a link can be listening = on that address,
right?  For point-to-point links that's not a = problem - there can only be
one relay agent or server at the other end of the = point-to-point link.
I'm still not clear about multiple-access links and = multicast - are
there any multiple access link technologies that = don't provide or emulate
multicast?

Is there a precedent for the reservation of a = link-scoped, well-known
unicast address?

Using a link-scoped unicast address, the first relay = agent or server to
bind to the address gets to use it.   I'm = not familiar with the IPv6 API;
I assume that an application (with sufficient = privilege) can make a
request to assign a specific address to an = interface.  I guess the stack
does DAD on the requested address and the request = fails if the address is
already in use?

I'm not thrilled with my idea - it sounds fairly = ugly.  Does it break or
bend fewer existing standards, or require the = definition of fewer new
standards than the use of an anycast address?  = Does the assignment of a
well-known link-scoped unicast address for DHCP set = a precedent we'd
rather not set?

The use of the unicast address could be further = discouraged by including a
restriction that relay agents and servers MUST NOT = listen on the unicast
address and clients MUST NOT send messages to the = unicast address on a
link that supports multicast.

- Ralph

 On Sun, 12 May 2002, Bound, Jim wrote:

> Thomas,
>
> I am fine with this too.  But what we are = permitting the server to have an anycast address and the addr arch says = don't do this?  Will it not be kicked  back again by the IESG = because we did that?

>
> thanks
> /jim
>
> -----Original Message-----
> From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.erics= son.se]
> Sent: Thursday, May 09, 2002 9:27 AM
> To: 'Thomas Narten'; Bernie Volz (EUD)
> Cc: Ole Troan; Ralph Droms; = dhcwg@ietf.org
> Subject: RE: [dhcwg] dhcpv6-24: use of = anycast
>
>
> >> What we probably should say is that = the client MUST use the
> >> multicast address if the interface on = which it is sending the
> >> message supports multicast. Otherwise, = it may use the anycast
> >> address.
> >
> >This is OK with me. Just so long as it's = clear that the anycast usage
> >is only link-local and is only for reaching = servers (and relay agents)
> >on the same link. This seems like a = straightforward thing to get
> >right.
> Sounds fine to me.
> - Bernie
> -----Original Message-----
> From: Thomas Narten [mailto:narten@us.ibm.com]
> Sent: Thursday, May 09, 2002 9:23 AM
> To: Bernie Volz (EUD)
> Cc: Ole Troan; Ralph Droms; = dhcwg@ietf.org
> Subject: Re: [dhcwg] dhcpv6-24: use of = anycast
>
>
> > The only issue with this is that DHCP = usually runs as an application
> > and is therefore only able to access that = information which the
> > lower layers (via APIs) make = available.
> Understood.
> > Determining whether multicast is supported = or not is pretty standard
> > from the socket API. However, determining = that a particular
> > interface is a specific media type may be = difficult.
> OK.
> > Therefore, there is some value in = providing a clear direction here
> >  that is also relatively easy to = implement.
> Agreed.
> > If all interface types provide multicast = (either inherently or via
> > some type of emulation), there is little = need to ever use the
> > anycast address and so what harm is there = in specifying it.
> The harm is that a) we may define something = that isn't useful (which
> may cause problems when deployed because some = implementations choose
> use the feature even if it doesn't work as = intended). b) clients may
> choose to send to anycast addresses, but if = servers aren't configured
> to deal with them, we don't get = interoperability, so specifying that
> clients MAY do something really implies (to me) = that server SHOULD (or
> maybe even MUST) be prepared to handle such = packets from clients. If
> the client  can't expect a server to = handle something, there is little
> point in clients implementing the feature = either.
> My general opinion: if its not clear something = is useful, and it's not
> obvious what the details should be, including = the feature distracts
> from the overall goal of getting the spec done. = The more one can
> remove, the fewer details that have to be = gotten right.
> > What we probably should say is that the = client MUST use the
> > multicast address if the interface on = which it is sending the
> > message supports multicast. Otherwise, it = may use the anycast
> > address.
> This is OK with me. Just so long as it's clear = that the anycast usage
> is only link-local and is only for reaching = servers (and relay agents)
> on the same link. This seems like a = straightforward thing to get
> right.
> Thomas
>

------_=_NextPart_001_01C1FA1E.52FE1270-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 22:12:13 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 WAA10543; Sun, 12 May 2002 22:12:13 -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 WAA21770; Sun, 12 May 2002 22:11: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 WAA21696 for ; Sun, 12 May 2002 22:10:58 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10504 for ; Sun, 12 May 2002 22:10:46 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 94BB560CB; Sun, 12 May 2002 22:10:56 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:10:56 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Sun, 12 May 2002 22:10:55 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B0@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: movement detection and Confirm message Thread-Index: AcH5uj4AaEXiABjyQWWcD12h7889+gAaJNhg From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Thomas Narten" , "Ralph Droms" Cc: X-OriginalArrivalTime: 13 May 2002 02:10:56.0700 (UTC) FILETIME=[6AE0C7C0:01C1FA23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA21697 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 Bernie, Please use ascii text. thanks. I did not say that the server could not figure it out like a router does. But a server should not have to be a router. This is new to IPv6 dhcp. What I am saying is that there is no inherent assumption clients can make about addresses from the server as I can for addresses received from stateless router via the prefix advertisements. Not that I should be doing that either but I did. Hence, forcing that as a requirement or benefit to support Confirm is not a valid protocol argument here in a standards forum. An implementation note that it could be done is fine. I just did not want folks to think we had an interoperable wide mechanism to determine this fact. thanks /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Sunday, May 12, 2002 9:38 AM To: Bound, Jim; Thomas Narten; Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Jim: >We have no way as a server to know prefixes so kill #2 as argument. Huh? How could it be set up to provide addresses on a link for which it doesn't know the prefixes? There may well be a "not authoritative" setting (using the ISC DHCP server configuration concepts) that would tell a server it may not have complete information for a link - and in this case the server could not send a "NotOnLink" response to a Confirm. - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Sunday, May 12, 2002 12:58 AM To: Bernie Volz (EUD); Thomas Narten; Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Bernie, We have no way as a server to know prefixes so kill #2 as argument. We CANNOT assume prefix length for any IPv6 address unless the client tells us and it does not now. Nor should it IMO. thanks /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, May 09, 2002 9:24 AM To: 'Thomas Narten'; Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Thomas: My desire for the Confirm would be as follows: - Client can send a Confirm to help in movement detection. It shouldn't be required for the client to do this since it may have other means of doing this. - A server that does implement Confirm handles the message in three ways: 1. If it has the binding for the client and the addresses are valid, it can send a Reply with the success indication. This would be the case if the client hasn't really moved. 2. If it doesn't have a binding but in comparing the addresses provided in the Confirm, the server can determine that the prefixes for the addresses are NOT valid for the link, the server can Reply to the client that the addresses are bad. 3. The server discards the Confirm since it can not verify that the addresses are truely valid for the client. (We could allow another Reply from the server that would indicate to the client that the prefixes appear to be valid, but it can't confirm the actual addresses. However, this isn't really necessary since no response to the Confirm essentially means that and it could give false information at times; that is why it would be best not to have servers do this.) - While I think servers SHOULD implement Confirm, they don't have to. If they don't, they won't enhance movement detection but since there are other mechanisms that can help with this, it is not required. - Confirm processing is much different than a Renew/Rebind. There is much less work involved on the server - it is only verifying the information. A Confirm can NOT be used to extend address lifetimes/leases. IMHO, it should only be used to help the client determine whether it moved. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Thursday, May 09, 2002 9:00 AM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: movement detection and Confirm message > Confirm - client has detected it may have moved, sends > Confirm to any available server to determine > if configuration is still valid > Renew - client unicasts to assigning server to extend > lease on IA > Rebind - client sends to any available server to extend > lease on IA Including the above in the overview would be very helpful. It's not clearly described there, and the above description really helps me to understand why/how the messages differ. > Thomas - rereading your original question, I'm not sure if you're > suggesting that a client not try to detect if it has moved to a new link, > or if it use a Renew instead of a Rebind when it detects it may have moved > to a new link. I believe a client should definitely try to detect when it has moved. What I was wondering about is whether DHC should be specifying *how* it does movement detection (since this is a general topic), and whether DHC should provide explicit mechanisms (beyond other existing message types) that help the client determine if it has moved. Seems to me the Confirm is (maybe?) just an optimization. Couldn't the client just send a Renew to the assigning server? I gather that one advantage of the Confirm is that it is sent to all servers, so one will respond quickly. If the client sends a Renew to a specific server, but the client has moved, the Renew will presumably time out, which takes a lot longer. But in terms of the amount of work a server has to do when processing Confirm vs. Renew, the work is pretty much the same, I would think. I assume that this is the motivation for Confirm. Question: when one sends a confirm, does only the server that has that information respond, or are all servers expected to respond? The text says: > In any situation when a client may have moved to a new link, the > client MUST initiate a Confirm/Reply message exchange. The client > includes any IAs, along with the addresses associated with those IAs, > in its Confirm message. Any responding servers will indicate the > acceptability of the addresses with the status in the Reply message > it returns to the client. But how do other servers know that they are to respond positively? I would expect that only server that originally allocated the addresses to be able to respond positively that the config is valid. Maybe the text isn't explicit enough about what a server does when it gets a Confirm. Does it just check that the addresses are on the link as indicated by the link-address field in the relayed packet? This would be sufficient to verify that client hasn't moved. If it needs to verify that the actual addresses have been assigned it's not clear that any server can do that. This makes me wonder if this is really very much better than just using Renew (if only one server can respond anyway). The text says (under server processing): > If the server finds that the information for the client does not > match what is in the binding for that client or the configuration > information is not valid, the server sends a Reply message containing > a Status Code option with the value ConfNoMatch. I think more text would be good to make it clear that a server can also respond positively even if it can't verify the actual binding. Likewise, a positive response in that case DOSE NOT actually confirm the binding, just that the node hasn't moved. Make sense? > I think from: > >if a client detects that it has > >moved, then just have it redo the normal DHC exchanges. > you mean keep movement detection but use different DHCP messages. Exactly > what did you have in mind for "normal DHCP exchange"? Renew, Rebind and or just restarting with solicit. > The idea behind > Confirm is (as is the case in DHCPv4) if the client has not moved (e.g., > the client has been power cycled), the client uses a two message exchange > with any available server rather than a four message exchange. This assumes that *any* server is in a position to respond definitively. This is not immediately clear to me per above. > Perhaps Confirm overlaps with Rapid Commit? Hmm. 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 dhcwg-admin@ietf.org Sun May 12 22:14: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 WAA10635; Sun, 12 May 2002 22:14: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 WAA21922; Sun, 12 May 2002 22: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 WAA21888 for ; Sun, 12 May 2002 22:13:33 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10621 for ; Sun, 12 May 2002 22:13:20 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 182A270B; Sun, 12 May 2002 22:13:31 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:13:31 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: use of anycast Date: Sun, 12 May 2002 22:13:30 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B1@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: use of anycast Thread-Index: AcH5uqmZmsfzZBhPRi2jGTyBU2Mt/wAaOuFQ From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Thomas Narten" Cc: "Ole Troan" , "Ralph Droms" , X-OriginalArrivalTime: 13 May 2002 02:13:31.0019 (UTC) FILETIME=[C6DBFDB0:01C1FA23] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA21893 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 Bernie, Nope I was stating if I want to know if confirm is multicast I can. Not having an API is a non issue. /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Sunday, May 12, 2002 9:41 AM To: Bound, Jim; Thomas Narten; Bernie Volz (EUD) Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast Jim: Did you mistype here ... "This is not a good argument IMO for confirm."? What does anycast have to do with Confirm (well, the message might need to be anycast in NMBA networks but so would a Solicit, Information-Request, Rebind, ...). - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Sunday, May 12, 2002 12:58 AM To: Thomas Narten; Bernie Volz (EUD) Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast One thing I don't agree with is that its hard to figure out of you have multicast existent on an interface? All of us support some form of sysconf to do that. This is not a good argument IMO for confirm. (I am not against confirm) but to have it because of the API comment is not good). /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Thursday, May 09, 2002 9:23 AM > To: Bernie Volz (EUD) > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: use of anycast > > > > The only issue with this is that DHCP usually runs as an application > > and is therefore only able to access that information which the > > lower layers (via APIs) make available. > > Understood. > > > Determining whether multicast is supported or not is pretty standard > > from the socket API. However, determining that a particular > > interface is a specific media type may be difficult. > > OK. > > > Therefore, there is some value in providing a clear direction here > > that is also relatively easy to implement. > > Agreed. > > > If all interface types provide multicast (either inherently or via > > some type of emulation), there is little need to ever use the > > anycast address and so what harm is there in specifying it. > > The harm is that a) we may define something that isn't useful (which > may cause problems when deployed because some implementations choose > use the feature even if it doesn't work as intended). b) clients may > choose to send to anycast addresses, but if servers aren't configured > to deal with them, we don't get interoperability, so specifying that > clients MAY do something really implies (to me) that server SHOULD (or > maybe even MUST) be prepared to handle such packets from clients. If > the client can't expect a server to handle something, there is little > point in clients implementing the feature either. > > My general opinion: if its not clear something is useful, and it's not > obvious what the details should be, including the feature distracts > from the overall goal of getting the spec done. The more one can > remove, the fewer details that have to be gotten right. > > > What we probably should say is that the client MUST use the > > multicast address if the interface on which it is sending the > > message supports multicast. Otherwise, it may use the anycast > > address. > > This is OK with me. Just so long as it's clear that the anycast usage > is only link-local and is only for reaching servers (and relay agents) > on the same link. This seems like a straightforward thing to get > right. > > 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 dhcwg-admin@ietf.org Sun May 12 22:17: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 WAA10756; Sun, 12 May 2002 22:17: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 WAA22153; Sun, 12 May 2002 22:15: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 WAA22128 for ; Sun, 12 May 2002 22:15:51 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10722 for ; Sun, 12 May 2002 22:15:38 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 580F18BE0; Sun, 12 May 2002 22:15:49 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:15:49 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Date: Sun, 12 May 2002 22:15:48 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B2@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Thread-Index: AcH5u/bNGSexKgScT6WGgT+pnVJTOgAZ+7fg From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Ralph Droms" , X-OriginalArrivalTime: 13 May 2002 02:15:49.0481 (UTC) FILETIME=[19639D90:01C1FA24] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA22129 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 Bernie, Thomas sent the ND paragraph. When reboot set to default and default is stateless ND. Please use ascii text. thanks /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Sunday, May 12, 2002 9:48 AM To: Bound, Jim; Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Jim: Yes, the flag can change from TRUE to FALSE, but the issue is when does stateful configuration stop (sorry I didn't state that more clearly last time): 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. So, once DHCP starts, this kind of implies that it never stops until a reboot of the system occurs. In -24 (17.1.2) we also have: A DHCP client SHOULD choose MRC and MRD to be 0. If the DHCP client is configured with either MRC or MRD set to a value other than 0, it MUST stop trying to configure the interface if the message exchange fails. After the DHCP client stops trying to configure the interface, it SHOULD choose to restart the reconfiguration process after some external event, such as user input, system restart, or when the client is attached to a new link. So, if a client follows the SHOULD it would keep running the process. I guess one could assume that the client should stop transmitting Solicits if the ManagedFlag is false. - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Sunday, May 12, 2002 12:58 AM To: Bernie Volz (EUD); Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Bernie, It could be reset by RA to FALSE fyi. /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, May 08, 2002 9:45 PM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Yes, that is my assumption - that the host has to wait for an RA. The Stateless Autoconfiguration RFC doesn't state this explicitly and also doesn't cover the case of a moving client (at least that I could find). It seems to me that if a host follows that specification, once the ManagedFlag is set to TRUE the only way it can ever be set to FALSE is via a reboot of the host. There always is the possibility that a host's policy could force the ManagedFlag to be TRUE always? Though why you'd want to do this is not clear to me. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, May 08, 2002 7:38 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: randomization delay before invoking DHC Thomas comment (below) raised a question in my mind. Is the state of the managedFlag always go to FALSE or is it maintained across systems restarts? That is, does a host always come up in stateless mode and then switch to stateful upon receipt of the first RA. If the client does always come up in stateless mode, does the following text cause the first Solicit to be delayed until at least the receipt of the first RA? 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). At 11:00 AM 5/8/2002 -0400, Thomas Narten wrote: >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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 22:23:15 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 WAA10917; Sun, 12 May 2002 22:23: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 WAA22400; Sun, 12 May 2002 22:22: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 WAA22375 for ; Sun, 12 May 2002 22:22:33 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10889 for ; Sun, 12 May 2002 22:22:17 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id B6B712514; Sun, 12 May 2002 22:22:27 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:22:27 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Sun, 12 May 2002 22:22:26 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B3@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: movement detection and Confirm message Thread-Index: AcH5vCnBk6OXEXITQJuxW8RIWRUsQQAaAm4w From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Thomas Narten" Cc: X-OriginalArrivalTime: 13 May 2002 02:22:27.0590 (UTC) FILETIME=[06AE3A60:01C1FA25] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA22378 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 Bernie, ******************************** But a Renew is only directed to the one server and it is down or not on the network, the client gets no response. What should it do? ******************************** Go look for another server and use the addresses as long as it can. Confirm should not have been used to detect movement as Thomas stated. What I am saying is Renew could be a hint. If a response comes back all is golden. But putting into the protocol that this works for that case is not ideal. ********************************** If it gets a Reply, it does know it is on the same network as before. *************************** Or the server was smart enough to give it a new prefix was where I was going and then the node could have gone to a different link. This requires no change to the spec. ****************************** If it gets no Reply, it knows only that it may not be on the same network OR that the original server is down. **************************** I see no advantage here over Renew and in fact disadvantage per Renew giving the client new addresses with new prefixes for that link. regards, /jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 22:23: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 WAA10978; Sun, 12 May 2002 22:23:56 -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 WAA22449; Sun, 12 May 2002 22:23: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 WAA22426 for ; Sun, 12 May 2002 22:23:19 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10914 for ; Sun, 12 May 2002 22:23:06 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 3CF428C96; Sun, 12 May 2002 22:23:17 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:23:17 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Sun, 12 May 2002 22:23:16 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B4@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: movement detection and Confirm message Thread-Index: AcH5w7FkxvUhNJlkSHSFZMdLnjcCagAYWqaQ From: "Bound, Jim" To: "Ted Lemon" Cc: , "Ralph Droms" , "Thomas Narten" , "Bernie Volz (EUD)" X-OriginalArrivalTime: 13 May 2002 02:23:17.0125 (UTC) FILETIME=[2434AB50:01C1FA25] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA22427 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 I agree. /jim > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Sunday, May 12, 2002 10:46 AM > To: Bound, Jim > Cc: dhcwg@ietf.org; Ralph Droms; Thomas Narten; Bernie Volz (EUD) > Subject: Re: [dhcwg] dhcpv6-24: movement detection and > Confirm message > > > The server administrator will likely configure the DHCP > server to know what > the prefix lengths are for the subnets it serves, so in fact > it will know > prefix lengths, and we can use them. We shouldn't require > the use of them > in all cases, because the server administrator might _not_ > configure the > DHCP server with a complete list, but we can specify what to > do if the DHCP > server has them, and this will be of genuine use in real-world > installations. > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 22:24: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 WAA11067; Sun, 12 May 2002 22:24:54 -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 WAA22541; Sun, 12 May 2002 22:24:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA22525 for ; Sun, 12 May 2002 22:24:25 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11031 for ; Sun, 12 May 2002 22:24:13 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 113478C96; Sun, 12 May 2002 22:24:24 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:24:24 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: movement detection and Confirm message Date: Sun, 12 May 2002 22:24:23 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B5@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: movement detection and Confirm message Thread-Index: AcH5w9rROzZeUDguSiKJjdPq0c7ZqQAYU5hg From: "Bound, Jim" To: "Ted Lemon" , "Bernie Volz (EUD)" Cc: "Thomas Narten" , "Ralph Droms" , X-OriginalArrivalTime: 13 May 2002 02:24:24.0184 (UTC) FILETIME=[4C2D0F80:01C1FA25] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA22526 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 but not with the qualifcation that you and I did. Also this cannot be specified for CORRECT dhcp protocol operation just a hint in the spec. /jim > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Sunday, May 12, 2002 10:47 AM > To: Bernie Volz (EUD) > Cc: Bound, Jim; Thomas Narten; Ralph Droms; dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: movement detection and > Confirm message > > > > Huh? How could it be set up to provide addresses on a link > for which it > > doesn't know the prefixes? There may well be a "not > authoritative" setting > > (using the ISC DHCP server configuration concepts) that > would tell a > > server it may not have complete information for a link - > and in this case > > the server could not send a "NotOnLink" response to a Confirm. > > Right. Bernie put this much better than I did in my > previous message. > :'} > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 22:29:43 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 WAA11243; Sun, 12 May 2002 22:29: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 WAA22707; Sun, 12 May 2002 22:28: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 WAA22689 for ; Sun, 12 May 2002 22:28:53 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11207 for ; Sun, 12 May 2002 22:28:40 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id 247CB8E2A; Sun, 12 May 2002 22:28:51 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:28:51 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: use of anycast Date: Sun, 12 May 2002 22:28:50 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B6@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: use of anycast Thread-Index: AcH51GVW9wtl6XIlTU6DuiIRaDaVKAAUTZPg From: "Bound, Jim" To: "Ralph Droms" Cc: "Bernie Volz (EUD)" , "Thomas Narten" , "Ole Troan" , X-OriginalArrivalTime: 13 May 2002 02:28:51.0029 (UTC) FILETIME=[EB3A6050:01C1FA25] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA22690 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 Ralph, I don't believe we have any but will check for well known unicast. But why not use well known multicast address on the link. We do that today. Either way it does not break any API or implementation. But using multicast there is well known way to join that group and we just say what it is reserved for? Good idea. regards, /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Sunday, May 12, 2002 12:45 PM > To: Bound, Jim > Cc: Bernie Volz (EUD); Thomas Narten; Ole Troan; dhcwg@ietf.org > Subject: RE: [dhcwg] dhcpv6-24: use of anycast > > > > Jim makes a good good point about anycast. Given the current > discussion about anycast addresses and hosts on the ipngwg mailing > list, it would be premature to specify site-local anycast for DHCPv6. > > What about link-local only "anycast" - perhaps that's not really > "anycast" because there's no routing? > > Instead of an anycast address, suppose we request the reservation of a > link-scoped unicast address for DHCP? If we use a unicast > address, only > one relay agent or server on a link can be listening on that address, > right? For point-to-point links that's not a problem - there > can only be > one relay agent or server at the other end of the point-to-point link. > I'm still not clear about multiple-access links and multicast - are > there any multiple access link technologies that don't > provide or emulate > multicast? > > Is there a precedent for the reservation of a link-scoped, well-known > unicast address? > > Using a link-scoped unicast address, the first relay agent or > server to > bind to the address gets to use it. I'm not familiar with > the IPv6 API; > I assume that an application (with sufficient privilege) can make a > request to assign a specific address to an interface. I > guess the stack > does DAD on the requested address and the request fails if > the address is > already in use? > > I'm not thrilled with my idea - it sounds fairly ugly. Does > it break or > bend fewer existing standards, or require the definition of fewer new > standards than the use of an anycast address? Does the > assignment of a > well-known link-scoped unicast address for DHCP set a precedent we'd > rather not set? > > The use of the unicast address could be further discouraged > by including a > restriction that relay agents and servers MUST NOT listen on > the unicast > address and clients MUST NOT send messages to the unicast address on a > link that supports multicast. > > - Ralph > > On Sun, 12 May 2002, Bound, Jim wrote: > > > Thomas, > > > > I am fine with this too. But what we are permitting the > server to have an anycast address and the addr arch says > don't do this? Will it not be kicked back again by the IESG > because we did that? > > > > thanks > > /jim > > > > -----Original Message----- > > From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > > Sent: Thursday, May 09, 2002 9:27 AM > > To: 'Thomas Narten'; Bernie Volz (EUD) > > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > > Subject: RE: [dhcwg] dhcpv6-24: use of anycast > > > > > > >> What we probably should say is that the client MUST use the > > >> multicast address if the interface on which it is sending the > > >> message supports multicast. Otherwise, it may use the anycast > > >> address. > > > > > >This is OK with me. Just so long as it's clear that the > anycast usage > > >is only link-local and is only for reaching servers (and > relay agents) > > >on the same link. This seems like a straightforward thing to get > > >right. > > Sounds fine to me. > > - Bernie > > -----Original Message----- > > From: Thomas Narten [mailto:narten@us.ibm.com] > > Sent: Thursday, May 09, 2002 9:23 AM > > To: Bernie Volz (EUD) > > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > > Subject: Re: [dhcwg] dhcpv6-24: use of anycast > > > > > > > The only issue with this is that DHCP usually runs as an > application > > > and is therefore only able to access that information which the > > > lower layers (via APIs) make available. > > Understood. > > > Determining whether multicast is supported or not is > pretty standard > > > from the socket API. However, determining that a particular > > > interface is a specific media type may be difficult. > > OK. > > > Therefore, there is some value in providing a clear direction here > > > that is also relatively easy to implement. > > Agreed. > > > If all interface types provide multicast (either inherently or via > > > some type of emulation), there is little need to ever use the > > > anycast address and so what harm is there in specifying it. > > The harm is that a) we may define something that isn't useful (which > > may cause problems when deployed because some implementations choose > > use the feature even if it doesn't work as intended). b) clients may > > choose to send to anycast addresses, but if servers aren't > configured > > to deal with them, we don't get interoperability, so specifying that > > clients MAY do something really implies (to me) that server > SHOULD (or > > maybe even MUST) be prepared to handle such packets from clients. If > > the client can't expect a server to handle something, > there is little > > point in clients implementing the feature either. > > My general opinion: if its not clear something is useful, > and it's not > > obvious what the details should be, including the feature distracts > > from the overall goal of getting the spec done. The more one can > > remove, the fewer details that have to be gotten right. > > > What we probably should say is that the client MUST use the > > > multicast address if the interface on which it is sending the > > > message supports multicast. Otherwise, it may use the anycast > > > address. > > This is OK with me. Just so long as it's clear that the > anycast usage > > is only link-local and is only for reaching servers (and > relay agents) > > on the same link. This seems like a straightforward thing to get > > right. > > Thomas > > > > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 12 22:35:44 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 WAA12382; Sun, 12 May 2002 22:35: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 WAA23447; Sun, 12 May 2002 22:35:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA23424 for ; Sun, 12 May 2002 22:35:23 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12357 for ; Sun, 12 May 2002 22:35:11 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id E6F412708; Sun, 12 May 2002 22:35:21 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Sun, 12 May 2002 22:35:22 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: use of anycast Date: Sun, 12 May 2002 22:35:21 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B85B7@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: use of anycast Thread-Index: AcH6Hlb2S3qn8XSlTOuM/HeV6p8tGQAB56Ww From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Ralph Droms" Cc: "Thomas Narten" , "Ole Troan" , X-OriginalArrivalTime: 13 May 2002 02:35:22.0043 (UTC) FILETIME=[D44A60B0:01C1FA26] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id WAA23425 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 Bernie, ************************************* I don't think the link-scoped unicast address is a good idea. What would the prefix for this be? If it is the standard link-local prefix, what about all the hosts today that don't have code to check for this value. ************************************** The client dhcpv6 code only needs know the address. It does not affect IPv6 networking implementations at all. And even if it was anycast thats handled by mgmt interface for the address set. ************************************* I think we're best left with letting this issue be resolved by the first link that needs it (as Thomas originally suggested). ************************************** I agree with Thomas if anycast is used just use the first listner. But we have an issue maybe and do with anycast right now. What Ralph proposes works with well-known-unicast, anycast, or well-known-multicast as I suggested. And it don't break anything. ********************************************* So, perhaps we should simply say: "If the link supports multicast, the multicast address MUST be used. Otherwise, the link over IPv6 specification needs to specify what the DHCP Client must use." ********************************** I don't agree Ralphs suggestion is more clear, easy to implement, and fits the IPv6 architecture well. thanks /jim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 13 10:59: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 KAA14305; Mon, 13 May 2002 10:59: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 KAA06776; Mon, 13 May 2002 10:56:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA06748 for ; Mon, 13 May 2002 10:56:06 -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 KAA14033 for ; Mon, 13 May 2002 10:55:55 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-174.cisco.com [10.82.224.174]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA27863; Mon, 13 May 2002 10:55:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20020511064013.0311acc0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 May 2002 10:37:09 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [dhcwg] some comments and questions on dhcpv6-24 Cc: dhcwg@ietf.org In-Reply-To: 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 Thanks for your review - I apologize for the delay in replying, and we'll take your comments into account when we edit the next rev of the draft. - Ralph At 05:24 PM 4/26/2002 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: >I have some comments and questions on the latest I-D of DHCPv6, >draft-ietf-dhc-dhcpv6-24.txt. > >15.10. Reply message > > Clients MUST discard any received Reply messages that meet any of the > following conditions: > > - the message does not include a Server Identifier option > > - the "transaction-ID" field in the message does not match the > value used in the original message > > - the message does not include a Client Identifier option and the > original message from the client contained a Client Identifier > option > > - the message includes a Client Identifier option and the contents > of the Client Identifier option does not match the DUID of the > client > >What if the message includes a Client Identifier option but the client >did not send the option in the corresponding request? The message should be rejected if it includes a Client Identifier option and the client did not include the option in its original message. >17.2.2. Creation and transmission of Advertise messages > > ... The Advertise message MUST > be unicast through the interface on which the Solicit message was > received. > >It seems to me the requirement is too strong. Is this really >necessary? It's necessary if the server received the Solicit directly from the client; i.e., if the server and the client are on the same link and the server is sending the Advertise to the client's link-local address. >18.2.5. Receipt of Information-request messages > > The server contructs a Reply message by setting the "msg-type" field > ^^^^^^^^^this should be "constructs". There are many >other "contructs" in the draft. This problem was fixed between preliminary publication of the -24 rev and the final version published at the IETF. > to REPLY, copying the transaction ID from the Rebind message into the > ^^^^^^ > transaction-ID field. > >Should the "Rebind" message be "Information-request"? This sentence >seems to be just copied from the previous section... This problem was fixed between preliminary publication of the -24 rev and the final version published at the IETF. > The server MUST include a Server Identifier option containing the > server's DUID and the Client Identifier option from the Rebind > ^^^^^^ > message in the Reply message. > >Again, should the "Rebind" be "Information-request"? This problem was fixed between preliminary publication of the -24 rev and the final version published at the IETF. >Other questions to this section: > - what should the receiving server do if the Information-request > contains a client Identifier option? I think the server MUST > copy the option to the reply, but the draft does not mention this > case. Yes, we should make that clarification. > - what should the receiving server do if the Information-request > contains an IA option? Section 18.1.5 says that: > The client MUST NOT include any IA options. > But none of this section and Section 15.12 mention this case. We will add text clarifying that an Information-request containing IA options is discarded. >BTW: there seem to me several cases for this type of incompleteness. >For example, Section 22.6 says "The IA Address option must be >encapsulated in the Options field of an Identity Association option." >But I'm not sure what a node should do when it receives an IA address >option not encapsulated in an IA option. I've not gone through the >entire draft, so I may miss something, and if so, I'd apologize in >advance. If my guess is correct, however, then I'd suggest to check >the consistency of the requirements over the entire draft. OK, we'll make that consistency check. > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 13 17:05:10 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 RAA03236; Mon, 13 May 2002 17:05:10 -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 FAA21391; Mon, 13 May 2002 05:50:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA14711 for ; Mon, 13 May 2002 03:57:09 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00018 for ; Mon, 13 May 2002 03:56:58 -0400 (EDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4D7v7874070 for ; Mon, 13 May 2002 16:57:07 +0900 (JST) Date: Mon, 13 May 2002 16:57:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org In-Reply-To: References: User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 21 Subject: [dhcwg] Re: comments and qeustions on dhcpv6-24 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 Mon, 13 May 2002 16:02:06 +0900, >>>>> JINMEI Tatuya said: > I've just gone thorough dhcpv6-24, and have some comments and > questions on it. I forgot to add one last (editorial) comment: Section 25.6 contains unnecessary slash characters: UseMulticast 7 Sent by a server to a client to force the client to send messages to the server using the All\_DHCP\_Relay\_Agents\_and\_Servers address This should be just "All_DHCP_Relay_Agents_and_Servers". JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 13 17:13: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 RAA03722; Mon, 13 May 2002 17:13: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 HAA26344; Mon, 13 May 2002 07:34:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26283 for ; Mon, 13 May 2002 07:33:57 -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 HAA03557; Mon, 13 May 2002 07:33:43 -0400 (EDT) Message-Id: <200205131133.HAA03557@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 13 May 2002 07:33:42 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-timeconfig-01.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 : Time Configuration Options for DHCPv6 Author(s) : A. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt Pages : 6 Date : 10-May-02 This document describes the options for Time related configuration information in DHCPv6: NTP Servers and IEEE 1003.1 POSIX Timezone specifier. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020510124104.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020510124104.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 13 17:15:55 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 RAA03883; Mon, 13 May 2002 17:15: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 HAA26315; Mon, 13 May 2002 07:33:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA26253 for ; Mon, 13 May 2002 07:33:53 -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 HAA03536; Mon, 13 May 2002 07:33:39 -0400 (EDT) Message-Id: <200205131133.HAA03536@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 13 May 2002 07:33:39 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-nisconfig-01.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 : NIS Configuration Options for DHCPv6 Author(s) : A. Vijayabhaskar Filename : draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Pages : 6 Date : 10-May-02 This document describes four options for NIS-related configuration information in DHCPv6: NIS Servers, NIS+ Servers, NIS Client Domain Name, NIS+ Client Domain name. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020510124054.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020510124054.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 13 17:18: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 RAA04084; Mon, 13 May 2002 17:18: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 GAA23739; Mon, 13 May 2002 06:37:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA23702 for ; Mon, 13 May 2002 06:37:07 -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 GAA02284 for ; Mon, 13 May 2002 06:36:55 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-39.cisco.com [10.82.224.39]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA14274; Mon, 13 May 2002 06:36:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20020513063120.00b5e198@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 May 2002 06:36:20 -0400 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] dhcpv6-24: use of anycast Cc: "Bound, Jim" , Thomas Narten , Ole Troan , dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D3EF@EAMBUNT705> 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 Bernie - I'm not sure the link-scoped unicast address is such a good idea, either. However, I do have some comments about your concerns (in line)... - Ralph At 08:34 PM 5/12/2002 -0500, Bernie Volz (EUD) wrote: >Ralph: > >I don't think the link-scoped unicast address is a good idea. What would >the prefix for this be? The standard link-local prefix > If it is the standard link-local prefix, what about all the hosts today > that don't have code to check for this value. There's no need to check for this reserved value - the IPv6 stack will do normal DAD. I don't think the stack has to know about the use of the reserved address for DHCPv6 - just DHCPv6 applications need to know. >I think we're best left with letting this issue be resolved by the first >link that needs it (as Thomas originally suggested). That's OK - except for those link technologies that are already defined? Or, do we go ahead with DHCPv6 and make a note that existing "IPv6 over X" docs should review the need for special handling for DHCPv6? >So, perhaps we should simply say: > >"If the link supports multicast, the multicast address MUST be used. >Otherwise, the link over IPv6 specification needs to specify what the DHCP >Client must use." > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Sunday, May 12, 2002 12:45 PM >To: Bound, Jim >Cc: Bernie Volz (EUD); Thomas Narten; Ole Troan; dhcwg@ietf.org >Subject: RE: [dhcwg] dhcpv6-24: use of anycast > > >Jim makes a good good point about anycast. Given the current >discussion about anycast addresses and hosts on the ipngwg mailing >list, it would be premature to specify site-local anycast for DHCPv6. > >What about link-local only "anycast" - perhaps that's not really >"anycast" because there's no routing? > >Instead of an anycast address, suppose we request the reservation of a >link-scoped unicast address for DHCP? If we use a unicast address, only >one relay agent or server on a link can be listening on that address, >right? For point-to-point links that's not a problem - there can only be >one relay agent or server at the other end of the point-to-point link. >I'm still not clear about multiple-access links and multicast - are >there any multiple access link technologies that don't provide or emulate >multicast? > >Is there a precedent for the reservation of a link-scoped, well-known >unicast address? > >Using a link-scoped unicast address, the first relay agent or server to >bind to the address gets to use it. I'm not familiar with the IPv6 API; >I assume that an application (with sufficient privilege) can make a >request to assign a specific address to an interface. I guess the stack >does DAD on the requested address and the request fails if the address is >already in use? > >I'm not thrilled with my idea - it sounds fairly ugly. Does it break or >bend fewer existing standards, or require the definition of fewer new >standards than the use of an anycast address? Does the assignment of a >well-known link-scoped unicast address for DHCP set a precedent we'd >rather not set? > >The use of the unicast address could be further discouraged by including a >restriction that relay agents and servers MUST NOT listen on the unicast >address and clients MUST NOT send messages to the unicast address on a >link that supports multicast. > >- Ralph > > On Sun, 12 May 2002, Bound, Jim wrote: > > > Thomas, > > > > I am fine with this too. But what we are permitting the server to have > an anycast address and the addr arch says don't do this? Will it not be > kicked back again by the IESG because we did that? > > > > > thanks > > /jim > > > > -----Original Message----- > > From: Bernie Volz (EUD) > [mailto:Bernie.Volz@am1.ericsson.se] > > Sent: Thursday, May 09, 2002 9:27 AM > > To: 'Thomas Narten'; Bernie Volz (EUD) > > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > > Subject: RE: [dhcwg] dhcpv6-24: use of anycast > > > > > > >> What we probably should say is that the client MUST use the > > >> multicast address if the interface on which it is sending the > > >> message supports multicast. Otherwise, it may use the anycast > > >> address. > > > > > >This is OK with me. Just so long as it's clear that the anycast usage > > >is only link-local and is only for reaching servers (and relay agents) > > >on the same link. This seems like a straightforward thing to get > > >right. > > Sounds fine to me. > > - Bernie > > -----Original Message----- > > From: Thomas Narten [mailto:narten@us.ibm.com] > > Sent: Thursday, May 09, 2002 9:23 AM > > To: Bernie Volz (EUD) > > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > > Subject: Re: [dhcwg] dhcpv6-24: use of anycast > > > > > > > The only issue with this is that DHCP usually runs as an application > > > and is therefore only able to access that information which the > > > lower layers (via APIs) make available. > > Understood. > > > Determining whether multicast is supported or not is pretty standard > > > from the socket API. However, determining that a particular > > > interface is a specific media type may be difficult. > > OK. > > > Therefore, there is some value in providing a clear direction here > > > that is also relatively easy to implement. > > Agreed. > > > If all interface types provide multicast (either inherently or via > > > some type of emulation), there is little need to ever use the > > > anycast address and so what harm is there in specifying it. > > The harm is that a) we may define something that isn't useful (which > > may cause problems when deployed because some implementations choose > > use the feature even if it doesn't work as intended). b) clients may > > choose to send to anycast addresses, but if servers aren't configured > > to deal with them, we don't get interoperability, so specifying that > > clients MAY do something really implies (to me) that server SHOULD (or > > maybe even MUST) be prepared to handle such packets from clients. If > > the client can't expect a server to handle something, there is little > > point in clients implementing the feature either. > > My general opinion: if its not clear something is useful, and it's not > > obvious what the details should be, including the feature distracts > > from the overall goal of getting the spec done. The more one can > > remove, the fewer details that have to be gotten right. > > > What we probably should say is that the client MUST use the > > > multicast address if the interface on which it is sending the > > > message supports multicast. Otherwise, it may use the anycast > > > address. > > This is OK with me. Just so long as it's clear that the anycast usage > > is only link-local and is only for reaching servers (and relay agents) > > on the same link. This seems like a straightforward thing to get > > right. > > Thomas > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 13 17:20: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 RAA04230; Mon, 13 May 2002 17:20: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 FAA21363; Mon, 13 May 2002 05:50: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 DAA12428 for ; Mon, 13 May 2002 03:01:40 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29323 for ; Mon, 13 May 2002 03:01:25 -0400 (EDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4D71U873513 for ; Mon, 13 May 2002 16:01:30 +0900 (JST) Date: Mon, 13 May 2002 16:02:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 265 Subject: [dhcwg] comments and qeustions on dhcpv6-24 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 just gone thorough dhcpv6-24, and have some comments and questions on it. Since most of them are just for clarification or editorial comments, I've put all of them into this message. If we need to discuss some of them separately, please make another thread for the particular items. I've also checked recent discussions on the list based on comments from Thomas and tried to avoid duplicated comments (actually I have one.) I'd apologize in advance, if there is still any duplication. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp 1. Section 4.1. defines binding A binding (or, client binding) is a group of server data records containing the information the server has about the addresses in an IA and any other configuration information assigned to the client. A binding is indexed by the tuple (where IA-type is the type of address in the IA; for example, temporary) Is it always appropriate to contain "IA-TYPE" and "IAID" in the index of a binding? What if a configuration information (that needs a binding) is not associated with an IA? An IPv6 prefix delegated by DHCPv6 can be an example of such binding. 2. Section 15.13. says Clients MUST discard any received Relay-forward messages. What if a relay agent receives a relay-forward message? 3. Section 16. repeatedly says like 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,... I think requiring the client to use an address on the particular "interface" is too strong (though it should be the typical case). The source address MUST be on the "link" to which the interface being configured belongs, since the server may use the information to detect the client's link, but does not necessarily have to be on the exact interface. Using the term "link" instead of "interface" is also consistent with the last paragraph of this section. Also, I don't get why the "default address selection" draft is cited here. If this is just because the draft describes the generic mechanism to select source addresses, I don't think we need to cite it explicitly here. 4. Section 17.1. says A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. The wording is too specific. Since the client may just need other information than addresses, the text should be like "DHCP servers configured to server addresses or other configuration parameters...". 5. Section 17.1.1. says The client MAY include options with data values as hints to the server about parameter values the client would like to have returned. I'm not sure how the data values are specified. An option request option can only specify required option "types"... The same comments applies to Sections 18.1.1 and 18.1.5. 6. Section 17.1.3 says The client MUST ignore any Advertise message that includes a Status Code option containing the value AddrUnavail, with the exception that the client MAY display the associated status message to the user. and Section 17.2.2 has a corresponding text: If the server will not assign any addresses to IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a status code option with the status code set to AddrUnavail and a status message for the user. With the specification, it seems to me that a client cannot configure itself without getting addresses (except via information-request and reply exchanges). For example, suppose that a client wants to be delegated an IPv6 prefix from a provider, and sends a solicit without any IA option. The server is configured to delegate prefixes only (i.e. not addresses), so it sends an Advertise message with an AddrUnavail code. Since the client MUST ignore the advertise message, it cannot proceed any more. So, the specification should be clearer on the procedure when a client does not need addresses. 7. What if a reply message for a solicit with a rapid commit option does *not* contain a rapid commit option? Section 17.2.3 says that the server includes a Rapid Commit option in the Reply message, but Section 17.1.4 says nothing about the case if the rapid commit option is not included. 8. It is not very clear when a server includes a Server Unicast option. Section 18.1.1 (and some succeeding sections) says Use of multicast or anycast on a link and relay agents enables the inclusion of relay agent options in all messages sent by the client. The server should enable the use of unicast only when relay agent options will not be used. But, this only talks about some restrictions of including the option. Even with the text of section 22.13, I'm still not sure when a server should or can send a Server Unicast option. It would be better to describe the allowed (or necessary) cases explicitly. 9. (I've once pointed it out, but I'll do it again) Section 17.2.2 says If the Solicit message was received directly by the server,...The Advertise message MUST be unicast through the interface on which the Solicit message was received. Technically, the requirement is too strong, since links are larger than interfaces according to the IPv6 scoped address architecture. So, more accurately, it should say "The Advertise message MUST be unicast through the link on which the Solicit message was received." (Also see the last paragraph of Section 16.) 10. Section 18.2.1 says When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a status code option with value UseMulticast and no other options. I'm not sure how the client should act when it receives the reply message. Should it resend the request to multicast? Should it restart the entire procedure from the solicit? At least Section 18.1.6 should mention this case. The same comment applies to Sections 18.2.3, 18.2.6, and 18.2.7. 11. Section 18.2.6 says "The server ignores invalid addresses." What does "invalid" exactly mean? In particular, I'm not sure if the source address of the receipt message is "invalid" or not (note that section 18.1.7 prohibits the client to use addresses being released as the source address). The text should clearly define the term "invalid". The same comment applies to Section 18.2.7. 12. Section 19.1.1 says "The server sets the transaction-id field to 0". But I could not found description about the case where the client receives a reconfigure message with a non-0 transaction-id. Should it discard the message, or should it ignore the non-0 value, or others? 13. Why doesn't the timeout and retransmission rule in Section 19.1.2 follow the general rules described in Section 14? Is there something special for reconfigure messages? 14. In the first sentence of Section 19.3 A client MUST accept Reconfigure messages sent to UDP port 546on... we need a white space after "546". 15. What if a client receives a reconfigure message but none of the configuration information was provided by the server (that sends the reconfigure)? What if only a part of the configuration information was provided by the server? Section 19.3.1 is not clear (enough) about the cases. 16. (Relevant to the comment 12 above) Section 19.3.1 says the client ignores any additional Reconfigure messages (regardless of the transaction ID in the Reconfigure message) until the exchange is complete. Subsequent Reconfigure messages (again independent of the transaction ID) cause the client to initiate a new exchange. But, according to Section 19.1.1, the transaction ID should always be 0. So I don't get the rationale about the wording here. Does this simply mean the client should always ignore the transaction-ID? If so, it seems to me more natural to say so explicitly. 17. Section 21.5.2 says A DHCP message MUST NOT contain more than one Authentication option when using the delayed authentication protocol. Then, what if a received message contains more than one Authentication option? Ignore the entire message, ignore the authentication options (but a particular one), or others? (an editorial comment) we need some additional white space in this paragraph: ... in the DHCP message to facilitate processing of the authentication information.The format of the Authentication... after "information". 18. Section 21.5.3 says receiver computes the MAC as described in [9]. The entire DHCP message (except the MAC field of the authentication option itself), is used as input to the HMAC-MDS computation function. This is not very clear to me. Does this mean we should regard the MAC field as an all-0 field when computation? 19. We need a closing parenthesis in the first sentence of Section 21.5.5.4: If the server has selected a key for the client in a previous message exchange (see section 21.5.6.1, the client MUST use the same key to generate the authentication information. The appropriate point should be after "21.5.6.1". 20. Section 22.5 says An identity association for temporary addresses option MUST NOT appear in a Renew or Rebind message. What should the receiving node do if this condition is broken? 21. Section 22.14 specifies to use a UTF-8 encoded text string, but it seems to me too much. I think a simple ascii text is enough. (However, this may be based on a consensus of a former discussion, and if so, I don't oppose to the result.) 22. Section 22.17 says A DHCP message MUST NOT contain more than one Vendor Class option. What should the receiving node do if this condition is broken? 23. Section 22.18 says A DHCP message MUST NOT contain more than one Vendor-specific Information option with the same Enterprise Number. What should the receiving node do if this condition is broken? 24. Section 22.19 says This option MUST NOT appear in any message except a Relay-Forward or Relay-Reply message. What should the receiving node do if this condition is broken? (This question should be extended in a general form; "what should the receiving node do if an option is included in a message in which the option MUST NOT be appeared?") _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 13 17:21:27 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 RAA04291; Mon, 13 May 2002 17:21: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 JAA00441; Mon, 13 May 2002 09:00: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 JAA00364 for ; Mon, 13 May 2002 09:00:10 -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 IAA07649 for ; Mon, 13 May 2002 08:59:57 -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 g4DCxdi21514 for ; Mon, 13 May 2002 07:59:39 -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 g4DCxdv03369 for ; Mon, 13 May 2002 07:59:39 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon May 13 07:59:36 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 07:59:36 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D3F3@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" Cc: "Bound, Jim" , Thomas Narten , Ole Troan , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast Date: Mon, 13 May 2002 07:59:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FA7E.080F0570" 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_01C1FA7E.080F0570 Content-Type: text/plain; charset="iso-8859-1" Ralph: >There's no need to check for this reserved value - the IPv6 stack will do >normal DAD. I don't think the stack has to know about the use of the >reserved address for DHCPv6 - just DHCPv6 applications need to know. What happens if a client starts up before the DHCP server (or DAD fails to work because of temporary network issues) and uses this "reserved value"? In that case, the DHCP server can't run on that address and hence you don't have DHCP service. Again, I think this is a bad idea. >That's OK - except for those link technologies that are already >defined? Or, do we go ahead with DHCPv6 and make a note that existing >"IPv6 over X" docs should review the need for special handling for DHCPv6? I could be wrong, but as Thomas pointed out the existing technologies do have multicast solutions and they'd have an issue if they don't support multicast since ND (and DAD) wouldn't work if they don't provide it. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, May 13, 2002 6:36 AM To: Bernie Volz (EUD) Cc: Bound, Jim; Thomas Narten; Ole Troan; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: use of anycast Bernie - I'm not sure the link-scoped unicast address is such a good idea, either. However, I do have some comments about your concerns (in line)... - Ralph At 08:34 PM 5/12/2002 -0500, Bernie Volz (EUD) wrote: >Ralph: > >I don't think the link-scoped unicast address is a good idea. What would >the prefix for this be? The standard link-local prefix > If it is the standard link-local prefix, what about all the hosts today > that don't have code to check for this value. There's no need to check for this reserved value - the IPv6 stack will do normal DAD. I don't think the stack has to know about the use of the reserved address for DHCPv6 - just DHCPv6 applications need to know. >I think we're best left with letting this issue be resolved by the first >link that needs it (as Thomas originally suggested). That's OK - except for those link technologies that are already defined? Or, do we go ahead with DHCPv6 and make a note that existing "IPv6 over X" docs should review the need for special handling for DHCPv6? >So, perhaps we should simply say: > >"If the link supports multicast, the multicast address MUST be used. >Otherwise, the link over IPv6 specification needs to specify what the DHCP >Client must use." > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Sunday, May 12, 2002 12:45 PM >To: Bound, Jim >Cc: Bernie Volz (EUD); Thomas Narten; Ole Troan; dhcwg@ietf.org >Subject: RE: [dhcwg] dhcpv6-24: use of anycast > > >Jim makes a good good point about anycast. Given the current >discussion about anycast addresses and hosts on the ipngwg mailing >list, it would be premature to specify site-local anycast for DHCPv6. > >What about link-local only "anycast" - perhaps that's not really >"anycast" because there's no routing? > >Instead of an anycast address, suppose we request the reservation of a >link-scoped unicast address for DHCP? If we use a unicast address, only >one relay agent or server on a link can be listening on that address, >right? For point-to-point links that's not a problem - there can only be >one relay agent or server at the other end of the point-to-point link. >I'm still not clear about multiple-access links and multicast - are >there any multiple access link technologies that don't provide or emulate >multicast? > >Is there a precedent for the reservation of a link-scoped, well-known >unicast address? > >Using a link-scoped unicast address, the first relay agent or server to >bind to the address gets to use it. I'm not familiar with the IPv6 API; >I assume that an application (with sufficient privilege) can make a >request to assign a specific address to an interface. I guess the stack >does DAD on the requested address and the request fails if the address is >already in use? > >I'm not thrilled with my idea - it sounds fairly ugly. Does it break or >bend fewer existing standards, or require the definition of fewer new >standards than the use of an anycast address? Does the assignment of a >well-known link-scoped unicast address for DHCP set a precedent we'd >rather not set? > >The use of the unicast address could be further discouraged by including a >restriction that relay agents and servers MUST NOT listen on the unicast >address and clients MUST NOT send messages to the unicast address on a >link that supports multicast. > >- Ralph > > On Sun, 12 May 2002, Bound, Jim wrote: > > > Thomas, > > > > I am fine with this too. But what we are permitting the server to have > an anycast address and the addr arch says don't do this? Will it not be > kicked back again by the IESG because we did that? > > > > > thanks > > /jim > > > > -----Original Message----- > > From: Bernie Volz (EUD) > [mailto:Bernie.Volz@am1.ericsson.se] > > Sent: Thursday, May 09, 2002 9:27 AM > > To: 'Thomas Narten'; Bernie Volz (EUD) > > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > > Subject: RE: [dhcwg] dhcpv6-24: use of anycast > > > > > > >> What we probably should say is that the client MUST use the > > >> multicast address if the interface on which it is sending the > > >> message supports multicast. Otherwise, it may use the anycast > > >> address. > > > > > >This is OK with me. Just so long as it's clear that the anycast usage > > >is only link-local and is only for reaching servers (and relay agents) > > >on the same link. This seems like a straightforward thing to get > > >right. > > Sounds fine to me. > > - Bernie > > -----Original Message----- > > From: Thomas Narten [mailto:narten@us.ibm.com] > > Sent: Thursday, May 09, 2002 9:23 AM > > To: Bernie Volz (EUD) > > Cc: Ole Troan; Ralph Droms; dhcwg@ietf.org > > Subject: Re: [dhcwg] dhcpv6-24: use of anycast > > > > > > > The only issue with this is that DHCP usually runs as an application > > > and is therefore only able to access that information which the > > > lower layers (via APIs) make available. > > Understood. > > > Determining whether multicast is supported or not is pretty standard > > > from the socket API. However, determining that a particular > > > interface is a specific media type may be difficult. > > OK. > > > Therefore, there is some value in providing a clear direction here > > > that is also relatively easy to implement. > > Agreed. > > > If all interface types provide multicast (either inherently or via > > > some type of emulation), there is little need to ever use the > > > anycast address and so what harm is there in specifying it. > > The harm is that a) we may define something that isn't useful (which > > may cause problems when deployed because some implementations choose > > use the feature even if it doesn't work as intended). b) clients may > > choose to send to anycast addresses, but if servers aren't configured > > to deal with them, we don't get interoperability, so specifying that > > clients MAY do something really implies (to me) that server SHOULD (or > > maybe even MUST) be prepared to handle such packets from clients. If > > the client can't expect a server to handle something, there is little > > point in clients implementing the feature either. > > My general opinion: if its not clear something is useful, and it's not > > obvious what the details should be, including the feature distracts > > from the overall goal of getting the spec done. The more one can > > remove, the fewer details that have to be gotten right. > > > What we probably should say is that the client MUST use the > > > multicast address if the interface on which it is sending the > > > message supports multicast. Otherwise, it may use the anycast > > > address. > > This is OK with me. Just so long as it's clear that the anycast usage > > is only link-local and is only for reaching servers (and relay agents) > > on the same link. This seems like a straightforward thing to get > > right. > > Thomas > > ------_=_NextPart_001_01C1FA7E.080F0570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: use of anycast

Ralph:

>There's no need to check for this reserved value = - the IPv6 stack will do
>normal DAD.  I don't think the stack has to = know about the use of the
>reserved address for DHCPv6 - just DHCPv6 = applications need to know.

What happens if a client starts up before the DHCP = server (or DAD fails to work because of temporary network issues) and = uses this "reserved value"? In that case, the DHCP server = can't run on that address and hence you don't have DHCP = service.

Again, I think this is a bad idea.

>That's OK - except for those link technologies = that are already
>defined?  Or, do we go ahead with DHCPv6 = and make a note that existing
>"IPv6 over X" docs should review the = need for special handling for DHCPv6?

I could be wrong, but as Thomas pointed out the = existing technologies do have multicast solutions and they'd have an = issue if they don't support multicast since ND (and DAD) wouldn't work = if they don't provide it.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, May 13, 2002 6:36 AM
To: Bernie Volz (EUD)
Cc: Bound, Jim; Thomas Narten; Ole Troan; = dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: use of anycast =


Bernie - I'm not sure the link-scoped unicast address = is such a good idea,
either.  However, I do have some comments about = your concerns (in line)...

- Ralph

At 08:34 PM 5/12/2002 -0500, Bernie Volz (EUD) = wrote:

>Ralph:
>
>I don't think the link-scoped unicast address is = a good idea. What would
>the prefix for this be?

The standard link-local prefix

>  If it is the standard link-local prefix, = what about all the hosts today
> that don't have code to check for this = value.

There's no need to check for this reserved value - = the IPv6 stack will do
normal DAD.  I don't think the stack has to = know about the use of the
reserved address for DHCPv6 - just DHCPv6 = applications need to know.


>I think we're best left with letting this issue = be resolved by the first
>link that needs it (as Thomas originally = suggested).

That's OK - except for those link technologies that = are already
defined?  Or, do we go ahead with DHCPv6 and = make a note that existing
"IPv6 over X" docs should review the need = for special handling for DHCPv6?


>So, perhaps we should simply say:
>
>"If the link supports multicast, the = multicast address MUST be used.
>Otherwise, the link over IPv6 specification = needs to specify what the DHCP
>Client must use."
>
>- Bernie
>
>-----Original Message-----
>From: Ralph Droms [<mailto:rdroms@cisco.com>mailto:rdroms@cisco.com]
>Sent: Sunday, May 12, 2002 12:45 PM
>To: Bound, Jim
>Cc: Bernie Volz (EUD); Thomas Narten; Ole Troan; = dhcwg@ietf.org
>Subject: RE: [dhcwg] dhcpv6-24: use of = anycast
>
>
>Jim makes a good good point about anycast.  = Given the current
>discussion about anycast addresses and hosts on = the ipngwg mailing
>list, it would be premature to specify = site-local anycast for DHCPv6.
>
>What about link-local only "anycast" - = perhaps that's not really
>"anycast" because there's no = routing?
>
>Instead of an anycast address, suppose we = request the reservation of a
>link-scoped unicast address for DHCP?  If = we use a unicast address, only
>one relay agent or server on a link can be = listening on that address,
>right?  For point-to-point links that's not = a problem - there can only be
>one relay agent or server at the other end of = the point-to-point link.
>I'm still not clear about multiple-access links = and multicast - are
>there any multiple access link technologies that = don't provide or emulate
>multicast?
>
>Is there a precedent for the reservation of a = link-scoped, well-known
>unicast address?
>
>Using a link-scoped unicast address, the first = relay agent or server to
>bind to the address gets to use it.   = I'm not familiar with the IPv6 API;
>I assume that an application (with sufficient = privilege) can make a
>request to assign a specific address to an = interface.  I guess the stack
>does DAD on the requested address and the = request fails if the address is
>already in use?
>
>I'm not thrilled with my idea - it sounds fairly = ugly.  Does it break or
>bend fewer existing standards, or require the = definition of fewer new
>standards than the use of an anycast = address?  Does the assignment of a
>well-known link-scoped unicast address for DHCP = set a precedent we'd
>rather not set?
>
>The use of the unicast address could be further = discouraged by including a
>restriction that relay agents and servers MUST = NOT listen on the unicast
>address and clients MUST NOT send messages to = the unicast address on a
>link that supports multicast.
>
>- Ralph
>
>  On Sun, 12 May 2002, Bound, Jim = wrote:
>
> > Thomas,
> >
> > I am fine with this too.  But what we = are permitting the server to have
> an anycast address and the addr arch says don't = do this?  Will it not be
> kicked  back again by the IESG because we = did that?
>
> >
> > thanks
> > /jim
> >
> > -----Original Message-----
> > From: Bernie Volz (EUD)
> [<mailto:Bernie.Volz@am1.erics= son.se>mailto:Bernie.Volz@am1.erics= son.se]
> > Sent: Thursday, May 09, 2002 9:27 = AM
> > To: 'Thomas Narten'; Bernie Volz = (EUD)
> > Cc: Ole Troan; Ralph Droms; = dhcwg@ietf.org
> > Subject: RE: [dhcwg] dhcpv6-24: use of = anycast
> >
> >
> > >> What we probably should say is = that the client MUST use the
> > >> multicast address if the = interface on which it is sending the
> > >> message supports multicast. = Otherwise, it may use the anycast
> > >> address.
> > >
> > >This is OK with me. Just so long as = it's clear that the anycast usage
> > >is only link-local and is only for = reaching servers (and relay agents)
> > >on the same link. This seems like a = straightforward thing to get
> > >right.
> > Sounds fine to me.
> > - Bernie
> > -----Original Message-----
> > From: Thomas Narten [<mailto:narten@us.ibm.com>mailto:narten@us.ibm.com]
> > Sent: Thursday, May 09, 2002 9:23 = AM
> > To: Bernie Volz (EUD)
> > Cc: Ole Troan; Ralph Droms; = dhcwg@ietf.org
> > Subject: Re: [dhcwg] dhcpv6-24: use of = anycast
> >
> >
> > > The only issue with this is that DHCP = usually runs as an application
> > > and is therefore only able to access = that information which the
> > > lower layers (via APIs) make = available.
> > Understood.
> > > Determining whether multicast is = supported or not is pretty standard
> > > from the socket API. However, = determining that a particular
> > > interface is a specific media type = may be difficult.
> > OK.
> > > Therefore, there is some value in = providing a clear direction here
> > >  that is also relatively easy to = implement.
> > Agreed.
> > > If all interface types provide = multicast (either inherently or via
> > > some type of emulation), there is = little need to ever use the
> > > anycast address and so what harm is = there in specifying it.
> > The harm is that a) we may define = something that isn't useful (which
> > may cause problems when deployed because = some implementations choose
> > use the feature even if it doesn't work as = intended). b) clients may
> > choose to send to anycast addresses, but = if servers aren't configured
> > to deal with them, we don't get = interoperability, so specifying that
> > clients MAY do something really implies = (to me) that server SHOULD (or
> > maybe even MUST) be prepared to handle = such packets from clients. If
> > the client  can't expect a server to = handle something, there is little
> > point in clients implementing the feature = either.
> > My general opinion: if its not clear = something is useful, and it's not
> > obvious what the details should be, = including the feature distracts
> > from the overall goal of getting the spec = done. The more one can
> > remove, the fewer details that have to be = gotten right.
> > > What we probably should say is that = the client MUST use the
> > > multicast address if the interface on = which it is sending the
> > > message supports multicast. = Otherwise, it may use the anycast
> > > address.
> > This is OK with me. Just so long as it's = clear that the anycast usage
> > is only link-local and is only for = reaching servers (and relay agents)
> > on the same link. This seems like a = straightforward thing to get
> > right.
> > Thomas
> >

------_=_NextPart_001_01C1FA7E.080F0570-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 13 21:34:27 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 VAA13328; Mon, 13 May 2002 21:34: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 VAA10017; Mon, 13 May 2002 21:34: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 VAA09992 for ; Mon, 13 May 2002 21:34:09 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13312 for ; Mon, 13 May 2002 21:33:54 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4E1WXm04015; Mon, 13 May 2002 21:32:33 -0400 Message-Id: <200205140132.g4E1WXm04015@cichlid.adsl.duke.edu> To: Ralph Droms cc: "Bound, Jim" , "Bernie Volz (EUD)" , Ole Troan , dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of anycast In-Reply-To: Message from Ralph Droms of "Sun, 12 May 2002 12:44:52 EDT." Date: Mon, 13 May 2002 21:32:33 -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 > Is there a precedent for the reservation of a link-scoped, well-known > unicast address? Not that I know of. Another reason why I'd like to include this only if we *really* need it. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 13 22:16: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 WAA15385; Mon, 13 May 2002 22:16: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 WAA13066; Mon, 13 May 2002 22:16:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA09422 for ; Mon, 13 May 2002 21:18:24 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13109 for ; Mon, 13 May 2002 21:18:07 -0400 (EDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4E1IB879840; Tue, 14 May 2002 10:18:11 +0900 (JST) Date: Tue, 14 May 2002 10:18:45 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] some comments and questions on dhcpv6-24 In-Reply-To: <4.3.2.7.2.20020511064013.0311acc0@funnel.cisco.com> References: <4.3.2.7.2.20020511064013.0311acc0@funnel.cisco.com> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 48 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 Mon, 13 May 2002 10:37:09 -0400, >>>>> Ralph Droms said: >> 17.2.2. Creation and transmission of Advertise messages >> >> ... The Advertise message MUST >> be unicast through the interface on which the Solicit message was >> received. >> >> It seems to me the requirement is too strong. Is this really >> necessary? > It's necessary if the server received the Solicit directly from the client; > i.e., if the server and the client are on the same link and the server is > sending the Advertise to the client's link-local address. I understand that, but as I said in the succeeding message, I think the "link" (not "interface") is more accurate. Requiring to send a particular "interface" is overspecification from a strict scope-architecture point of view. Also, using the word "link" is consistent with the wording in Section 16. >> 18.2.5. Receipt of Information-request messages >> >> The server contructs a Reply message by setting the "msg-type" field >> ^^^^^^^^^this should be "constructs". There are many >> other "contructs" in the draft. > This problem was fixed between preliminary publication of the -24 > rev and the final version published at the IETF. >> to REPLY, copying the transaction ID from the Rebind message into the >> ^^^^^^ >> transaction-ID field. >> >> Should the "Rebind" message be "Information-request"? This sentence >> seems to be just copied from the previous section... > This problem was fixed between preliminary publication of the -24 > rev and the final version published at the IETF. Okay, but where can I get the "final version"? The -24 draft at ftp://ftp.ietf.org/internet-drafts has the same problems. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon May 13 22:16:41 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 WAA15425; Mon, 13 May 2002 22:16: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 WAA13191; Mon, 13 May 2002 22:16: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 IAA28784 for ; Mon, 13 May 2002 08:28:36 -0400 (EDT) Received: from mlry.radlan.co.il ([212.117.141.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06317 for ; Mon, 13 May 2002 08:28:22 -0400 (EDT) Received: by MLRY with Internet Mail Service (5.5.2653.19) id ; Mon, 13 May 2002 15:27:21 +0200 Message-ID: <42AB6BE23C29D511831E0002B32024885BE0B9@messenger.radlan.co.il> From: Katia Linker To: DHCP IETF mailing list Date: Mon, 13 May 2002 15:27:30 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [dhcwg] "Options" field 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 Hi ! My question to all of you is regarding the "options" field of DHCP header. * Is it possible for DHCP server to receive some message with the length of options field = X, and send another message as a reply to client with the length of options field = Y ? * According to RFC 2131, the minimal length of the options field is 312, what is the maximal length of this field ? Thanks in advance Katya Linker Radlan Computer Communications Ltd. Atidim Technological Park Bldg #4 Tel Aviv 61131, Israel Tel: +972-3-7657900 Fax: +972-3-6487368 Visit us on http://www.radlan.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 14 13:52:55 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 NAA28383; Tue, 14 May 2002 13:52: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 NAA05537; Tue, 14 May 2002 13:50:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05507 for ; Tue, 14 May 2002 13:50:22 -0400 (EDT) Received: from quadntweb.quadritek.com ([198.200.138.211]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28304 for ; Tue, 14 May 2002 13:50:08 -0400 (EDT) Received: from dcopelandw2k ([198.200.138.72]) by quadntweb.quadritek.com (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35) with SMTP id com for ; Tue, 14 May 2002 13:49:22 -0400 Reply-To: From: "Dawn Copeland" To: Date: Tue, 14 May 2002 13:54:35 -0400 Message-ID: <005501c1fb70$68af6a80$488ac8c6@dcopelandw2k> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: <200205141600.MAA24244@optimus.ietf.org> Content-Transfer-Encoding: 7bit Subject: [dhcwg] help 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 Help...I would like to unsubscribe from the list. drcopeland@lucent.com Thanks, Dawn -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] Sent: Tuesday, May 14, 2002 12:01 PM To: dhcwg@ietf.org Subject: dhcwg digest, Vol 1 #260 - 5 msgs Send dhcwg mailing list submissions to dhcwg@ietf.org To subscribe or unsubscribe via the web, visit https://www1.ietf.org/mailman/listinfo/dhcwg or, via email, send a message with subject or body 'help' to dhcwg-request@ietf.org You can reach the person managing the list at dhcwg-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcwg digest..." Today's Topics: 1. Re: dhcpv6-24: use of anycast (Thomas Narten) 2. Re: some comments and questions on dhcpv6-24 (JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=) 3. "Options" field (Katia Linker) 4. Re: some comments and questions on dhcpv6-24 (Ralph Droms) 5. RE: "Options" field (Kostur, Andre) --__--__-- Message: 1 To: Ralph Droms cc: "Bound, Jim" , "Bernie Volz (EUD)" , Ole Troan , dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of anycast Date: Mon, 13 May 2002 21:32:33 -0400 From: Thomas Narten > Is there a precedent for the reservation of a link-scoped, well-known > unicast address? Not that I know of. Another reason why I'd like to include this only if we *really* need it. Thomas --__--__-- Message: 2 Date: Tue, 14 May 2002 10:18:45 +0900 From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] some comments and questions on dhcpv6-24 <4.3.2.7.2.20020511064013.0311acc0@funnel.cisco.com> Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. >>>>> On Mon, 13 May 2002 10:37:09 -0400, >>>>> Ralph Droms said: >> 17.2.2. Creation and transmission of Advertise messages >> >> ... The Advertise message MUST >> be unicast through the interface on which the Solicit message was >> received. >> >> It seems to me the requirement is too strong. Is this really >> necessary? > It's necessary if the server received the Solicit directly from the client; > i.e., if the server and the client are on the same link and the server is > sending the Advertise to the client's link-local address. I understand that, but as I said in the succeeding message, I think the "link" (not "interface") is more accurate. Requiring to send a particular "interface" is overspecification from a strict scope-architecture point of view. Also, using the word "link" is consistent with the wording in Section 16. >> 18.2.5. Receipt of Information-request messages >> >> The server contructs a Reply message by setting the "msg-type" field >> ^^^^^^^^^this should be "constructs". There are many >> other "contructs" in the draft. > This problem was fixed between preliminary publication of the -24 > rev and the final version published at the IETF. >> to REPLY, copying the transaction ID from the Rebind message into the >> ^^^^^^ >> transaction-ID field. >> >> Should the "Rebind" message be "Information-request"? This sentence >> seems to be just copied from the previous section... > This problem was fixed between preliminary publication of the -24 > rev and the final version published at the IETF. Okay, but where can I get the "final version"? The -24 draft at ftp://ftp.ietf.org/internet-drafts has the same problems. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --__--__-- Message: 3 From: Katia Linker To: DHCP IETF mailing list Date: Mon, 13 May 2002 15:27:30 +0200 charset="windows-1255" Subject: [dhcwg] "Options" field Hi ! My question to all of you is regarding the "options" field of DHCP header. * Is it possible for DHCP server to receive some message with the length of options field = X, and send another message as a reply to client with the length of options field = Y ? * According to RFC 2131, the minimal length of the options field is 312, what is the maximal length of this field ? Thanks in advance Katya Linker Radlan Computer Communications Ltd. Atidim Technological Park Bldg #4 Tel Aviv 61131, Israel Tel: +972-3-7657900 Fax: +972-3-6487368 Visit us on http://www.radlan.com --__--__-- Message: 4 Date: Tue, 14 May 2002 05:46:46 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [dhcwg] some comments and questions on dhcpv6-24 Cc: dhcwg@ietf.org <4.3.2.7.2.20020511064013.0311acc0@funnel.cisco.com> At 10:18 AM 5/14/2002 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Mon, 13 May 2002 10:37:09 -0400, > >>>>> Ralph Droms said: > > >> 17.2.2. Creation and transmission of Advertise messages > >> > >> ... The Advertise message MUST > >> be unicast through the interface on which the Solicit message was > >> received. > >> > >> It seems to me the requirement is too strong. Is this really > >> necessary? > > > It's necessary if the server received the Solicit directly from the > client; > > i.e., if the server and the client are on the same link and the server is > > sending the Advertise to the client's link-local address. > >I understand that, but as I said in the succeeding message, I think >the "link" (not "interface") is more accurate. Requiring to send a >particular "interface" is overspecification from a strict >scope-architecture point of view. Also, using the word "link" is >consistent with the wording in Section 16. You're correct - we can reuse the wording of section 16 here. > >> 18.2.5. Receipt of Information-request messages > >> > >> The server contructs a Reply message by setting the "msg-type" field > >> ^^^^^^^^^this should be "constructs". There are many > >> other "contructs" in the draft. > > > This problem was fixed between preliminary publication of the -24 > > rev and the final version published at the IETF. > > >> to REPLY, copying the transaction ID from the Rebind message into the > >> ^^^^^^ > >> transaction-ID field. > >> > >> Should the "Rebind" message be "Information-request"? This sentence > >> seems to be just copied from the previous section... > > > This problem was fixed between preliminary publication of the -24 > > rev and the final version published at the IETF. > >Okay, but where can I get the "final version"? The -24 draft at >ftp://ftp.ietf.org/internet-drafts has the same problems. Sorry - the version at ftp.ietf.org is the "final version". I missed that the "Rebind"->"Information-request" goof was not fixed... > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp --__--__-- Message: 5 From: "Kostur, Andre" To: "'Katia Linker'" , DHCP IETF mailing list Subject: RE: [dhcwg] "Options" field Date: Tue, 14 May 2002 08:38:06 -0700 boundary="----_=_NextPart_001_01C1FB5D.57863CB0" 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_01C1FB5D.57863CB0 Content-Type: text/plain; charset="windows-1255" Comments inline.... > -----Original Message----- > From: Katia Linker [mailto:KatiaL@radlan.com] > Sent: Monday, May 13, 2002 6:28 AM > To: DHCP IETF mailing list > Subject: [dhcwg] "Options" field > > > > Hi ! > My question to all of you is regarding the "options" field of > DHCP header. > * Is it possible for DHCP server to receive some message with the > length > of options field = X, and send another message as a reply to > client with > the length of options field = Y ? Sure. Just means that the server has more to say than the client. > * According to RFC 2131, the minimal length of the > options field is > 312, > what is the maximal length of this field ? Probably the size of a UDP packet (minus the size of the header... 200 or so bytes). However, clients can tell the server that they can only accept messages up to size X (there's an option for it). ------_=_NextPart_001_01C1FB5D.57863CB0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] "Options" field

Comments inline....

> -----Original Message-----
> From: Katia Linker [mailto:KatiaL@radlan.com]
> Sent: Monday, May 13, 2002 6:28 AM
> To: DHCP IETF mailing list
> Subject: [dhcwg] "Options" = field
>
>
>
> Hi !
> My question to all of you is regarding the = "options" field of
> DHCP header.
> *     Is it possible for = DHCP server to receive some message with the
> length
> of options field =3D X, and send another = message as a reply to
> client with
> the length of options field =3D Y ?

Sure.  Just means that the server has more to = say than the client.

> *     According to RFC 2131, = the minimal length of the
> options field is
> 312,
> what is the maximal length of this field = ?

Probably the size of a UDP packet (minus the size of = the header... 200 or so bytes).  However, clients can tell the = server that they can only accept messages up to size X (there's an = option for it).

------_=_NextPart_001_01C1FB5D.57863CB0-- --__--__-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg End of dhcwg Digest _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 14 15:54:43 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 PAA03379; Tue, 14 May 2002 15:54: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 PAA16459; Tue, 14 May 2002 15:53:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA16430 for ; Tue, 14 May 2002 15:53:14 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03284 for ; Tue, 14 May 2002 15:53:00 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4EJqgHt017525 for ; Tue, 14 May 2002 12:52:42 -0700 (PDT) Date: Tue, 14 May 2002 15:52:42 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Edit #1 of DHCPv6 spec 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 am updating draft-ietf-dhc-dhcpv6-24.txt, following up on Thomas Narten's recent comments. Here's the first of those updates: Narten: 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. The authors decided to retain the VUID-DN format and correct the text in section 9.3 to reflect the representation of DNS names specified in section 8. *** dhcpv6-24.txt Tue Apr 23 15:35:14 2002 --- dhcpv6.tty Tue May 14 15:43:55 2002 *************** *** 1258,1272 **** +---+---+---+---+---+---+---+---+ | 0 | 2 | 0 | 8 | 12|192|132|221| +---+---+---+---+---+---+---+---+ ! | 3 | 0 | 9 | 18|101|120| 97|109| +---+---+---+---+---+---+---+---+ - |112|108|101| 46| 99|111|109| - +---+---+---+---+---+---+---+ This example includes the two-octet type of 2, the two-octet length of 8, eight octets of identifier data, followed by "example.com" ! represented in ASCII. 9.4. Vendor-assigned unique ID based on Enterprise Number (VUID-EN) --- 1258,1272 ---- +---+---+---+---+---+---+---+---+ | 0 | 2 | 0 | 8 | 12|192|132|221| +---+---+---+---+---+---+---+---+ ! | 3 | 0 | 9 | 18| 7 |101|120| 97| ! +---+---+---+---+---+---+---+---+ ! |109|112|108|101| 3 | 99|111|109| +---+---+---+---+---+---+---+---+ This example includes the two-octet type of 2, the two-octet length of 8, eight octets of identifier data, followed by "example.com" ! represented as described in section 8. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 14 15:56: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 PAA03485; Tue, 14 May 2002 15:56: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 FAA22986; Tue, 14 May 2002 05:51: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 FAA22949 for ; Tue, 14 May 2002 05:51:27 -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 FAA10867 for ; Tue, 14 May 2002 05:51:15 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-84.cisco.com [10.82.224.84]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA23858; Tue, 14 May 2002 05:50:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20020513222518.00ba4158@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 May 2002 05:46:46 -0400 To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= From: Ralph Droms Subject: Re: [dhcwg] some comments and questions on dhcpv6-24 Cc: dhcwg@ietf.org In-Reply-To: References: <4.3.2.7.2.20020511064013.0311acc0@funnel.cisco.com> <4.3.2.7.2.20020511064013.0311acc0@funnel.cisco.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 At 10:18 AM 5/14/2002 +0900, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > >>>>> On Mon, 13 May 2002 10:37:09 -0400, > >>>>> Ralph Droms said: > > >> 17.2.2. Creation and transmission of Advertise messages > >> > >> ... The Advertise message MUST > >> be unicast through the interface on which the Solicit message was > >> received. > >> > >> It seems to me the requirement is too strong. Is this really > >> necessary? > > > It's necessary if the server received the Solicit directly from the > client; > > i.e., if the server and the client are on the same link and the server is > > sending the Advertise to the client's link-local address. > >I understand that, but as I said in the succeeding message, I think >the "link" (not "interface") is more accurate. Requiring to send a >particular "interface" is overspecification from a strict >scope-architecture point of view. Also, using the word "link" is >consistent with the wording in Section 16. You're correct - we can reuse the wording of section 16 here. > >> 18.2.5. Receipt of Information-request messages > >> > >> The server contructs a Reply message by setting the "msg-type" field > >> ^^^^^^^^^this should be "constructs". There are many > >> other "contructs" in the draft. > > > This problem was fixed between preliminary publication of the -24 > > rev and the final version published at the IETF. > > >> to REPLY, copying the transaction ID from the Rebind message into the > >> ^^^^^^ > >> transaction-ID field. > >> > >> Should the "Rebind" message be "Information-request"? This sentence > >> seems to be just copied from the previous section... > > > This problem was fixed between preliminary publication of the -24 > > rev and the final version published at the IETF. > >Okay, but where can I get the "final version"? The -24 draft at >ftp://ftp.ietf.org/internet-drafts has the same problems. Sorry - the version at ftp.ietf.org is the "final version". I missed that the "Rebind"->"Information-request" goof was not fixed... > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 14 15:58:49 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 PAA03570; Tue, 14 May 2002 15:58: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 LAA18690; Tue, 14 May 2002 11:32:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18640 for ; Tue, 14 May 2002 11:32:08 -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 LAA23569 for ; Tue, 14 May 2002 11:31:51 -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 177e9O-00014v-00; Tue, 14 May 2002 08:23:42 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <2ZV8S3VK>; Tue, 14 May 2002 08:38:06 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D19849587E@homer.incognito.com.> From: "Kostur, Andre" To: "'Katia Linker'" , DHCP IETF mailing list Subject: RE: [dhcwg] "Options" field Date: Tue, 14 May 2002 08:38:06 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FB5D.57863CB0" 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_01C1FB5D.57863CB0 Content-Type: text/plain; charset="windows-1255" Comments inline.... > -----Original Message----- > From: Katia Linker [mailto:KatiaL@radlan.com] > Sent: Monday, May 13, 2002 6:28 AM > To: DHCP IETF mailing list > Subject: [dhcwg] "Options" field > > > > Hi ! > My question to all of you is regarding the "options" field of > DHCP header. > * Is it possible for DHCP server to receive some message with the > length > of options field = X, and send another message as a reply to > client with > the length of options field = Y ? Sure. Just means that the server has more to say than the client. > * According to RFC 2131, the minimal length of the > options field is > 312, > what is the maximal length of this field ? Probably the size of a UDP packet (minus the size of the header... 200 or so bytes). However, clients can tell the server that they can only accept messages up to size X (there's an option for it). ------_=_NextPart_001_01C1FB5D.57863CB0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] "Options" field

Comments inline....

> -----Original Message-----
> From: Katia Linker [mailto:KatiaL@radlan.com]
> Sent: Monday, May 13, 2002 6:28 AM
> To: DHCP IETF mailing list
> Subject: [dhcwg] "Options" = field
>
>
>
> Hi !
> My question to all of you is regarding the = "options" field of
> DHCP header.
> *     Is it possible for = DHCP server to receive some message with the
> length
> of options field =3D X, and send another = message as a reply to
> client with
> the length of options field =3D Y ?

Sure.  Just means that the server has more to = say than the client.

> *     According to RFC 2131, = the minimal length of the
> options field is
> 312,
> what is the maximal length of this field = ?

Probably the size of a UDP packet (minus the size of = the header... 200 or so bytes).  However, clients can tell the = server that they can only accept messages up to size X (there's an = option for it).

------_=_NextPart_001_01C1FB5D.57863CB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 14 16:03: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 QAA03805; Tue, 14 May 2002 16:03: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 QAA18236; Tue, 14 May 2002 16:02:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA18211 for ; Tue, 14 May 2002 16:02:11 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03745 for ; Tue, 14 May 2002 16:01:57 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4EK1dHt023356 for ; Tue, 14 May 2002 13:01:40 -0700 (PDT) Date: Tue, 14 May 2002 16:01:39 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Edit #1 of DHCPv6 spec (corrected) 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 am updating draft-ietf-dhc-dhcpv6-24.txt, following up on Thomas Narten's recent comments. Here's the first of those updates (corrected; Josh Littlefield pointed out the example needs a trailing null octet.): Narten: 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. The authors decided to retain the VUID-DN format and correct the text in section 9.3 to reflect the representation of DNS names specified in section 8. +---+---+---+---+---+---+---+---+ | 0 | 2 | 0 | 8 | 12|192|132|221| +---+---+---+---+---+---+---+---+ ! | 3 | 0 | 9 | 18| 7 |101|120| 97| +---+---+---+---+---+---+---+---+ ! |109|112|108|101| 3 | 99|111|109| ! +---+---+---+---+---+---+---+---+ ! | 0 | ! +---+ This example includes the two-octet type of 2, the two-octet length of 8, eight octets of identifier data, followed by "example.com" ! represented as described in section 8. ! ! --- 1258,1279 ---- +---+---+---+---+---+---+---+---+ | 0 | 2 | 0 | 8 | 12|192|132|221| +---+---+---+---+---+---+---+---+ ! | 3 | 0 | 9 | 18|101|120| 97|109| +---+---+---+---+---+---+---+---+ ! |112|108|101| 46| 99|111|109| ! +---+---+---+---+---+---+---+ This example includes the two-octet type of 2, the two-octet length of 8, eight octets of identifier data, followed by "example.com" ! represented in ASCII. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 14 16:08: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 QAA04148; Tue, 14 May 2002 16:08:25 -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 QAA19084; Tue, 14 May 2002 16:07:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19056 for ; Tue, 14 May 2002 16:07:01 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04040 for ; Tue, 14 May 2002 16:06:47 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4EK6THt027140 for ; Tue, 14 May 2002 13:06:30 -0700 (PDT) Date: Tue, 14 May 2002 16:06:29 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Edit #2 of DHCP spec 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 Narten: > 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. Response: Changed the second sentence as follows: *************** *** 1923,1932 **** 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 IPv6 Neighbor Discovery causes the client to ! invoke the stateful address autoconfiguration protocol (see section ! 5.5.3 of RFC2462). This random delay desynchronizes clients which ! start at the same time (for example, after a power outage). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 14 16:58:58 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 QAA06656; Tue, 14 May 2002 16:58:58 -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 QAA23297; Tue, 14 May 2002 16:57: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 QAA23277 for ; Tue, 14 May 2002 16:57:23 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06562 for ; Tue, 14 May 2002 16:57:09 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4EKupHt000624 for ; Tue, 14 May 2002 13:56:52 -0700 (PDT) Date: Tue, 14 May 2002 16:56:51 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Edit #4 of DHCPv6 spec 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 Narten: > 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. Response: Remove All_DHCP_Servers as destination for Information-request message; deleted cited text from section 18.1.5. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 08:54:28 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 IAA00898; Wed, 15 May 2002 08:54: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 IAA13540; Wed, 15 May 2002 08:53: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 IAA13505 for ; Wed, 15 May 2002 08:53:49 -0400 (EDT) Received: from ch2-dhcp150-26.cisco.com (ch2-dhcp150-26.cisco.com [161.44.150.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00858 for ; Wed, 15 May 2002 08:53:35 -0400 (EDT) Received: (from rdroms@localhost) by ch2-dhcp150-26.cisco.com (8.11.6/8.11.6) id g4FCrG801313; Wed, 15 May 2002 08:53:16 -0400 Date: Wed, 15 May 2002 08:53:16 -0400 Message-Id: <200205151253.g4FCrG801313@ch2-dhcp150-26.cisco.com> From: Ralph Droms To: dhcwg@ietf.org Reply-to: rdroms@cisco.com Subject: [dhcwg] Edit #5 of DHCPv6 spec 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 Narten: > 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. Response: We have clarified the definitions of Confirm, Renew and Rebind (see below). We have retained the Confirm message as it is used by a client in different situations from Rebind and Renew, and we have retained the references to "movement detection" as examples of situations in which a DHCP client may send a Confirm message. *** dhcpv6.tty Wed May 15 05:35:23 2002 --- dhcpv6-24.txt Tue Apr 23 15:35:14 2002 *************** *** 752,776 **** REQUEST (3) A client sends a Request message to request configuration parameters from a server. ! CONFIRM (4) A client sends a Confirm message to any ! available server when it detects that it may ! have moved to a new link to request that the ! servers verify 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 parameters to extend the ! leases on the addresses assigned to the client ! and to update other configuration parameters. ! ! REBIND (6) A client sends a Rebind message to any ! available server to extend the leases on the ! addresses assigned to the client and to update ! other configuration parameters; this message is ! sent after a client receives no response to a ! Renew message. REPLY (7) A server sends a Reply message containing assigned addresses and configuration parameters --- 752,778 ---- REQUEST (3) A client sends a Request message to request configuration parameters from a server. ! 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. REPLY (7) A server sends a Reply message containing assigned addresses and configuration parameters _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 09:36: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 JAA03659; Wed, 15 May 2002 09:36: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 JAA19751; Wed, 15 May 2002 09:35: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 JAA19729 for ; Wed, 15 May 2002 09:35:50 -0400 (EDT) Received: from ch2-dhcp150-26.cisco.com (ch2-dhcp150-26.cisco.com [161.44.150.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03527 for ; Wed, 15 May 2002 09:35:36 -0400 (EDT) Received: (from rdroms@localhost) by ch2-dhcp150-26.cisco.com (8.11.6/8.11.6) id g4FDZHf01496; Wed, 15 May 2002 09:35:17 -0400 Date: Wed, 15 May 2002 09:35:17 -0400 Message-Id: <200205151335.g4FDZHf01496@ch2-dhcp150-26.cisco.com> From: Ralph Droms To: dhcwg@ietf.org CC: rdroms@cisco.com Reply-to: rdroms@cisco.com Subject: [dhcwg] Edit #3 of DHCP spec 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 Narten: > 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? Response: Modified Rapid Commit to allow servers to respond with Advertise and client to respond to Advertise if it does not receive a Rapid Commit/Reply *** dhcpv6.tty Wed May 15 06:14:14 2002 --- dhcpv6-24.txt Tue Apr 23 15:35:14 2002 *************** *** 1940,1951 **** MRD 0 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. If the client receives an ! Advertise message that includes a Preference option with a preference ! value of 255, the client immediately begins a client-initiated ! message exchange (as described in section 18) by sending a Request ! message to the server from which the Advertise message was received. --- 1939,1951 ---- MRD 0 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. ! ! If the client is waiting for an Advertise message, the mechanism in ! section 14 is modified as follows for use in the transmission of ! Solicit messages. The message exchange is not terminated by the ! receipt of an Advertise before IRT has elapsed. Rather, the client *************** *** 1954,1969 **** Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 - If the client receives an Advertise message that does not include - a Preference option with a preference value of 255, the client - continues to wait until IRT elapses. If IRT elapses and the client - has received an Advertise message, the client SHOULD continue with a - client-initiated message exchange by sending a Request message. - - If the client is waiting for an Advertise message, the mechanism in - section 14 is modified as follows for use in the transmission of - Solicit messages. The message exchange is not terminated by the - receipt of an Advertise before IRT has elapsed. Rather, the client collects Advertise messages until IRT has elapsed. Also, the first RT MUST be selected to be strictly greater than IRT by choosing RAND to be strictly greater than 0. --- 1954,1959 ---- *************** *** 2039,2047 **** 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. 17.2. Server Behavior --- 2028,2039 ---- 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. 17.2. Server Behavior *************** *** 2061,2081 **** If the client has included a Rapid Commit option in the Solicit message and the server has been configured to respond with committed address assignments and other resources, the server responds to the ! Solicit with a Reply message as described in section 17.2.3. If the ! server has been configured to respond to the client but has not been ! configured to respond with committed address assignments and other ! resources, the server responds with an Advertise message. Otherwise, the server generates and sends an Advertise message to the client. - - Droms (ed.), et al. Expires 22 Oct 2002 [Page 30] - - Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 - - 17.2.2. Creation and transmission of Advertise messages The server sets the "msg-type" field to ADVERTISE and copies the --- 2053,2064 ---- If the client has included a Rapid Commit option in the Solicit message and the server has been configured to respond with committed address assignments and other resources, the server responds to the ! Solicit with a Reply message as described in section 17.2.3. Otherwise, the server generates and sends an Advertise message to the client. 17.2.2. Creation and transmission of Advertise messages The server sets the "msg-type" field to ADVERTISE and copies the _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 10:02: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 KAA05209; Wed, 15 May 2002 10:02: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 KAA22464; Wed, 15 May 2002 10:01: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 FAA29718 for ; Wed, 15 May 2002 05:09:28 -0400 (EDT) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22444 for ; Wed, 15 May 2002 05:09:13 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id BAA28674 for ; Wed, 15 May 2002 01:57:24 -0700 (MST)] Received: [from az33exr02.mot.com (az33exr02.mot.com [10.64.251.232]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id BAA23789 for ; Wed, 15 May 2002 01:56:23 -0700 (MST)] Received: from thorgal.crm.mot.com (thorgal.crm.mot.com [140.101.173.1]) by az33exr02.mot.com (8.11.6/8.11.6) with ESMTP id g4F99lF07287; Wed, 15 May 2002 04:09:48 -0500 Received: from test9.crm.mot.com.crm.mot.com (test9.crm.mot.com [140.101.173.239]) by thorgal.crm.mot.com (Postfix) with ESMTP id 3F7C82EC86; Wed, 15 May 2002 11:09:16 +0200 (CEST) To: Thomas Narten Cc: Subject: Re: [dhcwg] dhcpv6-24: confirm vs. renew vs. rebind References: <200205081513.g48FD7W19372@rotala.raleigh.ibm.com> From: Alexandru Petrescu Date: 14 May 2002 22:48:35 +0200 In-Reply-To: <200205081513.g48FD7W19372@rotala.raleigh.ibm.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Lines: 21 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 Narten writes: > 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.) Hi, I'm not intending at all to fight over whether this particular message is useful or not, especially since I was not involved in its inclusion here. Just wanted to mention a possible use that is to couple it with RIP update messages within a small domain (what is small) to manage mobility with host-based routes. Within such a domain, access routers are co-located with DHCP relays and the most central router is co-located with the DHCP server. The advantage of using confirm to trigger the update is that the addition of the new route is triggered from both ends of a path (from server and from relay), completing the route supposedly faster. Alex _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 12:58:31 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 MAA13262; Wed, 15 May 2002 12:58: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 MAA11541; Wed, 15 May 2002 12:49:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA11523 for ; Wed, 15 May 2002 12:49:01 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12921 for ; Wed, 15 May 2002 12:48:46 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4FGlar01969 for ; Wed, 15 May 2002 12:47:36 -0400 Message-Id: <200205151647.g4FGlar01969@cichlid.adsl.duke.edu> To: dhcwg@ietf.org Date: Wed, 15 May 2002 12:47:36 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-w4: optional parts of spec 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 From another thread: Ted Lemon writes: > > Hmm. If this message is OPTIONAL to implement, this needs to be made > > clear in the spec. I assumed it was mandatory. I think it should be > > mandatory. If it is not, there is little point in clients implementing > > it. I.e., it doesn't make sense for clients to implement basic > > features that servers aren't required to implement. This leads to bad > > interoperability. > This is a case where the market will quickly punish servers that don't > implement it that should. We aren't even insisting that address > allocation is mandatory, AFAIK, so saying that confirm is mandatory seems > inconsistent. That is, it is fine to implement a DHCPv6 server that only > responds to information requests and that does not allocate IP addresses. > A DHCP server configured to just provide information might not even have > enough information to determine whether or not a client is on the link on > which its addresses are valid. I have a real problem with significant parts of the base DHCP being "optional" Note also that an IESG reviewer (independently) did notice the following: > 1.2. Protocol implementation > Clients and servers that do not use all of the functions of DHCP > need not implement processing for those DHCP messages that will > not be used. > how will this ever do *useful* interop testing? a client/server > pair which implement *no* messages, or a useless but amusing > subset, could pass. If we want useful interoperability, that means that any protocol feature the client MAY (or even SHOULD) be able to implement MUST be implemented by the server. Note I am not talking about support for individual options. But I am talking about support for basic DHC message types (Confirm, Fast-Reply, etc.) I think the spec needs to make it very clear that all parts of DHC MUST be implemented for a server to be considered compliant. If the WG wants to define several levels of implementations (like a non-address supporting mode) that is one thing. But then the document should make it clear what parts MUST be implemented in order to be support a particular mode. But life would just be simpler if the spec just said servers need to implement everything. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:02: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 NAA13410; Wed, 15 May 2002 13:02: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 MAA11910; Wed, 15 May 2002 12:53: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 MAA11882 for ; Wed, 15 May 2002 12:53:55 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13069 for ; Wed, 15 May 2002 12:53:36 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4FGqN902056; Wed, 15 May 2002 12:52:23 -0400 Message-Id: <200205151652.g4FGqN902056@cichlid.adsl.duke.edu> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: use of anycast In-Reply-To: Message from Ralph Droms of "Wed, 08 May 2002 11:07:35 EDT." <4.3.2.7.2.20020508110115.031eaab0@funnel.cisco.com> Date: Wed, 15 May 2002 12:52:22 -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. I've asked some more IPv6 people about whether they believe there are (or will ever be) links that support IPv6, but not IPv6 multicast. No one has argued that such links will exists or should be allowed to exist. Based on the above, I would like to request that all the anycast text be removed from the document. It simply does not seem to be needed to solve an actual problem. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:10: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 NAA13708; Wed, 15 May 2002 13: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 NAA12869; Wed, 15 May 2002 13:01:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA12836 for ; Wed, 15 May 2002 13:01:11 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13371 for ; Wed, 15 May 2002 13:00:57 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4FGxlj02153 for ; Wed, 15 May 2002 12:59:47 -0400 Message-Id: <200205151659.g4FGxlj02153@cichlid.adsl.duke.edu> To: dhcwg@ietf.org Date: Wed, 15 May 2002 12:59:47 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: compression in DNS names 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 [Note: the IESG is starting to review this document, and I'm getting questions comments on the ID]. This document specifies that DNS Names are represented in DNS on-the-wire formate, and compression MUST be supported. I understand that DHCPv4 supports this now (with recent options). But there is also complexity associated with the compression part. In DHCPv4, options were limited in size (255 bytes). DHCPv6 doesn't have this restriction. So the need for compression is reduced. How about just removing the requirement to support compression. This will simplify implementations and doesn't appear to result in any real loss of functionality. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:12: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 NAA13828; Wed, 15 May 2002 13:12: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 NAA12742; Wed, 15 May 2002 13:00: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 NAA12706 for ; Wed, 15 May 2002 13:00:52 -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 NAA13366 for ; Wed, 15 May 2002 13:00:38 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-152.cisco.com [161.44.149.152]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA00880 for ; Wed, 15 May 2002 13:00:20 -0400 (EDT) Message-Id: <4.3.2.7.2.20020515124413.03651758@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 May 2002 13:00:17 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhcpv6-24: Interface-ID option In-Reply-To: <200205081509.g48F9mY19283@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 At 11:09 AM 5/8/2002 -0400, Thomas Narten wrote: > > 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 always fills in the link-address field even if it also includes an Interface-id option. Does the text need to be clarified? > > 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. This text should be edited to (based on suggested text from Bernie): The relay agent fills in the link-address field as described in the previous paragraph regardless of whether the relay agent includes an Interface-id option in the Relay-forward message. > > 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. The link-address field does contain useful information (a site-scoped or global address); the Interface-ID provides additional 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. OK, we'll add some words about stability. > > interface-id An opaque value of arbitrary length generated > > by the relay agent to identify one of the > > relay agent's interfaces > >Any reason not to make this 32 bits? the IPv6 API already has 32-bit >interface IDs. Is there any reason to make it larger? The relay agent may use another value aside from the IPv6 API for the interface-id, so we should allow for arbitrary length. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:17:10 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 NAA13984; Wed, 15 May 2002 13:17:10 -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 NAA13262; Wed, 15 May 2002 13:07: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 NAA13237 for ; Wed, 15 May 2002 13:07:23 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13574 for ; Wed, 15 May 2002 13:07:07 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4FH5vq02245 for ; Wed, 15 May 2002 13:05:57 -0400 Message-Id: <200205151705.g4FH5vq02245@cichlid.adsl.duke.edu> To: dhcwg@ietf.org Date: Wed, 15 May 2002 13:05:57 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: Reconfigure 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 One IESG member has asked: > 19. DHCP Server-Initiated Configuration Exchange > reconfigure messages provide such a wonderful opportunity for > attack. and they are sent unicast "using an IPv6 unicast address > of sufficient scope belonging to the DHCP client." > possibly, the server could have intially provided a nonce that the > client retains for validation. but this precludes redundant server > setups etc. My response: An interesting suggestion. Actually, it may not preclude this. The idea behind the Reconfigure is that the server that has state about clients sends unicast Reconfigures to that client. It is not intended to be used to allow any old DHC server to prod a client. So requiring that the server also include a nonce may be OK. Question to the WG: should this be added? It would add some additional defense against improper Reconfigure. Thoughts? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:17: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 NAA14058; Wed, 15 May 2002 13:17:51 -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 NAA13378; Wed, 15 May 2002 13:09: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 NAA13351 for ; Wed, 15 May 2002 13:09:29 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA13665 for ; Wed, 15 May 2002 13:09:15 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4FH82402270 for ; Wed, 15 May 2002 13:08:02 -0400 Message-Id: <200205151708.g4FH82402270@cichlid.adsl.duke.edu> To: dhcwg@ietf.org Date: Wed, 15 May 2002 13:08:02 -0400 From: Thomas Narten Subject: [dhcwg] dhcpv6-24: Security considerations 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 Review comments on some security aspects: > 21. Authentication of DHCP messages > the replay detection method, which only requires a monotonically > increasing value, seems trivial to spoof. and the main auth > method, delayed authentication, relies on distribution of > preconfigured shared keys, yet 21.5.4 provides no key roll-over > mechanism (attack by ex-employee), and admits to not scaling well > and not supporting roamers. none of these issues are mentioned in > the security section. Makes sense to me. > 23. Security Considerations > should this not discuss where section 21 is weak? yes, or point to the text that does. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:20:41 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 NAA14208; Wed, 15 May 2002 13:20: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 NAA13612; Wed, 15 May 2002 13:11:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA13594 for ; Wed, 15 May 2002 13:11:28 -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 NAA13769 for ; Wed, 15 May 2002 13:11:14 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-152.cisco.com [161.44.149.152]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA01772 for ; Wed, 15 May 2002 13:10:56 -0400 (EDT) Message-Id: <4.3.2.7.2.20020515130438.03651a50@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 May 2002 13:10:54 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses In-Reply-To: <200205081511.g48FBh119311@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 At 11:11 AM 5/8/2002 -0400, Thomas Narten wrote: > > 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) OK (but see below). >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. I agree that the protocol software needs to identify temporary addresses so that applications can select for or against them. But, how does DHCP handle temporary and non-temp addresses differently? Is is just a tag that the server supplies and the protocol software interprets to identify temporary addresses or are there other differences? >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. OK - we can reference RFC3041 for that guidance... >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 dhcwg-admin@ietf.org Wed May 15 13:22:04 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 NAA14289; Wed, 15 May 2002 13:22: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 NAA14006; Wed, 15 May 2002 13: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 NAA13989 for ; Wed, 15 May 2002 13:17: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 NAA14035 for ; Wed, 15 May 2002 13:17:38 -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 g4FHHpl14825 for ; Wed, 15 May 2002 12:17:51 -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 g4FHHoe28970 for ; Wed, 15 May 2002 12:17:50 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed May 15 12:17:50 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:17:50 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D41A@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Reconfigure Date: Wed, 15 May 2002 12:17:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC34.6F519100" 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_01C1FC34.6F519100 Content-Type: text/plain; charset="iso-8859-1" This certainly is an interesting idea. (Redundant server setups would likely need to exchange other information so they could also exchange the nonce). But, what about simply suggesting that DHCP authentication be used? Or is that considered too weak? Anyway to make sure I understand this, you would recommend a "Reconfiguration Nonce" option that the server would send the client in a Reply (such as to a Request or Rebind). The client would save this option and only accept a Reconfigure if the server sent that same "Reconfiguration Nonce" option in the Reconfigure message? Note: Perhaps any Reply from a server could contain this as it may want to change its nonce? x.x Reconfiguration Nonce Option A server sends the Reconfiguration Nonce option to a client in a Reply to a Request and Rebind. The client is responsible for saving the reconfiguration-nonce in order to validation reconfiguration requests from the server. The server also sends the Reconfiguration Nonce option in a Reconfigure message and the client only accepts the Reconfigure message if the nonce matches the one received in a Reply. 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_INTERFACE_ID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . reconfiguration-nonce . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_INTERFACE_ID (18) option-len Length of reconfiguration-nonce field reconfiguration-nonce An opaque value of arbitrary length generated by the server - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Wednesday, May 15, 2002 1:06 PM To: dhcwg@ietf.org Subject: [dhcwg] dhcpv6-24: Reconfigure One IESG member has asked: > 19. DHCP Server-Initiated Configuration Exchange > reconfigure messages provide such a wonderful opportunity for > attack. and they are sent unicast "using an IPv6 unicast address > of sufficient scope belonging to the DHCP client." > possibly, the server could have intially provided a nonce that the > client retains for validation. but this precludes redundant server > setups etc. My response: An interesting suggestion. Actually, it may not preclude this. The idea behind the Reconfigure is that the server that has state about clients sends unicast Reconfigures to that client. It is not intended to be used to allow any old DHC server to prod a client. So requiring that the server also include a nonce may be OK. Question to the WG: should this be added? It would add some additional defense against improper Reconfigure. Thoughts? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1FC34.6F519100 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Reconfigure

This certainly is an interesting idea. (Redundant = server setups would likely need to exchange other information so they = could also exchange the nonce).

But, what about simply suggesting that DHCP = authentication be used? Or is that considered too weak?

Anyway to make sure I understand this, you would = recommend a "Reconfiguration Nonce" option that the server = would send the client in a Reply (such as to a Request or Rebind). The = client would save this option and only accept a Reconfigure if the = server sent that same "Reconfiguration Nonce" option in the = Reconfigure message?

Note: Perhaps any Reply from a server could contain = this as it may want to change its nonce?

x.x Reconfiguration Nonce Option

   A server sends the Reconfiguration Nonce = option to a client in a Reply
   to a Request and Rebind. The client is = responsible for saving the
   reconfiguration-nonce in order to = validation reconfiguration requests
   from the server. The server also sends = the Reconfiguration Nonce option
   in a Reconfigure message and the client = only accepts the Reconfigure
   message if the nonce matches the one = received in a Reply.

    = 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_INTERFACE_ID      = |         = option-len          &n= bsp; |
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
   = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
   = .           &nbs= p;         = reconfiguration-nonce        &nb= sp;            = .
   = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
   = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=



      = option-code          = OPTION_INTERFACE_ID (18)

      = option-len           = Length of reconfiguration-nonce field

      reconfiguration-nonce = An opaque value of arbitrary length generated
          &nb= sp;           &nb= sp;    by the server


- Bernie


-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Wednesday, May 15, 2002 1:06 PM
To: dhcwg@ietf.org
Subject: [dhcwg] dhcpv6-24: Reconfigure


One IESG member has asked:

> 19. DHCP Server-Initiated Configuration = Exchange

> reconfigure messages provide such a wonderful = opportunity for
> attack.  and they are sent unicast = "using an IPv6 unicast address
> of sufficient scope belonging to the DHCP = client."

> possibly, the server could have intially = provided a nonce that the
> client retains for validation.  but this = precludes redundant server
> setups etc.

My response:

An interesting suggestion. Actually, it may not = preclude this.  The
idea behind the Reconfigure is that the server that = has state about
clients sends unicast Reconfigures to that client. = It is not intended
to be used to allow any old DHC server to prod a = client. So requiring
that the server also include a nonce may be OK. =
 
Question to the WG: should this be added? It would = add some additional
defense against improper Reconfigure.

Thoughts?
 
Thomas

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

------_=_NextPart_001_01C1FC34.6F519100-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:24:49 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 NAA14429; Wed, 15 May 2002 13:24: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 NAA14389; Wed, 15 May 2002 13:24: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 NAA14332 for ; Wed, 15 May 2002 13:24:42 -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 NAA14425 for ; Wed, 15 May 2002 13:24:28 -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 g4FHOfl19172 for ; Wed, 15 May 2002 12:24:41 -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 g4FHOf807227 for ; Wed, 15 May 2002 12:24:41 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed May 15 12:24:40 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:24:40 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D41B@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Temporary addresses Date: Wed, 15 May 2002 12:24:38 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC35.63CF22B0" 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_01C1FC35.63CF22B0 Content-Type: text/plain; charset="iso-8859-1" Ralph: I think all we wanted to do was to remove the prohibition against renewing IA_TA's. I don't think we want to drop the IA_TA concept or need to add T1/T2 times to the IA_TA option since the intent is NOT to renew these. If the client needs to continue using existing temporary addresses, it must initiate a Renew in time to renew them. The server can always have policy that would disallow this (for example if a renumbering event is happening). And, adding some comments that in a managed (stateful) addressing environment the RFC 3041 procedures basically trigger stateful requests for temporary addresses in place of the stateless autoconfiguration would be useful. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, May 15, 2002 1:11 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses At 11:11 AM 5/8/2002 -0400, Thomas Narten wrote: > > 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) OK (but see below). >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. I agree that the protocol software needs to identify temporary addresses so that applications can select for or against them. But, how does DHCP handle temporary and non-temp addresses differently? Is is just a tag that the server supplies and the protocol software interprets to identify temporary addresses or are there other differences? >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. OK - we can reference RFC3041 for that guidance... >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 ------_=_NextPart_001_01C1FC35.63CF22B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Temporary addresses

Ralph:

I think all we wanted to do was to remove the = prohibition against renewing IA_TA's. I don't think we want to drop the = IA_TA concept or need to add T1/T2 times to the IA_TA option since the = intent is NOT to renew these. If the client needs to continue using = existing temporary addresses, it must initiate a Renew in time to renew = them. The server can always have policy that would disallow this (for = example if a renumbering event is happening).

And, adding some comments that in a managed = (stateful) addressing environment the RFC 3041 procedures basically = trigger stateful requests for temporary addresses in place of the = stateless autoconfiguration would be useful.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, May 15, 2002 1:11 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: Temporary = addresses


At 11:11 AM 5/8/2002 -0400, Thomas Narten = wrote:
> >    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)

OK (but see below).


>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.

I agree that the protocol software needs to identify = temporary addresses so
that applications can select for or against = them.  But, how does DHCP
handle temporary and non-temp addresses = differently?  Is is just a tag that
the server supplies and the protocol software = interprets to identify
temporary addresses or are there other = differences?


>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.

OK - we can reference RFC3041 for that = guidance...


>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

------_=_NextPart_001_01C1FC35.63CF22B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:27: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 NAA14619; Wed, 15 May 2002 13:27:54 -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 NAA14609; Wed, 15 May 2002 13:26: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 NAA14560 for ; Wed, 15 May 2002 13:26:04 -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 NAA14510 for ; Wed, 15 May 2002 13:25:45 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-152.cisco.com [161.44.149.152]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA02962 for ; Wed, 15 May 2002 13:25:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20020515131449.03653718@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 May 2002 13:23:33 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] dhcpv6-24: vendor-specific issues In-Reply-To: <200205081514.g48FESQ19407@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 At 11:14 AM 5/8/2002 -0400, Thomas Narten wrote: > > 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? The idea is to support additional flexibility and precision in identifying clients in some deployments. This situation anticipates that clients will be configured to send additional classing information and servers will have policies to select configuration information based on those classes. Because both the clients and server have been "managed" for this deployment, they will interoperate. A client that moves and tries to use a server that does not have policies for the classes specified by the client, or a client that does not supply the class specifications will get configuration information that is not selected on the basis of the client classes. > > 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. This text is essentially copied directly from section 8.4 of RFC2132 (which, of course, doesn't necessarily make it a good idea). Perhaps the differentiation should be "enhanced operation" with the vendor-specific information versus "functioning operation" without? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:33: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 NAA14793; Wed, 15 May 2002 13:33: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 NAA15353; Wed, 15 May 2002 13:32: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 NAA15327 for ; Wed, 15 May 2002 13:32:20 -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 NAA14767 for ; Wed, 15 May 2002 13:32:06 -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 g4FHV1S07306; Wed, 15 May 2002 10:31:01 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4FHWGd01923; Wed, 15 May 2002 12:32:16 -0500 (CDT) Date: Wed, 15 May 2002 12:32:16 -0500 Subject: Re: [dhcwg] dhcpv6-24: compression in DNS names 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: <200205151659.g4FGxlj02153@cichlid.adsl.duke.edu> 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 > How about just removing the requirement to support compression. This > will simplify implementations and doesn't appear to result in any real > loss of functionality. Works for me. In the cases where we're using domain names, it's unlikely we'd be able to compress more than the last label anyway, so we're only talking about three bytes of compression (e.g., with .com). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:33:44 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 NAA14854; Wed, 15 May 2002 13:33:43 -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 NAA15441; Wed, 15 May 2002 13:33: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 NAA15421 for ; Wed, 15 May 2002 13:33:43 -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 NAA14839 for ; Wed, 15 May 2002 13:33:24 -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 g4FHXal24965 for ; Wed, 15 May 2002 12:33:36 -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 g4FHXa812619 for ; Wed, 15 May 2002 12:33:36 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 15 12:33:35 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:33:35 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D41D@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" , Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: compression in DNS names Date: Wed, 15 May 2002 12:33:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC36.A41C0DA0" 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_01C1FC36.A41C0DA0 Content-Type: text/plain; charset="iso-8859-1" I'm fine with it as well. There will likely be few cases where multiple domain names appear in a single option - so the savings will be small. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, May 15, 2002 1:32 PM To: Thomas Narten Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: compression in DNS names > How about just removing the requirement to support compression. This > will simplify implementations and doesn't appear to result in any real > loss of functionality. Works for me. In the cases where we're using domain names, it's unlikely we'd be able to compress more than the last label anyway, so we're only talking about three bytes of compression (e.g., with .com). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1FC36.A41C0DA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: compression in DNS names

I'm fine with it as well. There will likely be few = cases where multiple domain names appear in a single option - so the = savings will be small.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Wednesday, May 15, 2002 1:32 PM
To: Thomas Narten
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: compression in DNS = names


> How about just removing the requirement to = support compression. This
> will simplify implementations and doesn't = appear to result in any real
> loss of functionality.

Works for me.   In the cases where we're = using domain names, it's unlikely
we'd be able to compress more than the last label = anyway, so we're only
talking about three bytes of compression (e.g., with = .com).


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

------_=_NextPart_001_01C1FC36.A41C0DA0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:37: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 NAA15070; Wed, 15 May 2002 13:37: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 NAA15724; Wed, 15 May 2002 13:36: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 NAA15701 for ; Wed, 15 May 2002 13:36:52 -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 NAA15062 for ; Wed, 15 May 2002 13:36:36 -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 g4FHZWS07314; Wed, 15 May 2002 10:35:32 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4FHald01927; Wed, 15 May 2002 12:36:47 -0500 (CDT) Date: Wed, 15 May 2002 12:36:46 -0500 Subject: Re: [dhcwg] dhcpv6-w4: optional parts of spec 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: <200205151647.g4FGlar01969@cichlid.adsl.duke.edu> Message-Id: <5460A7FA-682A-11D6-B998-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 > If the WG wants to define several levels of implementations (like a > non-address supporting mode) that is one thing. But then the document > should make it clear what parts MUST be implemented in order to be > support a particular mode. But life would just be simpler if the spec > just said servers need to implement everything. I don't feel very strongly about this, but we did have a last-call objection to the protocol because someone wanted to have a simpler protocol for just getting information, and didn't want to have to implement the whole thing (indeed, argued that the whole thing wasn't useful, but that the partial implementation was). Do we just ignore that comment? Can we ignore it and get through last call? What about clients? Do we say that a client that only implements the information request/reply sequence isn't compliant? Is a client that doesn't implement fast commit non-compliant? What about a client that doesn't implement certain options? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:38: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 NAA15112; Wed, 15 May 2002 13:38: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 NAA15863; Wed, 15 May 2002 13:37:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA15841 for ; Wed, 15 May 2002 13:37:47 -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 NAA15104 for ; Wed, 15 May 2002 13:37:33 -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 g4FHbGi22584 for ; Wed, 15 May 2002 12:37:16 -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 g4FHbG814734 for ; Wed, 15 May 2002 12:37:16 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 15 12:37:15 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:37:15 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D41E@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: vendor-specific issues Date: Wed, 15 May 2002 12:37:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC37.24D3DDB0" 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_01C1FC37.24D3DDB0 Content-Type: text/plain; charset="iso-8859-1" Ralph: See below (BV>). -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, May 15, 2002 1:24 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: vendor-specific issues At 11:14 AM 5/8/2002 -0400, Thomas Narten wrote: > > 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? The idea is to support additional flexibility and precision in identifying clients in some deployments. This situation anticipates that clients will be configured to send additional classing information and servers will have policies to select configuration information based on those classes. Because both the clients and server have been "managed" for this deployment, they will interoperate. A client that moves and tries to use a server that does not have policies for the classes specified by the client, or a client that does not supply the class specifications will get configuration information that is not selected on the basis of the client classes. BV> Don't we have this kind of text in the DHCPv4 User Class option? Yes (see below) and why don't we use this text since that passed the IESG? This option MAY carry multiple User Classes. Servers may 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. > > 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. This text is essentially copied directly from section 8.4 of RFC2132 (which, of course, doesn't necessarily make it a good idea). Perhaps the differentiation should be "enhanced operation" with the vendor-specific information versus "functioning operation" without? BV> Yes, I like enhanced operation! - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1FC37.24D3DDB0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] dhcpv6-24: vendor-specific issues

Ralph:

See below (BV>).

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, May 15, 2002 1:24 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-24: vendor-specific issues


At 11:14 AM 5/8/2002 -0400, Thomas Narten wrote:
> >    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?

The idea is to support additional flexibility and precision in identifying
clients in some deployments.  This situation anticipates that clients will
be configured to send additional classing information and servers will have
policies to select configuration information based on those
classes.  Because both the clients and server have been "managed" for this
deployment, they will interoperate.  A client that moves and tries to use a
server that does not have policies for the classes specified by the client,
or a client that does not supply the class specifications will get
configuration information that is not selected on the basis of the client
classes.


BV> Don't we have this kind of text in the DHCPv4 User Class option? Yes (see
below) and why don't we use this text since that passed the IESG?

   This option MAY carry multiple User Classes.  Servers may 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.

> > 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.

This text is essentially copied directly from section 8.4 of RFC2132
(which, of course, doesn't necessarily make it a good idea).  Perhaps the
differentiation should be "enhanced operation" with the vendor-specific
information versus "functioning operation" without?

BV> Yes, I like enhanced operation!

- Ralph


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

------_=_NextPart_001_01C1FC37.24D3DDB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 13:45:23 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 NAA15361; Wed, 15 May 2002 13:45: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 NAA16302; Wed, 15 May 2002 13:44:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA16282 for ; Wed, 15 May 2002 13:44:15 -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 NAA15333 for ; Wed, 15 May 2002 13:44:01 -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 g4FHiDl01330 for ; Wed, 15 May 2002 12:44:13 -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 g4FHiD818545 for ; Wed, 15 May 2002 12:44:13 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed May 15 12:43:39 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 12:43:39 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D41F@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" , Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec Date: Wed, 15 May 2002 12:43:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC38.09F14720" 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_01C1FC38.09F14720 Content-Type: text/plain; charset="iso-8859-1" We should have two levels - Fully managed (to support Stateful Address Configuration) and something else for "Other Config" only. (Though it will get more complex as there is also the Prefix Delegation stuff that Ralph has been working on and that may be another subset.) A fully managed client/server must support: Solicit, Advertise, Request, Renew, Rebind, Confirm, Decline, Release, Reply, Reconfigure, Information-Request A "Other Config" must support: Information-Request, Reply (I'm less sure Reconfigure is REQUIRED in this case.) Rapid Commit is an optional feature for clients and servers (IMHO). That is also why an option is used to communicate it. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, May 15, 2002 1:37 PM To: Thomas Narten Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-w4: optional parts of spec > If the WG wants to define several levels of implementations (like a > non-address supporting mode) that is one thing. But then the document > should make it clear what parts MUST be implemented in order to be > support a particular mode. But life would just be simpler if the spec > just said servers need to implement everything. I don't feel very strongly about this, but we did have a last-call objection to the protocol because someone wanted to have a simpler protocol for just getting information, and didn't want to have to implement the whole thing (indeed, argued that the whole thing wasn't useful, but that the partial implementation was). Do we just ignore that comment? Can we ignore it and get through last call? What about clients? Do we say that a client that only implements the information request/reply sequence isn't compliant? Is a client that doesn't implement fast commit non-compliant? What about a client that doesn't implement certain options? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1FC38.09F14720 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-w4: optional parts of spec

We should have two levels - Fully managed (to support = Stateful Address Configuration) and something else for "Other = Config" only. (Though it will get more complex as there is also = the Prefix Delegation stuff that Ralph has been working on and that may = be another subset.)

A fully managed client/server must support:
        Solicit, = Advertise, Request, Renew, Rebind, Confirm, Decline, Release, Reply, = Reconfigure,
        Information-Request

A "Other Config" must support:
        Information-Request, Reply
        (I'm less = sure Reconfigure is REQUIRED in this case.)

Rapid Commit is an optional feature for clients and = servers (IMHO). That is also why an option is used to communicate = it.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Wednesday, May 15, 2002 1:37 PM
To: Thomas Narten
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-w4: optional parts of = spec


> If the WG wants to define several levels of = implementations (like a
> non-address supporting mode) that is one thing. = But then the document
> should make it clear what parts MUST be = implemented in order to be
> support a particular mode. But life would just = be simpler if the spec
> just said servers need to implement = everything.

I don't feel very strongly about this, but we did = have a last-call
objection to the protocol because someone wanted to = have a simpler protocol
for just getting information, and didn't want to = have to implement the
whole thing (indeed, argued that the whole thing = wasn't useful, but that
the partial implementation was).   Do we = just ignore that comment?   Can we
ignore it and get through last call?

What about clients?   Do we say that a = client that only implements the
information request/reply sequence isn't = compliant?   Is a client that
doesn't implement fast commit = non-compliant?   What about a client that
doesn't implement certain options?


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

------_=_NextPart_001_01C1FC38.09F14720-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 14:18: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 OAA16446; Wed, 15 May 2002 14:17: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 OAA18523; Wed, 15 May 2002 14:17:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18395 for ; Wed, 15 May 2002 14:16:09 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16419 for ; Wed, 15 May 2002 14:15:53 -0400 (EDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4FIG2801378 for ; Thu, 16 May 2002 03:16:02 +0900 (JST) Date: Thu, 16 May 2002 03:16:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 54 Subject: [dhcwg] additional comments on dhcpv6-24 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 have some additional comments (and questions) on dhcpv6-24, particularly about server solicitation. (1) If the client sent a solicit message with a rapid commit option but the server responds to the solicitation with an advertise message, what should the client do? Should it ignore the advertise, should it accept the advertise and send a request, or others? Section 17.1.4 says ...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, the client should probably ignore the advertise (and keep waiting for a reply.) But I'm not 100% sure about this. (2) Section 17.1.2 says: If the client is waiting for an Advertise message, the mechanism in section 14 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before IRT has elapsed. Rather, the client collects Advertise messages until IRT has elapsed. Should this rule apply if the client is retransmitting solicit messages? For example, suppose that there is no advertise in response to the first solicit, and so the client retransmit the solicit. If the client then receives a first advertise, should it still wait until IRT elapses? (3) The paragraph above then says: Also, the first RT MUST be selected to be strictly greater than IRT by choosing RAND to be strictly greater than 0. However, according to Section 13, the first RT should be RT = 2*IRT + RAND*IRT where RAND is a random number chosen with a uniform distribution between -0.1 and +0.1. Thus, RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT (the rightmost '=' is satisfied only when IRT is 0) So the RT should always be greater than IRT regardless of the value of RAND, and "by choosing RAND to be strictly greater than 0" seems to be redundant. Is my understanding correct? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 15:25:10 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 PAA18875; Wed, 15 May 2002 15:25:10 -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 PAA23430; Wed, 15 May 2002 15:23: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 PAA23404 for ; Wed, 15 May 2002 15:23:52 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18853 for ; Wed, 15 May 2002 15:23:37 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 75925596F; Wed, 15 May 2002 15:23:50 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 15:23:46 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: compression in DNS names Date: Wed, 15 May 2002 15:23:15 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8691@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: compression in DNS names Thread-Index: AcH8M3cTtNAvnCJzQRyWjV6LpIBYQAAEnSIg From: "Bound, Jim" To: "Thomas Narten" , X-OriginalArrivalTime: 15 May 2002 19:23:46.0841 (UTC) FILETIME=[08C96090:01C1FC46] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA23405 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 this makes sense for IPv6. /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Wednesday, May 15, 2002 1:00 PM > To: dhcwg@ietf.org > Subject: [dhcwg] dhcpv6-24: compression in DNS names > > > [Note: the IESG is starting to review this document, and I'm getting > questions comments on the ID]. > > This document specifies that DNS Names are represented in DNS > on-the-wire formate, and compression MUST be supported. I understand > that DHCPv4 supports this now (with recent options). > > But there is also complexity associated with the compression part. In > DHCPv4, options were limited in size (255 bytes). DHCPv6 doesn't have > this restriction. So the need for compression is reduced. > > How about just removing the requirement to support compression. This > will simplify implementations and doesn't appear to result in any real > loss of functionality. > > 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 dhcwg-admin@ietf.org Wed May 15 15:28:46 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 PAA19025; Wed, 15 May 2002 15:28:46 -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 PAA23787; Wed, 15 May 2002 15:28:30 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23714 for ; Wed, 15 May 2002 15:28:26 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19011 for ; Wed, 15 May 2002 15:28:11 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 4463959CA; Wed, 15 May 2002 15:28:25 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 15:28:25 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: Interface-ID option Date: Wed, 15 May 2002 15:28:24 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8692@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: Interface-ID option Thread-Index: AcH8M7frlBEg1yiwQO6irjkNVCUg0wAEo3yQ From: "Bound, Jim" To: "Ralph Droms" , X-OriginalArrivalTime: 15 May 2002 19:28:25.0006 (UTC) FILETIME=[AE95FCE0:01C1FC46] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA23715 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 the one place we need to be careful with the interface ID is if the link-address is link-local from the client. then the server has no clue regardless of the interface id. The server must look at the IP header from the relay to figure everything out. we should put the required scoped value of the address on the interface of the relay in the link address. or else the relay now needs to maintain state to find the client. I am not sure what the interface id is buying us but it is useful field for the future for sure I can think of many reasons such as a future partitioned IPv6 link. /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, May 15, 2002 1:00 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: Interface-ID option > > > At 11:09 AM 5/8/2002 -0400, Thomas Narten wrote: > > > 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 always fills in the link-address field even > if it also > includes an Interface-id option. Does the text need to be clarified? > > > > > 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. > > This text should be edited to (based on suggested text from Bernie): > > The relay agent fills in the link-address field as > described in the > previous > paragraph regardless of whether the relay agent includes > an Interface-id > option in the Relay-forward message. > > > > > 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. > > The link-address field does contain useful information (a > site-scoped or > global address); the Interface-ID provides additional 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. > > OK, we'll add some words about stability. > > > > > interface-id An opaque value of arbitrary > length generated > > > by the relay agent to identify > one of the > > > relay agent's interfaces > > > >Any reason not to make this 32 bits? the IPv6 API already has 32-bit > >interface IDs. Is there any reason to make it larger? > > The relay agent may use another value aside from the IPv6 API for the > interface-id, so we should allow for arbitrary length. > > - Ralph > > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 15:30: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 PAA19161; Wed, 15 May 2002 15:30: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 PAA23993; Wed, 15 May 2002 15:30:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA23963 for ; Wed, 15 May 2002 15:30:03 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19144 for ; Wed, 15 May 2002 15:29:47 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 003DA5B54; Wed, 15 May 2002 15:30:00 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 15:30:00 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [dhcwg] dhcpv6-24: Reconfigure Date: Wed, 15 May 2002 15:30:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8693@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: Reconfigure Thread-Index: AcH8NHBJFXPJU2rsQMe/2xhLcfhIuAAElwjg From: "Bound, Jim" To: "Thomas Narten" , X-OriginalArrivalTime: 15 May 2002 19:30:00.0600 (UTC) FILETIME=[E7907980:01C1FC46] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA23969 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 I am fine with this if my coauthors are and the wg. /jim > -----Original Message----- > From: Thomas Narten [mailto:narten@us.ibm.com] > Sent: Wednesday, May 15, 2002 1:06 PM > To: dhcwg@ietf.org > Subject: [dhcwg] dhcpv6-24: Reconfigure > > > One IESG member has asked: > > > 19. DHCP Server-Initiated Configuration Exchange > > > reconfigure messages provide such a wonderful opportunity for > > attack. and they are sent unicast "using an IPv6 unicast address > > of sufficient scope belonging to the DHCP client." > > > possibly, the server could have intially provided a nonce that the > > client retains for validation. but this precludes redundant server > > setups etc. > > My response: > > An interesting suggestion. Actually, it may not preclude this. The > idea behind the Reconfigure is that the server that has state about > clients sends unicast Reconfigures to that client. It is not intended > to be used to allow any old DHC server to prod a client. So requiring > that the server also include a nonce may be OK. > > Question to the WG: should this be added? It would add some additional > defense against improper Reconfigure. > > Thoughts? > > 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 dhcwg-admin@ietf.org Wed May 15 15:33: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 PAA19334; Wed, 15 May 2002 15:33: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 PAA24637; Wed, 15 May 2002 15:33:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24617 for ; Wed, 15 May 2002 15:33:04 -0400 (EDT) Received: from zmamail04.zma.compaq.com (zmamail04.zma.compaq.com [161.114.64.104]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19316 for ; Wed, 15 May 2002 15:32:48 -0400 (EDT) Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.103]) by zmamail04.zma.compaq.com (Postfix) with ESMTP id 83B165A55; Wed, 15 May 2002 15:33:01 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 15:33:01 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC47.52E445F0" Subject: RE: [dhcwg] dhcpv6-24: Temporary addresses Date: Wed, 15 May 2002 15:33:00 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8694@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: Temporary addresses Thread-Index: AcH8NXypwydHVemDQGSaXYIvYC12EwAEczlw From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Ralph Droms" , X-OriginalArrivalTime: 15 May 2002 19:33:01.0288 (UTC) FILETIME=[53434680:01C1FC47] 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_001_01C1FC47.52E445F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable this sounds good to me. /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, May 15, 2002 1:25 PM To: 'Ralph Droms'; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Temporary addresses Ralph:=20 I think all we wanted to do was to remove the prohibition against = renewing IA_TA's. I don't think we want to drop the IA_TA concept or = need to add T1/T2 times to the IA_TA option since the intent is NOT to = renew these. If the client needs to continue using existing temporary = addresses, it must initiate a Renew in time to renew them. The server = can always have policy that would disallow this (for example if a = renumbering event is happening). And, adding some comments that in a managed (stateful) addressing = environment the RFC 3041 procedures basically trigger stateful requests = for temporary addresses in place of the stateless autoconfiguration = would be useful. - Bernie=20 -----Original Message-----=20 From: Ralph Droms [ mailto:rdroms@cisco.com]=20 Sent: Wednesday, May 15, 2002 1:11 PM=20 To: dhcwg@ietf.org=20 Subject: Re: [dhcwg] dhcpv6-24: Temporary addresses=20 At 11:11 AM 5/8/2002 -0400, Thomas Narten wrote:=20 > > A server MUST return the same set of temporary address for the = same=20 > > IA_TA (as identified by the IAID) as long as those addresses are=20 > > still valid. After the lifetimes of the addresses in an IA_TA = have=20 > > expired, the IAID may be reused to identify a new IA_TA with new=20 > > temporary addresses.=20 >=20 >I don't think the above is what we want. A Client should be able to=20 >renew/extend lifetimes for temp addresses *if* they want. But in=20 >general, they won't. (Note this is also allowed in 3041 in the sense=20 >that this is left open as a possibility -- I don't see a need for DHC=20 >to preclude this from being done)=20 OK (but see below).=20 >Ralph asked:=20 >=20 > > 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=20 > > be extended, how are they different from non-temp addresses? Good=20 > > question to discuss in WG.=20 >=20 >They are different in that applications can specifically request that=20 >temp addresses be used for communication, *or* that temp addresses NOT=20 >be used. Thus, there has to be a way to distinguish between temp and=20 >non-temp addresses. Also, I believe that a node might be using several=20 >sets of temp addresses simultaneously. Normally, that would mean one=20 >set that is "preferred", but there could be a number of others that=20 >are "deprecated", meaning not to be used for new communication, but=20 >still available to the applications that are already using them. If an=20 >application is still using a temp address, it may need to extend the=20 >valid Lifetime to prevent the address from going away.=20 I agree that the protocol software needs to identify temporary addresses = so=20 that applications can select for or against them. But, how does DHCP=20 handle temporary and non-temp addresses differently? Is is just a tag = that=20 the server supplies and the protocol software interprets to identify=20 temporary addresses or are there other differences?=20 >This also raises a different point. There should be more text about=20 >when to get a new set of temp addresses. I.e., one could point to 3041=20 >for guidance on when to get a new one and use similar rules. I.e.,=20 >unlike permanent addresses, the normal action when a temporary address=20 >becomes deprecated is to request a new (i.e., different) one. The old=20 >one still remains for a while, but is being phased out. In contrast,=20 >for public/global addresses, the normal action is to renew the *same*=20 >address and extend its preferred lifetime.=20 >=20 > > An identity association for temporary addresses option MUST NOT=20 > > appear in a Renew or Rebind message. This option MAY appear in a = > > Confirm message if the lifetimes on the temporary addresses in = the=20 > > associated IA have not expired.=20 >=20 >If the client wants to extend a binding (perhaps an application is=20 >still using that address) it should not be prohibited by the=20 >protocol from doing so.=20 OK - we can reference RFC3041 for that guidance...=20 >Thomas=20 >=20 >_______________________________________________=20 >dhcwg mailing list=20 >dhcwg@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/dhcwg=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/dhcwg=20 ------_=_NextPart_001_01C1FC47.52E445F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Temporary addresses
this=20 sounds good to me.
/jim
-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday, May = 15, 2002=20 1:25 PM
To: 'Ralph Droms'; dhcwg@ietf.org
Subject: = RE:=20 [dhcwg] dhcpv6-24: Temporary addresses

Ralph:

I think all we wanted to do was to remove the = prohibition=20 against renewing IA_TA's. I don't think we want to drop the IA_TA = concept or=20 need to add T1/T2 times to the IA_TA option since the intent is NOT to = renew=20 these. If the client needs to continue using existing temporary = addresses, it=20 must initiate a Renew in time to renew them. The server can always = have policy=20 that would disallow this (for example if a renumbering event is=20 happening).

And, adding some comments that in a managed = (stateful)=20 addressing environment the RFC 3041 procedures basically trigger = stateful=20 requests for temporary addresses in place of the stateless = autoconfiguration=20 would be useful.

- Bernie

-----Original Message-----
From: Ralph=20 Droms [mailto:rdroms@cisco.com]=20
Sent: Wednesday, May 15, 2002 1:11 PM =
To: dhcwg@ietf.org
Subject: Re: = [dhcwg]=20 dhcpv6-24: Temporary addresses


At 11:11 AM 5/8/2002 -0400, Thomas Narten = wrote:=20
> >    A server MUST return = the same set=20 of temporary address for the same
>=20 >    IA_TA (as identified by the IAID) as long as = those=20 addresses are
> >    = still=20 valid.  After the lifetimes of the addresses in an IA_TA = have=20
> >    expired, the IAID may = be reused=20 to identify a new IA_TA with new
>=20 >    temporary addresses.
>
>I don't think the above is = what we=20 want. A Client should be able to
>renew/extend=20 lifetimes for temp addresses *if* they want. But in
>general, they won't. (Note this is also allowed in 3041 = in the=20 sense
>that this is left open as a = possibility -- I=20 don't see a need for DHC
>to preclude = this from=20 being done)

OK (but see below).


>Ralph asked:
>
> > The basic question is "can a client ask and a = server agree to=20 extend
> > the lifetimes on temp=20 addresses".  If lifetimes on temp addresses can
> > be extended, how are they different from non-temp=20 addresses?  Good
> > question to = discuss in=20 WG.
>
>They = are=20 different in that applications can specifically request that =
>temp addresses be used for communication, *or* that temp = addresses=20 NOT
>be used. Thus, there has to be a way = to=20 distinguish between temp and
>non-temp = addresses.=20 Also, I believe that a node might be using several
>sets of temp addresses simultaneously. Normally, that = would mean=20 one
>set that is "preferred", but there = could be a=20 number of others that
>are "deprecated", = meaning=20 not to be used for new communication, but
>still=20 available to the applications that are already using them. If = an=20
>application is still using a temp address, it = may need to=20 extend the
>valid Lifetime to prevent the = address=20 from going away.

I agree that the protocol software needs to identify = temporary=20 addresses so
that applications can select = for or=20 against them.  But, how does DHCP
handle=20 temporary and non-temp addresses differently?  Is is just a tag = that=20
the server supplies and the protocol = software=20 interprets to identify
temporary addresses = or are=20 there other differences?


>This also raises a different point. There should = be more=20 text about
>when to get a new set of temp = addresses. I.e., one could point to 3041
>for=20 guidance on when to get a new one and use similar rules. I.e.,=20
>unlike permanent addresses, the normal action = when a=20 temporary address
>becomes deprecated is = to request=20 a new (i.e., different) one. The old
>one = still=20 remains for a while, but is being phased out. In contrast, =
>for public/global addresses, the normal action is to = renew the=20 *same*
>address and extend its preferred=20 lifetime.
>
>=20 >    An identity association for temporary addresses = option=20 MUST NOT
> >    appear = in a Renew=20 or Rebind message.  This option MAY appear in a
> >    Confirm message if the lifetimes = on the=20 temporary addresses in the
> = >   =20 associated IA have not expired.
> =
>If the client wants to extend a binding (perhaps an = application=20 is
>still using that address) it should = not be=20 prohibited by the
>protocol from  = doing=20 so.

OK - we can reference RFC3041 for that = guidance...=20


>Thomas
> =
>_______________________________________________ =
>dhcwg mailing list
>dhcwg@ietf.org
>https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20


_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------_=_NextPart_001_01C1FC47.52E445F0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 15:33:35 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 PAA19375; Wed, 15 May 2002 15:33:35 -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 PAA24503; Wed, 15 May 2002 15:31: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 PAA24484 for ; Wed, 15 May 2002 15:31:45 -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 PAA19265 for ; Wed, 15 May 2002 15:31:29 -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 g4FJVDi25519 for ; Wed, 15 May 2002 14:31:13 -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 g4FJVDQ22271 for ; Wed, 15 May 2002 14:31:13 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed May 15 14:31:12 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 14:31:12 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D427@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Bound, Jim'" , Ralph Droms , dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Interface-ID option Date: Wed, 15 May 2002 14:31:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC47.0FB7DCF0" 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_01C1FC47.0FB7DCF0 Content-Type: text/plain; charset="iso-8859-1" The link-address field in the Relay-Forw header is not the client's address. It is the a global or site address assigned to the relay for the link on which the client's message was received (in some applications, it could even be the "subnet selection" value as in DHCPv4). - Bernie -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Wednesday, May 15, 2002 3:28 PM To: Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Interface-ID option the one place we need to be careful with the interface ID is if the link-address is link-local from the client. then the server has no clue regardless of the interface id. The server must look at the IP header from the relay to figure everything out. we should put the required scoped value of the address on the interface of the relay in the link address. or else the relay now needs to maintain state to find the client. I am not sure what the interface id is buying us but it is useful field for the future for sure I can think of many reasons such as a future partitioned IPv6 link. /jim > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, May 15, 2002 1:00 PM > To: dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6-24: Interface-ID option > > > At 11:09 AM 5/8/2002 -0400, Thomas Narten wrote: > > > 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 always fills in the link-address field even > if it also > includes an Interface-id option. Does the text need to be clarified? > > > > > 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. > > This text should be edited to (based on suggested text from Bernie): > > The relay agent fills in the link-address field as > described in the > previous > paragraph regardless of whether the relay agent includes > an Interface-id > option in the Relay-forward message. > > > > > 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. > > The link-address field does contain useful information (a > site-scoped or > global address); the Interface-ID provides additional 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. > > OK, we'll add some words about stability. > > > > > interface-id An opaque value of arbitrary > length generated > > > by the relay agent to identify > one of the > > > relay agent's interfaces > > > >Any reason not to make this 32 bits? the IPv6 API already has 32-bit > >interface IDs. Is there any reason to make it larger? > > The relay agent may use another value aside from the IPv6 API for the > interface-id, so we should allow for arbitrary length. > > - Ralph > > > > _______________________________________________ > 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_01C1FC47.0FB7DCF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Interface-ID option

The link-address field in the Relay-Forw header is = not the client's address. It is the a global or site address assigned = to the relay for the link on which the client's message was received = (in some applications, it could even be the "subnet = selection" value as in DHCPv4).

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Wednesday, May 15, 2002 3:28 PM
To: Ralph Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: Interface-ID = option


the one place we need to be careful with the = interface ID is if the link-address is link-local from the = client.  then the server has no clue regardless of the interface = id. The server must look at the IP header from the relay to figure = everything out. 

we should put the required scoped value of the = address on the interface of the relay in the link address.  or = else the relay now needs to maintain state to find the = client.

I am not sure what the interface id is buying us but = it is useful field for the future for sure I can think of many reasons = such as a future partitioned IPv6 link.

/jim

> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Wednesday, May 15, 2002 1:00 PM
> To: dhcwg@ietf.org
> Subject: Re: [dhcwg] dhcpv6-24: Interface-ID = option
>
>
> At 11:09 AM 5/8/2002 -0400, Thomas Narten = wrote:
> > >    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 always fills in the = link-address field even
> if it also
> includes an Interface-id option.  Does the = text need to be clarified?
>
>
> > >    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.
>
> This text should be edited to (based on = suggested text from Bernie):
>
>     The relay agent fills = in the link-address field as
> described in the
> previous
>     paragraph regardless of = whether the relay agent includes
> an Interface-id
>     option in the = Relay-forward message.
>
>
> > >    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.
>
> The link-address field does contain useful = information (a
> site-scoped or
> global address); the Interface-ID provides = additional 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.
>
> OK, we'll add some words about = stability.
>
>
> > >       = interface-id         An opaque = value of arbitrary
> length generated
> > = >           &n= bsp;           &n= bsp;    by the relay agent to identify
> one of the
> > = >           &n= bsp;           &n= bsp;    relay agent's interfaces
> >
> >Any reason not to make this 32 bits? the = IPv6 API already has 32-bit
> >interface IDs. Is there any reason to make = it larger?
>
> The relay agent may use another value aside = from the IPv6 API for the
> interface-id, so we should allow for arbitrary = length.
>
> - Ralph
>
>
>
> = _______________________________________________
> 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_01C1FC47.0FB7DCF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 15:35: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 PAA19486; Wed, 15 May 2002 15:35: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 PAA24833; Wed, 15 May 2002 15:35:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24764 for ; Wed, 15 May 2002 15:35:05 -0400 (EDT) Received: from zmamail05.zma.compaq.com (zmamail05.zma.compaq.com [161.114.64.105]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19476 for ; Wed, 15 May 2002 15:34:50 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail05.zma.compaq.com (Postfix) with ESMTP id 456059356; Wed, 15 May 2002 15:35:04 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 15:35:04 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC47.9C20AB98" Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec Date: Wed, 15 May 2002 15:35:03 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8695@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-w4: optional parts of spec Thread-Index: AcH8OGPVcUOtuKaFQNyJrd7Ao5xLgwADyPnw From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Ted Lemon" , "Thomas Narten" Cc: X-OriginalArrivalTime: 15 May 2002 19:35:04.0056 (UTC) FILETIME=[9C702F80:01C1FC47] 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_001_01C1FC47.9C20AB98 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't agree. This spec is for a fully compliant dhcpv6 server. that = last call comment can be addressed in another spec. =20 /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, May 15, 2002 1:44 PM To: 'Ted Lemon'; Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec We should have two levels - Fully managed (to support Stateful Address = Configuration) and something else for "Other Config" only. (Though it = will get more complex as there is also the Prefix Delegation stuff that = Ralph has been working on and that may be another subset.) A fully managed client/server must support:=20 Solicit, Advertise, Request, Renew, Rebind, Confirm, Decline, = Release, Reply, Reconfigure,=20 Information-Request=20 A "Other Config" must support:=20 Information-Request, Reply=20 (I'm less sure Reconfigure is REQUIRED in this case.)=20 Rapid Commit is an optional feature for clients and servers (IMHO). That = is also why an option is used to communicate it. - Bernie=20 -----Original Message-----=20 From: Ted Lemon [ mailto:Ted.Lemon@nominum.com]=20 Sent: Wednesday, May 15, 2002 1:37 PM=20 To: Thomas Narten=20 Cc: dhcwg@ietf.org=20 Subject: Re: [dhcwg] dhcpv6-w4: optional parts of spec=20 > If the WG wants to define several levels of implementations (like a=20 > non-address supporting mode) that is one thing. But then the document=20 > should make it clear what parts MUST be implemented in order to be=20 > support a particular mode. But life would just be simpler if the spec=20 > just said servers need to implement everything.=20 I don't feel very strongly about this, but we did have a last-call=20 objection to the protocol because someone wanted to have a simpler = protocol=20 for just getting information, and didn't want to have to implement the=20 whole thing (indeed, argued that the whole thing wasn't useful, but that = the partial implementation was). Do we just ignore that comment? Can = we=20 ignore it and get through last call?=20 What about clients? Do we say that a client that only implements the=20 information request/reply sequence isn't compliant? Is a client that=20 doesn't implement fast commit non-compliant? What about a client that=20 doesn't implement certain options?=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/dhcwg=20 ------_=_NextPart_001_01C1FC47.9C20AB98 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-w4: optional parts of spec
I=20 don't agree.  This spec is for a fully compliant dhcpv6 = server.  that=20 last call comment can be addressed in another spec.
 
/jim
-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday, May = 15, 2002=20 1:44 PM
To: 'Ted Lemon'; Thomas Narten
Cc:=20 dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-w4: optional = parts of=20 spec

We should have two levels - Fully managed (to = support Stateful=20 Address Configuration) and something else for "Other Config" only. = (Though it=20 will get more complex as there is also the Prefix Delegation stuff = that Ralph=20 has been working on and that may be another subset.)

A fully managed client/server must support:=20
        Solicit, = Advertise, Request, Renew, Rebind, Confirm, Decline, Release, Reply,=20 Reconfigure,
        = Information-Request

A "Other Config" must support:=20
        Information-Request, Reply=20
        (I'm = less sure=20 Reconfigure is REQUIRED in this case.)

Rapid Commit is an optional feature for clients and = servers=20 (IMHO). That is also why an option is used to communicate = it.

- Bernie

-----Original Message-----
From: Ted=20 Lemon [mailto:Ted.Lemon@nominum.com]=20
Sent: Wednesday, May 15, 2002 1:37 PM =
To: Thomas Narten
Cc: = dhcwg@ietf.org=20
Subject: Re: [dhcwg] dhcpv6-w4: optional parts of = spec=20


> If the WG wants to define several levels of=20 implementations (like a
> non-address = supporting=20 mode) that is one thing. But then the document
>=20 should make it clear what parts MUST be implemented in order to = be=20
> support a particular mode. But life would just = be=20 simpler if the spec
> just said servers = need to=20 implement everything.

I don't feel very strongly about this, but we did = have a=20 last-call
objection to the protocol because = someone=20 wanted to have a simpler protocol
for just = getting=20 information, and didn't want to have to implement the
whole thing (indeed, argued that the whole thing wasn't = useful, but=20 that
the partial implementation = was).   Do=20 we just ignore that comment?   Can we
ignore=20 it and get through last call?

What about clients?   Do we say that a = client that=20 only implements the
information = request/reply sequence=20 isn't compliant?   Is a client that
doesn't=20 implement fast commit non-compliant?   What about a client = that=20
doesn't implement certain options? =


_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------_=_NextPart_001_01C1FC47.9C20AB98-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 15:36: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 PAA19626; Wed, 15 May 2002 15:36:57 -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 PAA24940; Wed, 15 May 2002 15:36: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 PAA24921 for ; Wed, 15 May 2002 15:36:20 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19517 for ; Wed, 15 May 2002 15:36:05 -0400 (EDT) Received: from tayexg11.americas.cpqcorp.net (tayexg11.americas.cpqcorp.net [16.103.130.96]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id D6ADD8DA2; Wed, 15 May 2002 15:36:18 -0400 (EDT) Received: from tayexc13.americas.cpqcorp.net ([16.103.130.26]) by tayexg11.americas.cpqcorp.net with Microsoft SMTPSVC(5.0.2195.2966); Wed, 15 May 2002 15:36:18 -0400 x-mimeole: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC47.C88CBA1E" Subject: RE: [dhcwg] dhcpv6-24: Interface-ID option Date: Wed, 15 May 2002 15:36:18 -0400 Message-ID: <9C422444DE99BC46B3AD3C6EAFC9711B020B8696@tayexc13.americas.cpqcorp.net> Thread-Topic: [dhcwg] dhcpv6-24: Interface-ID option Thread-Index: AcH8RxtIrNpfaButS0OGFn12NOhijgAAJvcA From: "Bound, Jim" To: "Bernie Volz (EUD)" , "Ralph Droms" , X-OriginalArrivalTime: 15 May 2002 19:36:18.0633 (UTC) FILETIME=[C8E3BB90:01C1FC47] 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_001_01C1FC47.C88CBA1E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable that is what I interrept it to be also. but appears to be confusion. =20 /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, May 15, 2002 3:31 PM To: Bound, Jim; Ralph Droms; dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-24: Interface-ID option The link-address field in the Relay-Forw header is not the client's = address. It is the a global or site address assigned to the relay for = the link on which the client's message was received (in some = applications, it could even be the "subnet selection" value as in = DHCPv4). - Bernie=20 -----Original Message-----=20 From: Bound, Jim [ mailto:Jim.Bound@hp.com]=20 Sent: Wednesday, May 15, 2002 3:28 PM=20 To: Ralph Droms; dhcwg@ietf.org=20 Subject: RE: [dhcwg] dhcpv6-24: Interface-ID option=20 the one place we need to be careful with the interface ID is if the = link-address is link-local from the client. then the server has no clue = regardless of the interface id. The server must look at the IP header = from the relay to figure everything out. =20 we should put the required scoped value of the address on the interface = of the relay in the link address. or else the relay now needs to = maintain state to find the client. I am not sure what the interface id is buying us but it is useful field = for the future for sure I can think of many reasons such as a future = partitioned IPv6 link. /jim=20 > -----Original Message-----=20 > From: Ralph Droms [ mailto:rdroms@cisco.com]=20 > Sent: Wednesday, May 15, 2002 1:00 PM=20 > To: dhcwg@ietf.org=20 > Subject: Re: [dhcwg] dhcpv6-24: Interface-ID option=20 >=20 >=20 > At 11:09 AM 5/8/2002 -0400, Thomas Narten wrote:=20 > > > If the relay agent cannot use the address in the=20 > link-address field=20 > > > to identify the interface through which the response=20 > to the client=20 > > > will be forwarded, the relay agent MUST include an Interface-id = > > > option (see section 22.19) in the Relay-forward=20 > message. The server=20 > >=20 > >I think the interface-id option may be underspecified. If it is=20 > >included, but there is no valid link-address (which I understand is=20 > >the reason for defining this particular option), how does the server=20 > >know which addresses to assign the client? I.e., how does the server=20 > >know on which link the client is?=20 >=20 > The relay agent always fills in the link-address field even=20 > if it also=20 > includes an Interface-id option. Does the text need to be clarified?=20 >=20 >=20 > > > The relay agent puts the client's address in the=20 > link-address field=20 > > > regardless of whether the relay agent includes an=20 > Interface-id option=20 > > > in the Relay-forward message.=20 > >=20 > >This doesn't seem right to me. I thought that the link-address is=20 > >supposed to hold the address of the relay agent. Seems wrong to put=20 > >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=20 > >the client's address is a link-local address, this field doesn't seem = > >to contain useful information for the server in this case.=20 >=20 > This text should be edited to (based on suggested text from Bernie):=20 >=20 > The relay agent fills in the link-address field as=20 > described in the=20 > previous=20 > paragraph regardless of whether the relay agent includes=20 > an Interface-id=20 > option in the Relay-forward message.=20 >=20 >=20 > > > Servers MAY use the Interface-ID for parameter=20 > assignment policies.=20 > > > The Interface-ID SHOULD be considered an opaque value,=20 > with policies=20 > > > based on exact string match only; that is, the=20 > Interface-ID SHOULD=20 > > > NOT be internally parsed by the server.=20 > >=20 > >Shouldn't the first MAY be a MUST? I.e., the link-address field=20 > >contains no useful information.=20 >=20 > The link-address field does contain useful information (a=20 > site-scoped or=20 > global address); the Interface-ID provides additional information.=20 >=20 > >Also, not sure the above is sufficient. Unless the=20 > >interface-identifier is somehow stable, it's not clear how the server = > >policy could take it into account. There are no words suggesting the=20 > >interface-identifier needs to be stable.=20 >=20 > OK, we'll add some words about stability.=20 >=20 >=20 > > > interface-id An opaque value of arbitrary=20 > length generated=20 > > > by the relay agent to identify=20 > one of the=20 > > > relay agent's interfaces=20 > >=20 > >Any reason not to make this 32 bits? the IPv6 API already has 32-bit=20 > >interface IDs. Is there any reason to make it larger?=20 >=20 > The relay agent may use another value aside from the IPv6 API for the=20 > interface-id, so we should allow for arbitrary length.=20 >=20 > - Ralph=20 >=20 >=20 >=20 > _______________________________________________=20 > dhcwg mailing list=20 > dhcwg@ietf.org=20 > https://www1.ietf.org/mailman/listinfo/dhcwg=20 >=20 _______________________________________________=20 dhcwg mailing list=20 dhcwg@ietf.org=20 https://www1.ietf.org/mailman/listinfo/dhcwg=20 ------_=_NextPart_001_01C1FC47.C88CBA1E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-24: Interface-ID option
that=20 is what I interrept it to be also.  but appears to be=20 confusion.
 
/jim
-----Original Message-----
From: Bernie Volz (EUD)=20 [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday, May = 15, 2002=20 3:31 PM
To: Bound, Jim; Ralph Droms;=20 dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-24: Interface-ID=20 option

The link-address field in the Relay-Forw header is = not the=20 client's address. It is the a global or site address assigned to the = relay for=20 the link on which the client's message was received (in some = applications, it=20 could even be the "subnet selection" value as in DHCPv4).

- Bernie

-----Original Message-----
From:=20 Bound, Jim [mailto:Jim.Bound@hp.com] =
Sent: Wednesday, May 15, 2002 3:28 PM
To: Ralph=20 Droms; dhcwg@ietf.org
Subject: RE: [dhcwg] = dhcpv6-24:=20 Interface-ID option


the one place we need to be careful with the = interface ID is=20 if the link-address is link-local from the client.  then the = server has=20 no clue regardless of the interface id. The server must look at the IP = header=20 from the relay to figure everything out. 

we should put the required scoped value of the = address on the=20 interface of the relay in the link address.  or else the relay = now needs=20 to maintain state to find the client.

I am not sure what the interface id is buying us but = it is=20 useful field for the future for sure I can think of many reasons such = as a=20 future partitioned IPv6 link.

/jim

> -----Original Message-----
>=20 From: Ralph Droms [mailto:rdroms@cisco.com] =
> Sent: Wednesday, May 15, 2002 1:00 PM
>=20 To: dhcwg@ietf.org
> Subject: Re: [dhcwg] = dhcpv6-24: Interface-ID option
> =
>
> At 11:09 AM 5/8/2002 = -0400, Thomas=20 Narten wrote:
> > = >    If the=20 relay agent cannot use the address in the
>=20 link-address field
> > = >    to=20 identify the interface through which the response
>=20 to the client
> > = >    will be=20 forwarded, the relay agent MUST include an Interface-id =
> > >    option (see section 22.19) = in the=20 Relay-forward
> message.  The = server=20
> >
> >I = think the=20 interface-id option may be underspecified. If it is
> >included, but there is no valid link-address (which = I=20 understand is
> >the reason for = defining this=20 particular option), how does the server
> = >know=20 which addresses to assign the client? I.e., how does the server =
> >know on which link the client is? =
>
> The relay agent always = fills in the=20 link-address field even
> if it also=20
> includes an Interface-id option.  = Does the=20 text need to be clarified?
> =
>
> > = >    The relay=20 agent puts the client's address in the
>=20 link-address field
> > = >   =20 regardless of whether the relay agent includes an
>=20 Interface-id option
> > = >   =20 in the Relay-forward message.
> = >=20
> >This doesn't seem right to me. I thought = that the=20 link-address is
> >supposed to hold = the address=20 of the relay agent. Seems wrong to put
> = >the=20 client's address in it. The link-address field is what the = server=20
> >uses to figure out which link the client = is on=20 (right?). Also, since
> >the client's = address is=20 a link-local address, this field doesn't seem
>=20 >to contain useful information for the server in this case.=20
>
> This text = should be edited=20 to (based on suggested text from Bernie):
>=20
>     The relay agent = fills in=20 the link-address field as
> described in = the=20
> previous
>     paragraph regardless of whether = the relay=20 agent includes
> an Interface-id =
>     option in the Relay-forward=20 message.
>
> =
> > >    Servers MAY = use the=20 Interface-ID for parameter
> assignment=20 policies.
> > >    = The=20 Interface-ID SHOULD be considered an opaque value,
> with policies
> >=20 >    based on exact string match only; that is, the=20
> Interface-ID SHOULD
>=20 > >    NOT be internally parsed by the = server.=20
> >
> = >Shouldn't the=20 first MAY be a MUST? I.e., the link-address field
>=20 >contains no useful information.
>=20
> The link-address field does contain = useful=20 information (a
> site-scoped or =
> global address); the Interface-ID provides additional=20 information.
>
>=20 >Also, not sure the above is sufficient. Unless the =
> >interface-identifier is somehow stable, it's not = clear how the=20 server
> >policy could take it into = account.=20 There are no words suggesting the
>=20 >interface-identifier needs to be stable.
>=20
> OK, we'll add some words about = stability.=20
>
> =
> > >      =20 interface-id         An opaque = value=20 of arbitrary
> length generated =
> >=20 = >           &nb= sp;           &nbs= p;   =20 by the relay agent to identify
> one of = the=20
> >=20 = >           &nb= sp;           &nbs= p;   =20 relay agent's interfaces
> > =
> >Any reason not to make this 32 bits? the IPv6 API = already has=20 32-bit
> >interface IDs. Is there any = reason to=20 make it larger?
>
> The=20 relay agent may use another value aside from the IPv6 API for = the=20
> interface-id, so we should allow for arbitrary = length.
>
> = -=20 Ralph
>
>=20
>
>=20 _______________________________________________
>=20 dhcwg mailing list
> = dhcwg@ietf.org=20
> https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20
>

_______________________________________________=20
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/dhcwg=20

------_=_NextPart_001_01C1FC47.C88CBA1E-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 15:37: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 PAA19665; Wed, 15 May 2002 15:37: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 PAA25133; Wed, 15 May 2002 15:37: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 PAA25108 for ; Wed, 15 May 2002 15:37:16 -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 PAA19650 for ; Wed, 15 May 2002 15:37:01 -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 g4FJaji28808 for ; Wed, 15 May 2002 14:36:45 -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 g4FJaiQ24516 for ; Wed, 15 May 2002 14:36:44 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 15 14:36:43 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 14:36:43 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D428@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'JINMEI Tatuya / ????'" , dhcwg@ietf.org Subject: RE: [dhcwg] additional comments on dhcpv6-24 Date: Wed, 15 May 2002 14:36:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC47.D3DF7840" 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_01C1FC47.D3DF7840 Content-Type: text/plain; charset="iso-2022-jp" Jinmei: Regarding (1), based on -24 the server shouldn't be sending an Advertise. And, yes, I think your assumption that the client should discard it is correct. Having said that, I would like to see the Rapid Commit change to be more of just an option. A server set up to respond to Rapid Commit would send the Reply. Other servers could send an Advertise. The client would use the Reply if received; otherwise simply start using the Advertises as if a Solicit w/o Rapid Commit was done. Regarding (2), good question ... I would say it should. The logic might simply be send a Solicit, wait IRT, check if any Advertises received ... if so, go use them otherwise send Solicit again. Regarding (3), your understanding is correct. I can't see that it hurts for us to indicate that RAND be greater than 0. - Bernie -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Wednesday, May 15, 2002 2:17 PM To: dhcwg@ietf.org Subject: [dhcwg] additional comments on dhcpv6-24 I have some additional comments (and questions) on dhcpv6-24, particularly about server solicitation. (1) If the client sent a solicit message with a rapid commit option but the server responds to the solicitation with an advertise message, what should the client do? Should it ignore the advertise, should it accept the advertise and send a request, or others? Section 17.1.4 says ...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, the client should probably ignore the advertise (and keep waiting for a reply.) But I'm not 100% sure about this. (2) Section 17.1.2 says: If the client is waiting for an Advertise message, the mechanism in section 14 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before IRT has elapsed. Rather, the client collects Advertise messages until IRT has elapsed. Should this rule apply if the client is retransmitting solicit messages? For example, suppose that there is no advertise in response to the first solicit, and so the client retransmit the solicit. If the client then receives a first advertise, should it still wait until IRT elapses? (3) The paragraph above then says: Also, the first RT MUST be selected to be strictly greater than IRT by choosing RAND to be strictly greater than 0. However, according to Section 13, the first RT should be RT = 2*IRT + RAND*IRT where RAND is a random number chosen with a uniform distribution between -0.1 and +0.1. Thus, RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT (the rightmost '=' is satisfied only when IRT is 0) So the RT should always be greater than IRT regardless of the value of RAND, and "by choosing RAND to be strictly greater than 0" seems to be redundant. Is my understanding correct? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1FC47.D3DF7840 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] additional comments on dhcpv6-24

Jinmei:

Regarding (1), based on -24 the server shouldn't be = sending an Advertise. And, yes, I think your assumption that the client = should discard it is correct. Having said that, I would like to see the = Rapid Commit change to be more of just an option. A server set up to = respond to Rapid Commit would send the Reply. Other servers could send = an Advertise. The client would use the Reply if received; otherwise = simply start using the Advertises as if a Solicit w/o Rapid Commit was = done.

Regarding (2), good question ... I would say it = should. The logic might simply be send a Solicit, wait IRT, check if = any Advertises received ... if so, go use them otherwise send Solicit = again.

Regarding (3), your understanding is correct. I can't = see that it hurts for us to indicate that RAND be greater than = 0.

- Bernie

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshi= ba.co.jp]
Sent: Wednesday, May 15, 2002 2:17 PM
To: dhcwg@ietf.org
Subject: [dhcwg] additional comments on = dhcpv6-24


I have some additional comments (and questions) on = dhcpv6-24,
particularly about server solicitation.

(1) If the client sent a solicit message with a rapid = commit option
    but the server responds to the = solicitation with an advertise
    message, what should the client = do?  Should it ignore the
    advertise, should it accept the = advertise and send a request, or
    others?  Section 17.1.4 = says

     ...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, the client should probably ignore = the advertise (and keep
   waiting for a reply.)  But I'm not = 100% sure about this.

(2) Section 17.1.2 says:

   If the client is waiting for an = Advertise message, the mechanism in
   section 14 is modified as follows for = use in the transmission of
   Solicit messages.  The message = exchange is not terminated by the
   receipt of an Advertise before IRT has = elapsed.  Rather, the client
   collects Advertise messages until IRT = has elapsed.

Should this rule apply if the client is = retransmitting solicit
messages?  For example, suppose that there is = no advertise in response
to the first solicit, and so the client retransmit = the solicit.  If
the client then receives a first advertise, should = it still wait until
IRT elapses?

(3) The paragraph above then says:
   Also, the first
   RT MUST be selected to be strictly = greater than IRT by choosing RAND
   to be strictly greater than 0.

However, according to Section 13, the first RT should = be

      RT =3D 2*IRT + = RAND*IRT

where  RAND is a random number chosen with a = uniform distribution
between -0.1 and +0.1.  Thus,

      RT >=3D 2*IRT - = 0.1*IRT =3D 1.9 * IRT >=3D IRT
      (the rightmost '=3D' = is satisfied only when IRT is 0)

So the RT should always be greater than IRT = regardless of the value of
RAND, and "by choosing RAND to be strictly = greater than 0" seems to be
redundant.  Is my understanding correct?

        =         =         =         =         JINMEI, = Tatuya
        =         =         =         =         Communication = Platform Lab.
        =         =         =         =         Corporate = R&D Center, Toshiba Corp.
        =         =         =         =         jinmei@isl.rdc.toshiba.co.jp


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

------_=_NextPart_001_01C1FC47.D3DF7840-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 15:38: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 PAA19732; Wed, 15 May 2002 15:38: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 PAA25286; Wed, 15 May 2002 15:38: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 PAA25200 for ; Wed, 15 May 2002 15:38:11 -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 PAA19691 for ; Wed, 15 May 2002 15:37:56 -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 g4FJc9l10272 for ; Wed, 15 May 2002 14:38:09 -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 g4FJc9826176 for ; Wed, 15 May 2002 14:38:09 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed May 15 14:38:08 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 14:38:08 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D429@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Bound, Jim'" , Ted Lemon , Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec Date: Wed, 15 May 2002 14:38:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC48.08722DF0" 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_01C1FC48.08722DF0 Content-Type: text/plain; charset="iso-8859-1" Jim ... based on the further discussion and thought, I agree with you. -----Original Message----- From: Bound, Jim [mailto:Jim.Bound@hp.com] Sent: Wednesday, May 15, 2002 3:35 PM To: Bernie Volz (EUD); Ted Lemon; Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec I don't agree. This spec is for a fully compliant dhcpv6 server. that last call comment can be addressed in another spec. /jim -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Wednesday, May 15, 2002 1:44 PM To: 'Ted Lemon'; Thomas Narten Cc: dhcwg@ietf.org Subject: RE: [dhcwg] dhcpv6-w4: optional parts of spec We should have two levels - Fully managed (to support Stateful Address Configuration) and something else for "Other Config" only. (Though it will get more complex as there is also the Prefix Delegation stuff that Ralph has been working on and that may be another subset.) A fully managed client/server must support: Solicit, Advertise, Request, Renew, Rebind, Confirm, Decline, Release, Reply, Reconfigure, Information-Request A "Other Config" must support: Information-Request, Reply (I'm less sure Reconfigure is REQUIRED in this case.) Rapid Commit is an optional feature for clients and servers (IMHO). That is also why an option is used to communicate it. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, May 15, 2002 1:37 PM To: Thomas Narten Cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-w4: optional parts of spec > If the WG wants to define several levels of implementations (like a > non-address supporting mode) that is one thing. But then the document > should make it clear what parts MUST be implemented in order to be > support a particular mode. But life would just be simpler if the spec > just said servers need to implement everything. I don't feel very strongly about this, but we did have a last-call objection to the protocol because someone wanted to have a simpler protocol for just getting information, and didn't want to have to implement the whole thing (indeed, argued that the whole thing wasn't useful, but that the partial implementation was). Do we just ignore that comment? Can we ignore it and get through last call? What about clients? Do we say that a client that only implements the information request/reply sequence isn't compliant? Is a client that doesn't implement fast commit non-compliant? What about a client that doesn't implement certain options? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1FC48.08722DF0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] dhcpv6-w4: optional parts of spec

Jim ... based on the further discussion and thought, = I agree with you.

-----Original Message-----
From: Bound, Jim [mailto:Jim.Bound@hp.com]
Sent: Wednesday, May 15, 2002 3:35 PM
To: Bernie Volz (EUD); Ted Lemon; Thomas = Narten
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-w4: optional parts of = spec


I don't agree.  This spec is for a fully = compliant dhcpv6 server.  that last call comment can be addressed = in another spec.

/jim
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.erics= son.se]
Sent: Wednesday, May 15, 2002 1:44 PM
To: 'Ted Lemon'; Thomas Narten
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] dhcpv6-w4: optional parts of = spec


We should have two levels - Fully managed (to support = Stateful Address Configuration) and something else for "Other = Config" only. (Though it will get more complex as there is also = the Prefix Delegation stuff that Ralph has been working on and that may = be another subset.)

A fully managed client/server must support:
        Solicit, = Advertise, Request, Renew, Rebind, Confirm, Decline, Release, Reply, = Reconfigure,
        = Information-Request
A "Other Config" must support:
        = Information-Request, Reply
        (I'm less = sure Reconfigure is REQUIRED in this case.)
Rapid Commit is an optional feature for clients and = servers (IMHO). That is also why an option is used to communicate = it.

- Bernie
-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com] =
Sent: Wednesday, May 15, 2002 1:37 PM
To: Thomas Narten
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6-w4: optional parts of = spec


> If the WG wants to define several levels of = implementations (like a
> non-address supporting mode) that is one thing. = But then the document
> should make it clear what parts MUST be = implemented in order to be
> support a particular mode. But life would just = be simpler if the spec
> just said servers need to implement everything. =
I don't feel very strongly about this, but we did = have a last-call
objection to the protocol because someone wanted to = have a simpler protocol
for just getting information, and didn't want to = have to implement the
whole thing (indeed, argued that the whole thing = wasn't useful, but that
the partial implementation was).   Do we = just ignore that comment?   Can we
ignore it and get through last call?
What about clients?   Do we say that a = client that only implements the
information request/reply sequence isn't = compliant?   Is a client that
doesn't implement fast commit = non-compliant?   What about a client that
doesn't implement certain options?


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

------_=_NextPart_001_01C1FC48.08722DF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 15:40: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 PAA19807; Wed, 15 May 2002 15:40: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 PAA25360; Wed, 15 May 2002 15:39: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 PAA25043 for ; Wed, 15 May 2002 15:36:56 -0400 (EDT) Received: from webmail23.rediffmail.com (webmail23.rediffmail.com [203.199.83.33] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19603 for ; Wed, 15 May 2002 15:36:41 -0400 (EDT) Received: (qmail 31651 invoked by uid 510); 15 May 2002 19:36:06 -0000 Date: 15 May 2002 19:36:06 -0000 Message-ID: <20020515193606.31650.qmail@webmail23.rediffmail.com> Received: from unknown (218.44.132.46) by rediffmail.com via HTTP; 15 May 2002 19:36:06 -0000 MIME-Version: 1.0 From: "prasanth nair" Reply-To: "prasanth nair" To: dhcwg@ietf.org Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [dhcwg] help me 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 hi, i am prasanth nair here, i was trying to dhcp installtion, i am facing a probelem pls help. i configured dhcpd.conf and one connection is going to global and other eth1 is going to hub.i think my config, all right like mask,inet add. etc. after all i cant ping the ip from the client m/c i am getting all site from the server also.i think global part is clear.only dhcp part went wrong.but restarting gives correct. what will be the common problems.. bye _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 15:40: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 PAA19830; Wed, 15 May 2002 15:40:21 -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 PAA25385; Wed, 15 May 2002 15:39:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA24876 for ; Wed, 15 May 2002 15:35:56 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19508 for ; Wed, 15 May 2002 15:35:41 -0400 (EDT) Received: from webmail15.rediffmail.com (webmail15.rediffmail.com [203.199.83.25] (may be forged)) by mail.bucknell.edu (8.11.6/8.11.6) with SMTP id g4FJZ8H29232 for ; Wed, 15 May 2002 15:35:08 -0400 (EDT) Received: (qmail 28041 invoked by uid 510); 15 May 2002 19:34:47 -0000 Date: 15 May 2002 19:34:47 -0000 Message-ID: <20020515193447.28040.qmail@webmail15.rediffmail.com> Received: from unknown (218.44.132.46) by rediffmail.com via HTTP; 15 May 2002 19:34:47 -0000 MIME-Version: 1.0 From: "prasanth nair" Reply-To: "prasanth nair" To: dhcp-v4@bucknell.edu Content-type: text/plain; format=flowed Content-Disposition: inline Subject: [dhcwg] dhcp problem help me urgent 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 hi, i am prasanth nair here, i was trying to dhcp installtion, i am facing a probelem pls help. i configured dhcpd.conf and one connection is going to global and other eth1 is going to hub.i think my config, all right like mask,inet add. etc. after all i cant ping the ip from the client m/c i am getting all site from the server also.i think global part is clear.only dhcp part went wrong.but restarting gives correct. what will be the common problems.. bye _________________________________________________________ Click below to visit monsterindia.com and review jobs in India or Abroad http://monsterindia.rediff.com/jobs _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 15:46: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 PAA20078; Wed, 15 May 2002 15:46: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 PAA25988; Wed, 15 May 2002 15:45: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 PAA25780 for ; Wed, 15 May 2002 15:43:12 -0400 (EDT) Received: from c003.snv.cp.net (h015.c003.snv.cp.net [209.228.32.229]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19970 for ; Wed, 15 May 2002 15:42:57 -0400 (EDT) Received: (cpmta 28859 invoked from network); 15 May 2002 12:42:33 -0700 Received: from 209.228.32.226 (HELO mail.telocity.com.criticalpath.net) by smtp.telocity.com (209.228.32.229) with SMTP; 15 May 2002 12:42:33 -0700 X-Sent: 15 May 2002 19:42:33 GMT Received: from [64.34.188.157] by mail.telocity.com with HTTP; Wed, 15 May 2002 12:42:28 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 7bit MIME-Version: 1.0 To: scoya@cnri.reston.va.us, iesg@ietf.org, iesg-secretary@ietf.org Cc: dhcwg@ietf.org, rdroms@cisco.com From: "Eugene Terrell" X-Sent-From: eterrell@telocity.com Date: Wed, 15 May 2002 12:42:28 -0700 (PDT) X-Mailer: Web Mail 5.0.8-8 Message-Id: <20020515124233.4687.h012.c003.wm@mail.telocity.com.criticalpath.net> Content-Transfer-Encoding: 7bit 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 Content-Transfer-Encoding: 7bit IESG / IETF / IAB / ISOC / IRTF COMMITTEE AND STAFF Notice of Rebuttal: This is a formal notice of rebuttal, which is maintained against the assignment for DHCPv6 to the Status of Standard: 1. (page 14, sect 9.2) "Despite our best efforts, it is possible that this algorithm for generating a DUID could result in a client identifier collision. 2. What is the IP Bit Mapped Address Space Defined by the Headers? Can not discern Bit displacement for either Unicast ot Multicast Address? In other words, while the Communication can be a 32 IP Bit Mapped Address Space, I thought it was a 128 Bit. E.g: 1. Multicast Addresses | 8 | 4 | 4 | 112 bits | +------ -+----+----+------------+ |11111111|FLGS|SCOP| GROUP ID | +--------+----+----+------------+ 2. Provider Based Unicast Addresses | 3 | n bits | m bits | +---+-----------+-----------+ |010|REGISTRY ID|PROVIDER ID| +---+-----------+-----------+ o bits | p bits | o-p bits | -------------+---------+----------+ SUBSCRIBER ID|SUBNET ID| INTF. ID | -------------+---------+----------+ In other words, my belief is that knowone actually understood the IPv4 specification, which meant that is was never fully exploited. And it does not matter whether or not the discussion invloves DHCP, DNS, or IP Addressing in General. So, my rebuttal deals specifically with whether or not anyone understand the IPv6 specification well enough that it should be implemented. At least, a further clarification regarding the IP Bit Mapped Address Space size is needed. Remember; KISS! Steve, yes! I have completed the IPtX IP Addressing Protocol Family Specification. And while I was hoping that my Internet Draft writing career was over. It seems as though, I am required to write another Draft, and this time it deal specifically with DNS Service, Routing, APRA, and IN-ADD. APRA Addressing. Nevertheless, I know that you, nor Fred would consider this Rebuttal as an unconscionable act, because that which I have said is not only true, but it is indeed easily varifiable. Sincerely, E. Terrell PS: Steve, the shock I gave you nearly 3 years ago, is unquestionable now. 1. http://www.ietf.org/internet-drafts/draft-terrell-visual-change-redefining-role-ipv6-01.txt 2. http://www.ietf.org/internet-drafts/draft-terrell-simple-proof-support-logic-analy-bin-02.txt 3. http://www.ietf.org/internet-drafts/draft-terrell-math-quant-new-para-redefi-bin-math-03.txt 4. http://www.ietf.org/internet-drafts/ draft-terrell-schem-desgn-ipt1-ipt2-cmput-tel-numb-01.txt 5. http://www.ietf.org/internet-drafts/draft-terrell-logic-analy-bin-ip-spec-ipv7-ipv8-10.txt 6. http://www.ietf.org/internet-drafts/draft-terrell-internet-protocol-t1-t2-ad-sp-06.txt 7. http://www.ietf.org/internet-drafts/draft-terrell-iptx-spec-def-cidr-ach-net-descrip-01.txt 8. http://www.ietf.org/internet-drafts/draft-terrell-gwebs-vs-ieps-00.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 16:05:04 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 QAA20740; Wed, 15 May 2002 16:05: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 QAA27826; Wed, 15 May 2002 16:04: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 QAA27800 for ; Wed, 15 May 2002 16:04:41 -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 QAA20720 for ; Wed, 15 May 2002 16:04: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 g4FK1VS07754; Wed, 15 May 2002 13:01:31 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4FK2kd02002; Wed, 15 May 2002 15:02:46 -0500 (CDT) Date: Wed, 15 May 2002 15:02:45 -0500 Subject: Re: [dhcwg] additional comments on dhcpv6-24 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: dhcwg@ietf.org, "'JINMEI Tatuya / ????'" To: "Bernie Volz (EUD)" From: Ted Lemon In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D428@EAMBUNT705> 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 > Regarding (2), good question ... I would say it should. The logic might > simply be send a Solicit, wait IRT, check if any Advertises received ... > if so, go use them otherwise send Solicit again. I think it makes more sense to say that if IRT has elapsed since the first Solicit was sent, the client just takes the first Advertise it gets. This is how I implemented the ISC DHCPv4 client, and it seems to work pretty nicely. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 16:06:47 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 QAA20812; Wed, 15 May 2002 16:06:47 -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 QAA28012; Wed, 15 May 2002 16:06: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 QAA27993 for ; Wed, 15 May 2002 16:06:23 -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 QAA20800 for ; Wed, 15 May 2002 16:06:07 -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 g4FK51S07765; Wed, 15 May 2002 13:05:01 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4FK6Gd02006; Wed, 15 May 2002 15:06:16 -0500 (CDT) Date: Wed, 15 May 2002 15:06:15 -0500 Subject: Re: [dhcwg] "Options" field Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "'Katia Linker'" , DHCP IETF mailing list To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D19849587E@homer.incognito.com.> Message-Id: <364E5DF8-683F-11D6-B998-00039367340A@nominum.com> X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id QAA27994 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 > Probably the size of a UDP packet (minus the size of the header... 200 or > so bytes).  However, clients can tell the server that they can only accept > messages up to size X (there's an option for it). No offense, but why are you answering someone's question about what the RFC says when you haven't looked the answer up in the RFC? From RFC2131: The 'options' field is now variable length. A DHCP client must be prepared to receive DHCP messages with an 'options' field of at least length 312 octets. This requirement implies that a DHCP client must be prepared to receive a message of up to 576 octets, the minimum IP Droms Standards Track [Page 10] RFC 2131 Dynamic Host Configuration Protocol March 1997 datagram size an IP host must be prepared to accept [3]. DHCP _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 16:16: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 QAA21033; Wed, 15 May 2002 16:16: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 QAA28523; Wed, 15 May 2002 16:15:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28500 for ; Wed, 15 May 2002 16:15:45 -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 QAA21001 for ; Wed, 15 May 2002 16:15: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 17853M-0006mV-00; Wed, 15 May 2002 13:07:16 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <2ZV8SRA0>; Wed, 15 May 2002 13:21:53 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D19849589D@homer.incognito.com.> From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: "'Katia Linker'" , DHCP IETF mailing list Subject: RE: [dhcwg] "Options" field Date: Wed, 15 May 2002 13:21:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC4E.21E97080" 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_01C1FC4E.21E97080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The original poster did ask what the _maximum_ length the options field = may be (not the minimum), and he did mention that he already knew that the minimum was 312 bytes. That passage from the RFC does not mention the maximum size, only the minimum size. It does continue to say that if = the client can handle larger message sizes it should supply option 57 to negotiate the larger sized packets. > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Wednesday, May 15, 2002 1:06 PM > To: Kostur, Andre > Cc: 'Katia Linker'; DHCP IETF mailing list > Subject: Re: [dhcwg] "Options" field >=20 >=20 > > Probably the size of a UDP packet (minus the size of the=20 > header... 200 or=20 > > so bytes).=A0 However, clients can tell the server that they=20 > can only accept=20 > > messages up to size X (there's an option for it). >=20 > No offense, but why are you answering someone's question=20 > about what the RFC=20 > says when you haven't looked the answer up in the RFC? From = RFC2131: >=20 > The 'options' field is now variable length. A DHCP client must be > prepared to receive DHCP messages with an 'options' field=20 > of at least > length 312 octets. This requirement implies that a DHCP=20 > client must > be prepared to receive a message of up to 576 octets, the=20 > minimum IP >=20 >=20 >=20 > Droms Standards Track =20 > [Page 10] > =0C>=20 > RFC 2131 Dynamic Host Configuration Protocol =20 > March 1997 >=20 >=20 > datagram size an IP host must be prepared to accept [3]. DHCP >=20 ------_=_NextPart_001_01C1FC4E.21E97080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] "Options" field

The original poster did ask what the _maximum_ length = the options field may be (not the minimum), and he did mention that he = already knew that the minimum was 312 bytes.  That passage from = the RFC does not mention the maximum size, only the minimum size.  = It does continue to say that if the client can handle larger message = sizes it should supply option 57 to negotiate the larger sized = packets.

> -----Original Message-----
> From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
> Sent: Wednesday, May 15, 2002 1:06 PM
> To: Kostur, Andre
> Cc: 'Katia Linker'; DHCP IETF mailing = list
> Subject: Re: [dhcwg] "Options" = field
>
>
> > Probably the size of a UDP packet (minus = the size of the
> header... 200 or
> > so bytes).=A0 However, clients can tell = the server that they
> can only accept
> > messages up to size X (there's an option = for it).
>
> No offense, but why are you answering someone's = question
> about what the RFC
> says when you haven't looked the answer up in = the RFC?   From RFC2131:
>
>     The 'options' field is = now variable length. A DHCP client must be
>     prepared to receive = DHCP messages with an 'options' field
> of at least
>     length 312 = octets.  This requirement implies that a DHCP
> client must
>     be prepared to receive = a message of up to 576 octets, the
> minimum IP
>
>
>
> = Droms           &= nbsp;           = Standards = Track           &= nbsp;      
>  [Page 10]
> =0C>
> RFC = 2131          Dynamic Host = Configuration Protocol         =
> March 1997
>
>
>     datagram size an IP = host must be prepared to accept [3].  DHCP
>

------_=_NextPart_001_01C1FC4E.21E97080-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 16:17:13 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 QAA21095; Wed, 15 May 2002 16:17:13 -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 QAA28583; Wed, 15 May 2002 16:16:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA28554 for ; Wed, 15 May 2002 16:16:07 -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 QAA21029 for ; Wed, 15 May 2002 16:15:52 -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 g4FKG5l05339 for ; Wed, 15 May 2002 15:16:05 -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 g4FKG5Q11360 for ; Wed, 15 May 2002 15:16:05 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed May 15 15:16:02 2002 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 15 May 2002 15:16:02 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D42C@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" Cc: dhcwg@ietf.org, "'JINMEI Tatuya / ????'" Subject: RE: [dhcwg] additional comments on dhcpv6-24 Date: Wed, 15 May 2002 15:16:00 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC4D.54C4CEB0" 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_01C1FC4D.54C4CEB0 Content-Type: text/plain; charset="iso-8859-1" But I would assume if you got zero Advertises back from the first transmission that it likely failed to be received by anyone (perhaps because the Relay did not forward it). That's why I think it might be best to always have the IRT time elapse. But, I fully agree that as more retransmission occur, this is less and less of an issue. And, if there is only one server, it could just as likely have been the response that was lost. But in this case, you'd set the server to use a preference of 255 and gain the benefit. - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Wednesday, May 15, 2002 4:03 PM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org; 'JINMEI Tatuya / ????' Subject: Re: [dhcwg] additional comments on dhcpv6-24 > Regarding (2), good question ... I would say it should. The logic might > simply be send a Solicit, wait IRT, check if any Advertises received ... > if so, go use them otherwise send Solicit again. I think it makes more sense to say that if IRT has elapsed since the first Solicit was sent, the client just takes the first Advertise it gets. This is how I implemented the ISC DHCPv4 client, and it seems to work pretty nicely. ------_=_NextPart_001_01C1FC4D.54C4CEB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] additional comments on dhcpv6-24

But I would assume if you got zero Advertises back = from the first transmission that it likely failed to be received by = anyone (perhaps because the Relay did not forward it). That's why I = think it might be best to always have the IRT time elapse. But, I fully = agree that as more retransmission occur, this is less and less of an = issue. And, if there is only one server, it could just as likely have = been the response that was lost. But in this case, you'd set the server = to use a preference of 255 and gain the benefit.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Wednesday, May 15, 2002 4:03 PM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org; 'JINMEI Tatuya / ????'
Subject: Re: [dhcwg] additional comments on = dhcpv6-24


> Regarding (2), good question ... I would say it = should. The logic might
> simply be send a Solicit, wait IRT, check if = any Advertises received ...
> if so, go use them otherwise send Solicit = again.

I think it makes more sense to say that if IRT has = elapsed since the first
Solicit was sent, the client just takes the first = Advertise it gets.   This
is how I implemented the ISC DHCPv4 client, and it = seems to work pretty
nicely.

------_=_NextPart_001_01C1FC4D.54C4CEB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 16:34: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 QAA21603; Wed, 15 May 2002 16:34:00 -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 QAA29870; Wed, 15 May 2002 16:33: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 QAA29841 for ; Wed, 15 May 2002 16:33:29 -0400 (EDT) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21575 for ; Wed, 15 May 2002 16:33:13 -0400 (EDT) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g4FKVtm04658; Wed, 15 May 2002 16:31:55 -0400 Message-Id: <200205152031.g4FKVtm04658@cichlid.adsl.duke.edu> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6-24: vendor-specific issues In-Reply-To: Message from Ralph Droms of "Wed, 15 May 2002 13:23:33 EDT." <4.3.2.7.2.20020515131449.03653718@funnel.cisco.com> Date: Wed, 15 May 2002 16:31:55 -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 Ralph Droms writes: > At 11:14 AM 5/8/2002 -0400, Thomas Narten wrote: > > > 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? > The idea is to support additional flexibility and precision in identifying > clients in some deployments. This situation anticipates that clients will > be configured to send additional classing information and servers will have > policies to select configuration information based on those > classes. Because both the clients and server have been "managed" for this > deployment, they will interoperate. A client that moves and tries to use a > server that does not have policies for the classes specified by the client, > or a client that does not supply the class specifications will get > configuration information that is not selected on the basis of the client > classes. I think my issue is more with the wording than the intent. TO be sure I understand, the User Class option is one that is configured by the end user. I.e., to say "accounting", "engineering", etc. In that case, the server processing shouldn't be "implementation specific" or "vendor specific". Another confusing part. The text is talking about multiple occurances of the option. How this is dealt with shouldn't be configuration specific... We don't get interoperability that way... On rereading this, one thing that is missing is discussion about how the client sets the value. Is it really "opaque data"? Shouldn't this be a utf-8 string (for ease of configuration)? Also, the server should treat them as opaque values in conjunction with its configuration-specific data. This is not stated. Does this help clarify my concern? > > > 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. > This text is essentially copied directly from section 8.4 of RFC2132 > (which, of course, doesn't necessarily make it a good idea). Perhaps the > differentiation should be "enhanced operation" with the vendor-specific > information versus "functioning operation" without? yes. It should not be implied that things "may not work well" if the server doesn't support the option. Rather, when it is supported, there maybe enhanced operation. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 17: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 RAA22295; Wed, 15 May 2002 17:08:57 -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 RAA02761; Wed, 15 May 2002 17:08:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA02728 for ; Wed, 15 May 2002 17:08:40 -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 RAA22274 for ; Wed, 15 May 2002 17:08: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 g4FL7JS07967; Wed, 15 May 2002 14:07:20 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4FL8Yd02021; Wed, 15 May 2002 16:08:34 -0500 (CDT) Date: Wed, 15 May 2002 16:08:34 -0500 Subject: Re: [dhcwg] "Options" field Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "'Katia Linker'" , DHCP IETF mailing list To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D19849589D@homer.incognito.com.> Message-Id: X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id RAA02729 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 > The original poster did ask what the _maximum_ length the options field > may be (not the minimum), and he did mention that he already knew that the > minimum was 312 bytes.  That passage from the RFC does not mention the > maximum size, only the minimum size.  It does continue to say that if the > client can handle larger message sizes it should supply option 57 to > negotiate the larger sized packets. On the contrary, the only size that section specifies is the maximum size. It says the field is variable length, and the maximum size a client has to be able to accept is 312 bytes of options (576 bytes total). It is perfectly permissible to send fewer than 312 bytes of options. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 17:48: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 RAA23315; Wed, 15 May 2002 17:48: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 RAA04752; Wed, 15 May 2002 17:48:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04723 for ; Wed, 15 May 2002 17:48:08 -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 RAA23309 for ; Wed, 15 May 2002 17:47:52 -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 1786Uj-00077J-00; Wed, 15 May 2002 14:39:37 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <2ZV8SRFY>; Wed, 15 May 2002 14:54:15 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D1984958A0@homer.incognito.com.> From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: "'Katia Linker'" , DHCP IETF mailing list Subject: RE: [dhcwg] "Options" field Date: Wed, 15 May 2002 14:54:13 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FC5B.0D4C9230" 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_01C1FC5B.0D4C9230 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > -----Original Message----- > From: Ted Lemon [mailto:Ted.Lemon@nominum.com] > Sent: Wednesday, May 15, 2002 2:09 PM > To: Kostur, Andre > Cc: 'Katia Linker'; DHCP IETF mailing list > Subject: Re: [dhcwg] "Options" field >=20 >=20 > > The original poster did ask what the _maximum_ length the=20 > options field=20 > > may be (not the minimum), and he did mention that he=20 > already knew that the=20 > > minimum was 312 bytes.=A0 That passage from the RFC does not=20 > mention the=20 > > maximum size, only the minimum size.=A0 It does continue to=20 > say that if the=20 > > client can handle larger message sizes it should supply=20 > option 57 to=20 > > negotiate the larger sized packets. >=20 > On the contrary, the only size that section specifies is the=20 > maximum size. > It says the field is variable length, and the maximum=20 > size a client has=20 > to be able to accept is 312 bytes of options (576 bytes=20 > total). It is=20 > perfectly permissible to send fewer than 312 bytes of options. I don't agree with your interpretation. Quoting from the RFC: "A DHCP client must be prepared to receive DHCP messages with an = 'options' field of at least length 312 octets" If that was to be a statement on the maxmium size of the options block, = then that statement would say "at most length 312 octects". Whether the = entire options block is actually filled with data may or may not be important = (the original poster didn't mention). The "minimum" interpretation is = somewhat reinforced by the wording within RFC 2132 for option 57: "The minimum legal value is 576 octets." 2132 makes no mention of a maximum value (other than it would obviously = have to fit within option 57's data). ------_=_NextPart_001_01C1FC5B.0D4C9230 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] "Options" field

> -----Original Message-----
> From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
> Sent: Wednesday, May 15, 2002 2:09 PM
> To: Kostur, Andre
> Cc: 'Katia Linker'; DHCP IETF mailing = list
> Subject: Re: [dhcwg] "Options" = field
>
>
> > The original poster did ask what the = _maximum_ length the
> options field
> > may be (not the minimum), and he did = mention that he
> already knew that the
> > minimum was 312 bytes.=A0 That passage = from the RFC does not
> mention the
> > maximum size, only the minimum size.=A0 It = does continue to
> say that if the
> > client can handle larger message sizes it = should supply
> option 57 to
> > negotiate the larger sized packets.
>
> On the contrary, the only size that section = specifies is the
> maximum size.
>     It says the field is = variable length, and the maximum
> size a client has
> to be able to accept is 312 bytes of options = (576 bytes
> total).   It is
> perfectly permissible to send fewer than 312 = bytes of options.

I don't agree with your interpretation.  Quoting = from the RFC:

"A DHCP client must be prepared to receive DHCP = messages with an 'options' field of at least length 312 = octets"

If that was to be a statement on the maxmium size of = the options block, then that statement would say "at most length = 312 octects".  Whether the entire options block is actually = filled with data may or may not be important (the original poster = didn't mention).  The "minimum" interpretation is = somewhat reinforced by the wording within RFC 2132 for option = 57:

"The minimum legal value is 576 = octets."

2132 makes no mention of a maximum value (other than = it would obviously have to fit within option 57's data).

------_=_NextPart_001_01C1FC5B.0D4C9230-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed May 15 18:57:47 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 SAA24891; Wed, 15 May 2002 18:57:46 -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 SAA08400; Wed, 15 May 2002 18:57:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08374 for ; Wed, 15 May 2002 18:57:00 -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 SAA24869 for ; Wed, 15 May 2002 18:56:46 -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 g4FMtZS08201; Wed, 15 May 2002 15:55:35 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4FMuod02060; Wed, 15 May 2002 17:56:50 -0500 (CDT) Date: Wed, 15 May 2002 17:56:50 -0500 Subject: Re: [dhcwg] "Options" field Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: DHCP IETF mailing list , "'Katia Linker'" To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D1984958A0@homer.incognito.com.> Message-Id: <0A6CFF74-6857-11D6-B998-00039367340A@nominum.com> X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA08375 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 > I don't agree with your interpretation.  Quoting from the RFC: > > "A DHCP client must be prepared to receive DHCP messages with an 'options' > field of at least length 312 octets" ^^^^^^ This section of the document says _nothing_ about sending messages. It specifies what a client must be prepared to receive. This is not an interpretation - it's what the text says. It says that a DHCP client must be able to handle _at least_ a 576-byte packet on input. This means that a DHCP server cannot assume that any client can accept a packet larger than 576 bytes unless the client says it can by sending the maximum message size option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 02:11: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 CAA13969; Thu, 16 May 2002 02:11:21 -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 CAA12342; Thu, 16 May 2002 02:10:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA12273 for ; Thu, 16 May 2002 02:10:07 -0400 (EDT) Received: from relay01.rabobank.nl (relay01.rabobank.nl [145.72.69.20]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13937 for ; Thu, 16 May 2002 02:09:51 -0400 (EDT) X-Server-Uuid: d32dbd14-b86d-11d3-8c8e-0008c7bba343 X-Server-Uuid: 91077152-1bde-4e67-8480-731f07dac000 From: "Boersma, A (Abe)" To: dhcwg@ietf.org Date: Thu, 16 May 2002 08:09:32 +0200 MIME-Version: 1.0 X-WSS-ID: 10FD997A1872917-38-02 Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1FCA0.3ED0E910" Message-ID: <10FD997A1872917-38@_rabobank.nl_> Subject: [dhcwg] unsubscribe a.boersma@rf.rabobank.nl 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_000_01C1FCA0.3ED0E910 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit unsubscribe a.boersma@rf.rabobank.nl X Abe Boersma Projectmanager mConnect Rabobank ICT (www.rabobankict.nl) Netwerkbedrijf / IP Services Laan van Eikenstein 9 3705 AR Zeist Tel: +31 (030)-2154974 Fax: +31 (030)-2151986 mailto:A.Boersma@rf.rabobank.nl BE CAREFULL IN WHAT YOU SEND, AND CONSERVATIVE IN WHAT YOU RECEIVE <> ================================================ De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de afzender direct te informeren door het bericht te retourneren. ================================================ The information contained in this message may be confidential and is intended to be exclusively for the addressee. Should you receive this message unintentionally, please do not use the contents herein and notify the sender immediately by return e-mail. ------_=_NextPart_000_01C1FCA0.3ED0E910 Content-Type: application/octet-stream; name="Boersma, A (Abe).vcf" Content-Disposition: attachment; filename="Boersma, A (Abe).vcf" Content-Transfer-Encoding: 7bit BEGIN:VCARD VERSION:2.1 N:Boersma;Abe FN:Boersma, A (Abe) ORG:Rabobank ICT;IS IP Services TEL;WORK;VOICE:+31 30 21 54974 ADR;WORK:;ZL O175 LABEL;WORK:ZL O175 EMAIL;PREF;INTERNET:A.Boersma@rf.rabobank.nl REV:20020314T100330Z END:VCARD ------_=_NextPart_000_01C1FCA0.3ED0E910-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 07:51:46 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 HAA21025; Thu, 16 May 2002 07:51:46 -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 HAA06884; Thu, 16 May 2002 07:51: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 BAA11255 for ; Thu, 16 May 2002 01:40:26 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05271 for ; Thu, 16 May 2002 01:40:10 -0400 (EDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4G5eL806688 for ; Thu, 16 May 2002 14:40:21 +0900 (JST) Date: Thu, 16 May 2002 14:41:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 28 Subject: [dhcwg] [dhcpv6] UseMulticast 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 Section 18.2.1 of dhcpv6-24 says: When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a status code option with value UseMulticast and no other options. On the other hand, section 15.10 says - the message does not include a Server Identifier option (snip) - the message does not include a Client Identifier option and the original message from the client contained a Client Identifier option Those two requirements seem to be inconsistent, or at least be confusing. Should the reply message contain the Server Identifier option (and the Client Identifier option if the original message contained it) in the Reply even if the server is responding with a status code option with UseMulticast? Or should the client loosen the validation in 15.10 if the reply contains a status code option? Or others? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 07:52: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 HAA21092; Thu, 16 May 2002 07:52:25 -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 HAA07021; Thu, 16 May 2002 07:52: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 EAA26511 for ; Thu, 16 May 2002 04:47:38 -0400 (EDT) Received: from mail.net2000.com.au (emerald.net2000.com.au [203.26.98.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17712 for ; Thu, 16 May 2002 04:47:23 -0400 (EDT) Received: from visual (client-203-166-84-44.net2000.com.au [203.166.84.44]) by mail.net2000.com.au (8.11.3/8.11.3) with SMTP id g4G8qDP27294 for ; Thu, 16 May 2002 18:52:14 +1000 Message-ID: <000a01c1fcb8$070f26a0$2c54a6cb@visual> From: "wahid231" To: Date: Thu, 16 May 2002 18:59:35 +1000 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C1FD0B.D215DBC0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [dhcwg] dhcp server 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_0007_01C1FD0B.D215DBC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi there, What i am interested to know if there is any possiblity to find out ip = address of any receipent who has send me an email. Thanks Faisal ------=_NextPart_000_0007_01C1FD0B.D215DBC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
hi there,
 
What i am interested to know if there = is any=20 possiblity to find out ip address of any receipent who has send me = an=20 email.
 
 
Thanks
 
Faisal
------=_NextPart_000_0007_01C1FD0B.D215DBC0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 08:22:15 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 IAA21959; Thu, 16 May 2002 08:22: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 IAA08792; Thu, 16 May 2002 08:21:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08764 for ; Thu, 16 May 2002 08:21:45 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21944 for ; Thu, 16 May 2002 08:21:31 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4GCLBHt029094 for ; Thu, 16 May 2002 05:21:11 -0700 (PDT) Date: Thu, 16 May 2002 08:21:10 -0400 (EDT) From: Ralph Droms To: dhcwg@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Original comment: > 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 reason not to make this 32 bits? the IPv6 API already has 32-bit interface IDs. Is there any reason to make it larger? Response: Clarified text in 20.1 to emphasize that relay agent fills in link-address field regardless of whether Interface-ID option is used. Added text explaining why interface-identifier for an interface should remain stable. Left interface-id as variable-length value. *** dhcpv6.tty Wed May 15 22:43:36 2002 - --- dhcpv6-24.txt Tue Apr 23 15:35:14 2002 *************** *** 3199,3207 **** will be forwarded, the relay agent MUST include an Interface-id option (see section 22.19) in the Relay-forward message. The server will include the Interface-id option in its Relay-reply message. ! The relay agent fills in the link-address field as described in the ! previous paragraph regardless of whether the relay agent includes an ! Interface-id option in the Relay-forward message. The relay agent copies the source address from the IP datagram in which the message was received from the client into the - --- 3260,3268 ---- will be forwarded, the relay agent MUST include an Interface-id option (see section 22.19) in the Relay-forward message. The server will include the Interface-id option in its Relay-reply message. ! 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. The relay agent copies the source address from the IP datagram in which the message was received from the client into the *************** *** 4548,4558 **** 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. The Interface-ID value for ! an interface SHOULD be stable and remain unchanged, for example, ! after the relay agent is restarted; if the Interface-ID changes, a ! server will not be able to use it reliabily in parameter assignment ! policies. 22.20. Reconfigure Message option - --- 4646,4652 ---- 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. 22.20. Reconfigure Message option ------- End of forwarded message ------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 08:58: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 IAA23065; Thu, 16 May 2002 08:58: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 IAA10106; Thu, 16 May 2002 08:50: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 IAA10087 for ; Thu, 16 May 2002 08:50:45 -0400 (EDT) Received: from dhcp-161-44-149-149.cisco.com (dhcp-161-44-149-149.cisco.com [161.44.149.149]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22849 for ; Thu, 16 May 2002 08:50:31 -0400 (EDT) Received: (from rdroms@localhost) by dhcp-161-44-149-149.cisco.com (8.11.6/8.11.6) id g4GCoAu01710; Thu, 16 May 2002 08:50:10 -0400 Date: Thu, 16 May 2002 08:50:10 -0400 Message-Id: <200205161250.g4GCoAu01710@dhcp-161-44-149-149.cisco.com> From: Ralph Droms To: dhcwg@ietf.org CC: rdroms@cisco.com Reply-to: rdroms@cisco.com 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 Narten: > 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. Response: Changed use of T1/T2 and lifetimes in Confirm message from client - client uses those fields for preferred values or sets to 0. Server compares only addresses for correctness and returns values chosen by server for T1/T2 and lifetimes. *** dhcpv6.tty Thu May 16 08:44:51 2002 --- dhcpv6-24.txt Tue Apr 23 15:35:14 2002 *************** *** 2220,2229 **** The client MUST include a Client Identifier option to identify itself to the server. The client adds any appropriate options, including one or more IA options. The client MUST include the addresses the ! client currently has associated with those IAs. The client fills in ! the T1 and T2 fields in the IA options and the preferred-lifetime and ! valid-lifetime fields in the IA Address options with preferred values ! or 0 if the client has no preference about those values. If the client chooses to request specific options from the server, it does so by including an Option Request option (see section 22.7, --- 2287,2293 ---- The client MUST include a Client Identifier option to identify itself to the server. The client adds any appropriate options, including one or more IA options. The client MUST include the addresses the ! client currently has associated with those IAs. If the client chooses to request specific options from the server, it does so by including an Option Request option (see section 22.7, *************** *** 2721,2756 **** When the server receives a Confirm message, the client is requesting confirmation that the configuration information it will use is valid. ! The server compares the addresses in the IA Address options in the ! Confirm message from the client with the addresses in the binding for ! the client. ! ! If the server finds that the addresses in the Confirm message do not ! match what is in the binding for that client or the addresses in ! the Confirm message are not appropriate for the link from which the ! client sent the Confirm message, the server sends a Reply message ! containing a Status Code option with the value ConfNoMatch. ! If the server finds that the addresses in the Confirm message match ! the addresses in the binding for that client, and the configuration information is still valid, the server sends a Reply message containing a Status Code option with the value Success. - If the server cannot determine if the information in the Confirm - message is valid or invalid, the server MUST NOT send a reply to the - client. For example, if the server does not have a binding for the ! Droms (ed.), et al. Expires 22 Oct 2002 [Page 41] Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 client, but the configuration information in the Confirm message appears valid, the server does not reply. ! The server constructs a Reply message by setting the "msg-type" field to REPLY, copying the transaction ID from the Confirm message into the transaction-ID field. --- 2785,2820 ---- 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. ! ! If the server finds that the information for the client does not ! match what is in the binding for that client or the configuration ! information is not valid, the server sends a Reply message containing ! a Status Code option with the value ConfNoMatch. ! If the server finds that the information for the client does match ! the information in the binding for that client, and the configuration information is still valid, the server sends a Reply message containing a Status Code option with the value Success. ! ! Droms (ed.), et al. Expires 22 Oct 2002 [Page 42] Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 + If the server cannot determine if the information in the Confirm + message is valid or invalid, the server MUST NOT send a reply to the + client. For example, if the server does not have a binding for the client, but the configuration information in the Confirm message appears valid, the server does not reply. ! The server contructs a Reply message by setting the "msg-type" field to REPLY, copying the transaction ID from the Confirm message into the transaction-ID field. *************** *** 2758,2771 **** server's DUID and the Client Identifier option from the Confirm message in the Reply message. - The server includes IA options for each of the IA options in the - Confirm message. The server chooses values for T1, T2 and lifetimes - for each of the addresses in the IAs according to the server's - configured policies. The values for T1, T2 and the lifetimes sent by - the client are the client's preferences for those values. The server - also includes options for any other configuration information to be - sent to the client. - The Reply message from the server MUST include a Status Code option. --- 2822,2827 ---- *************** *** 2794,2816 **** server may choose to change the list of addresses and the lifetimes of addresses in IAs that are returned to the client. ! The server constructs a Reply message by setting the "msg-type" field to REPLY, copying the transaction ID from the Renew message into the transaction-ID field. - Droms (ed.), et al. Expires 22 Oct 2002 [Page 42] - - Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 ! The server MUST include a Server Identifier option containing the ! server's DUID and the Client Identifier option from the Renew message ! in the Reply message. 18.2.4. Receipt of Rebind messages _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 09:08: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 JAA23395; Thu, 16 May 2002 09:08: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 JAA11237; Thu, 16 May 2002 09:08: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 JAA11197 for ; Thu, 16 May 2002 09:08:16 -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 JAA23376 for ; Thu, 16 May 2002 09:08:03 -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 g4GD7ki26973 for ; Thu, 16 May 2002 08:07:46 -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 g4GD7ks25961 for ; Thu, 16 May 2002 08:07:46 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu May 16 08:07:45 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 08:07:45 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D430@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'JINMEI Tatuya / ????'" , dhcwg@ietf.org Subject: RE: [dhcwg] [dhcpv6] UseMulticast Date: Thu, 16 May 2002 08:07:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FCDA.AA617BB0" 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_01C1FCDA.AA617BB0 Content-Type: text/plain; charset="iso-2022-jp" My take is that a Reply MUST always include the Server Identifier option (since that identifies the server responding) and it MUST include the Client Identifier option if the client sent one. I think the statements such as "no other options" should likely be reviewed and perhaps restates as no options containing configuration related information. We probably need a blanket statement somewhere that clarifies that all responses from a server to a client MUST contain: - The server identifier of the server. - The client identifier of the client if the client provided it. - Bernie -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Thursday, May 16, 2002 1:41 AM To: dhcwg@ietf.org Subject: [dhcwg] [dhcpv6] UseMulticast Section 18.2.1 of dhcpv6-24 says: When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a status code option with value UseMulticast and no other options. On the other hand, section 15.10 says - the message does not include a Server Identifier option (snip) - the message does not include a Client Identifier option and the original message from the client contained a Client Identifier option Those two requirements seem to be inconsistent, or at least be confusing. Should the reply message contain the Server Identifier option (and the Client Identifier option if the original message contained it) in the Reply even if the server is responding with a status code option with UseMulticast? Or should the client loosen the validation in 15.10 if the reply contains a status code option? Or others? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1FCDA.AA617BB0 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] [dhcpv6] UseMulticast

My take is that a Reply MUST always include the = Server Identifier option (since that identifies the server responding) = and it MUST include the Client Identifier option if the client sent = one.

I think the statements such as "no other = options" should likely be reviewed and perhaps restates as no = options containing configuration related information. We probably need = a blanket statement somewhere that clarifies that all responses from a = server to a client MUST contain:

- The server identifier of the server.
- The client identifier of the client if the client = provided it.

- Bernie

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshi= ba.co.jp]
Sent: Thursday, May 16, 2002 1:41 AM
To: dhcwg@ietf.org
Subject: [dhcwg] [dhcpv6] UseMulticast


Section 18.2.1 of dhcpv6-24 says:

   When the server receives a Request = message via unicast from a
   client to which the server has not sent = a unicast option, the server
   discards the Request message and = responds with a Reply message
   containing a status code option with = value UseMulticast and no other
   options.

On the other hand, section 15.10 says

    -  the message does not = include a Server Identifier option
(snip)
    -  the message does not = include a Client Identifier option and the
       original = message from the client contained a Client Identifier
       option

Those two requirements seem to be inconsistent, or at = least be
confusing.  Should the reply message contain = the Server Identifier
option (and the Client Identifier option if the = original message
contained it) in the Reply even if the server is = responding with a
status code option with UseMulticast?  Or = should the client loosen the
validation in 15.10 if the reply contains a status = code option?  Or
others?

        =         =         =         =         JINMEI, = Tatuya
        =         =         =         =         Communication = Platform Lab.
        =         =         =         =         Corporate = R&D Center, Toshiba Corp.
        =         =         =         =         jinmei@isl.rdc.toshiba.co.jp


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

------_=_NextPart_001_01C1FCDA.AA617BB0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 09:13: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 JAA23578; Thu, 16 May 2002 09:13: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 JAA11492; Thu, 16 May 2002 09:12: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 JAA11467 for ; Thu, 16 May 2002 09:12:41 -0400 (EDT) Received: from dhcp-161-44-149-149.cisco.com (dhcp-161-44-149-149.cisco.com [161.44.149.149]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23566 for ; Thu, 16 May 2002 09:12:27 -0400 (EDT) Received: (from rdroms@localhost) by dhcp-161-44-149-149.cisco.com (8.11.6/8.11.6) id g4GDC9P01719; Thu, 16 May 2002 09:12:09 -0400 Date: Thu, 16 May 2002 09:12:09 -0400 Message-Id: <200205161312.g4GDC9P01719@dhcp-161-44-149-149.cisco.com> From: Ralph Droms To: dhcwg@ietf.org CC: rdroms@cisco.com Reply-to: rdroms@cisco.com 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 Narten: > 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. Response: Changed use of T1/T2 and lifetimes in Confirm message from client. Client uses those fields for preferred values or sets to 0. Server checks only addresses for correctness and returns values chosen by server for T1/T2 and lifetimes. *** dhcpv6.tty Thu May 16 08:44:51 2002 --- dhcpv6-24.txt Tue Apr 23 15:35:14 2002 *************** *** 2220,2229 **** The client MUST include a Client Identifier option to identify itself to the server. The client adds any appropriate options, including one or more IA options. The client MUST include the addresses the ! client currently has associated with those IAs. The client fills in ! the T1 and T2 fields in the IA options and the preferred-lifetime and ! valid-lifetime fields in the IA Address options with preferred values ! or 0 if the client has no preference about those values. If the client chooses to request specific options from the server, it does so by including an Option Request option (see section 22.7, --- 2287,2293 ---- The client MUST include a Client Identifier option to identify itself to the server. The client adds any appropriate options, including one or more IA options. The client MUST include the addresses the ! client currently has associated with those IAs. If the client chooses to request specific options from the server, it does so by including an Option Request option (see section 22.7, *************** *** 2721,2756 **** When the server receives a Confirm message, the client is requesting confirmation that the configuration information it will use is valid. ! The server compares the addresses in the IA Address options in the ! Confirm message from the client with the addresses in the binding for ! the client. ! ! If the server finds that the addresses in the Confirm message do not ! match what is in the binding for that client or the addresses in ! the Confirm message are not appropriate for the link from which the ! client sent the Confirm message, the server sends a Reply message ! containing a Status Code option with the value ConfNoMatch. ! If the server finds that the addresses in the Confirm message match ! the addresses in the binding for that client, and the configuration information is still valid, the server sends a Reply message containing a Status Code option with the value Success. - If the server cannot determine if the information in the Confirm - message is valid or invalid, the server MUST NOT send a reply to the - client. For example, if the server does not have a binding for the ! Droms (ed.), et al. Expires 22 Oct 2002 [Page 41] Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 client, but the configuration information in the Confirm message appears valid, the server does not reply. ! The server constructs a Reply message by setting the "msg-type" field to REPLY, copying the transaction ID from the Confirm message into the transaction-ID field. --- 2785,2820 ---- 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. ! ! If the server finds that the information for the client does not ! match what is in the binding for that client or the configuration ! information is not valid, the server sends a Reply message containing ! a Status Code option with the value ConfNoMatch. ! If the server finds that the information for the client does match ! the information in the binding for that client, and the configuration information is still valid, the server sends a Reply message containing a Status Code option with the value Success. ! ! Droms (ed.), et al. Expires 22 Oct 2002 [Page 42] Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 + If the server cannot determine if the information in the Confirm + message is valid or invalid, the server MUST NOT send a reply to the + client. For example, if the server does not have a binding for the client, but the configuration information in the Confirm message appears valid, the server does not reply. ! The server contructs a Reply message by setting the "msg-type" field to REPLY, copying the transaction ID from the Confirm message into the transaction-ID field. *************** *** 2758,2771 **** server's DUID and the Client Identifier option from the Confirm message in the Reply message. - The server includes IA options for each of the IA options in the - Confirm message. The server chooses values for T1, T2 and lifetimes - for each of the addresses in the IAs according to the server's - configured policies. The values for T1, T2 and the lifetimes sent by - the client are the client's preferences for those values. The server - also includes options for any other configuration information to be - sent to the client. - The Reply message from the server MUST include a Status Code option. --- 2822,2827 ---- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 09:32:58 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 JAA24255; Thu, 16 May 2002 09:32:57 -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 JAA12724; Thu, 16 May 2002 09:32: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 JAA12670 for ; Thu, 16 May 2002 09:32:26 -0400 (EDT) Received: from dhcp-161-44-149-149.cisco.com (dhcp-161-44-149-149.cisco.com [161.44.149.149]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24240 for ; Thu, 16 May 2002 09:32:12 -0400 (EDT) Received: (from rdroms@localhost) by dhcp-161-44-149-149.cisco.com (8.11.6/8.11.6) id g4GDVs101757; Thu, 16 May 2002 09:31:54 -0400 Date: Thu, 16 May 2002 09:31:54 -0400 Message-Id: <200205161331.g4GDVs101757@dhcp-161-44-149-149.cisco.com> From: Ralph Droms To: dhcwg@ietf.org CC: rdroms@cisco.com Reply-to: rdroms@cisco.com 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 Narten: > 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. Response: Removed restriction on extension of lifetimes on temporary addresses. Added text pointing to RFC 3041 for guidance in extending lifetimes on temporary addresses and when to request additional temporary addresses. *** dhcpv6.tty Thu May 16 09:26:56 2002 --- dhcpv6-24.txt Tue Apr 23 15:35:14 2002 *************** *** 3944,3980 **** its own. When the lifetimes of all of the addresses in an IA have expired, the IA can be considered as having expired. ! An IA_TA option does not include values for T1 and T2. A client ! MAY request that the lifetimes on temporary addresses be extended ! by including the addresses in a IA_TA option sent in a Renew or ! Rebind message to a server. For example, a client would request ! an extension on the lifetime of a temporary address to allow an ! application to continue to use an established TCP connection. ! ! The client obtains new temporary addresses by sending an IA_TA option ! with a new IAID to a server. Requesting new temporary addresses from ! the server is the equivalent of generating new temporary addresses ! as described in RFC 3041. The server will generate new temporary ! addresses and return them to the client. The client should request ! new temporary addresses before the lifetimes on the previously ! assigned addresses expire. - Droms (ed.), et al. Expires 22 Oct 2002 [Page 61] - - Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 - 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. ! This option MAY appear in a Confirm message if the lifetimes on the ! temporary addresses in the associated IA have not expired. 22.6. IA Address option --- 4005,4031 ---- its own. When the lifetimes of all of the addresses in an IA have expired, the IA can be considered as having expired. ! 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. ! ! 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. ! ! Droms (ed.), et al. Expires 22 Oct 2002 [Page 62] ! ! Internet Draft DHCP for IPv6 (-24) 22 Apr 2002 22.6. IA Address option _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 10:53:27 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 KAA26904; Thu, 16 May 2002 10:53: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 KAA16979; Thu, 16 May 2002 10:52: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 KAA16959 for ; Thu, 16 May 2002 10:52:50 -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 KAA26855 for ; Thu, 16 May 2002 10:52:36 -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 178MTo-0002K5-00; Thu, 16 May 2002 07:43:44 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <2ZV8SSX3>; Thu, 16 May 2002 07:58:30 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D1984958A3@homer.incognito.com.> From: "Kostur, Andre" To: "'Ted Lemon'" , "Kostur, Andre" Cc: DHCP IETF mailing list , "'Katia Linker'" Subject: RE: [dhcwg] "Options" field Date: Thu, 16 May 2002 07:58:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FCEA.1E2C96B0" 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_01C1FCEA.1E2C96B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > > I don't agree with your interpretation.=A0 Quoting from the RFC: > > > > "A DHCP client must be prepared to receive DHCP messages=20 > with an 'options' > > field of at least length 312 octets" > ^^^^^^ >=20 > This section of the document says _nothing_ about sending=20 > messages. It=20 > specifies what a client must be prepared to receive. This is not an = > interpretation - it's what the text says. It says that a=20 > DHCP client must=20 > be able to handle _at least_ a 576-byte packet on input. =20 > This means that=20 > a DHCP server cannot assume that any client can accept a=20 > packet larger than=20 > 576 bytes unless the client says it can by sending the=20 > maximum message size=20 > option. I don't disagree that in the absence of information to the contrary, = the largest packet that a server can expect the client to handle is 576 = bytes. However, if the client sends option 57 specifying that the largest DHCP packet that it is willing to handle is 1400 bytes, then the options = field is 1400 - 286 =3D 1136 bytes. Thus, the maximum size that the options = field may be is much larger than the 312 bytes mentioned in RFC 2131. (The data within the options field may not take up the entire field). ------_=_NextPart_001_01C1FCEA.1E2C96B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] "Options" field

> > I don't agree with your interpretation.=A0 = Quoting from the RFC:
> >
> > "A DHCP client must be prepared to = receive DHCP messages
> with an 'options'
> >  field of at least length 312 = octets"
>          = ;            = ;            = ;            = ;            = ;      ^^^^^^
>
> This section of the document says _nothing_ = about sending
> messages.   It
> specifies what a client must be prepared to = receive.   This is not an
> interpretation - it's what the text = says.   It says that a
> DHCP client must
> be able to handle _at least_ a 576-byte packet = on input.  
> This means that
> a DHCP server cannot assume that any client can = accept a
> packet larger than
> 576 bytes unless the client says it can by = sending the
> maximum message size
> option.

I don't disagree that in the absence of information = to the contrary, the largest packet that a server can expect the client = to handle is 576 bytes.  However, if the client sends option 57 = specifying that the largest DHCP packet that it is willing to handle is = 1400 bytes, then the options field is 1400 - 286 =3D 1136 bytes.  = Thus, the maximum size that the options field may be is much larger = than the 312 bytes mentioned in RFC 2131.  (The data within the = options field may not take up the entire field).

------_=_NextPart_001_01C1FCEA.1E2C96B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 12:57: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 MAA02088; Thu, 16 May 2002 12:57:53 -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 MAA28080; Thu, 16 May 2002 12:56: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 MAA27835 for ; Thu, 16 May 2002 12:53:33 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01922 for ; Thu, 16 May 2002 12:53:16 -0400 (EDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4GGrR811967 for ; Fri, 17 May 2002 01:53:28 +0900 (JST) Date: Fri, 17 May 2002 01:46:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org Subject: Re: [dhcwg] [dhcpv6] UseMulticast In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D430@EAMBUNT705> References: <66F66129A77AD411B76200508B65AC69B4D430@EAMBUNT705> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 26 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, 16 May 2002 08:07:43 -0500, >>>>> "Bernie Volz (EUD)" said: > My take is that a Reply MUST always include the Server Identifier > option (since that identifies the server responding) and it MUST > include the Client Identifier option if the client sent one. Okay, I'm fine with this. > I think the statements such as "no other options" should likely be > reviewed and perhaps restates as no options containing configuration > related information. We probably need a blanket statement somewhere > that clarifies that all responses from a server to a client MUST > contain: > - The server identifier of the server. > - The client identifier of the client if the client provided it. I agree (except for the server ID in a reply to an information-request; I'm not sure if this is really necessary, but this is a different issue). JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 12:57: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 MAA02086; Thu, 16 May 2002 12:57:53 -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 MAA28088; Thu, 16 May 2002 12:56: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 MAA27855 for ; Thu, 16 May 2002 12:53:40 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01929 for ; Thu, 16 May 2002 12:53:24 -0400 (EDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4GGrX811974; Fri, 17 May 2002 01:53:33 +0900 (JST) Date: Fri, 17 May 2002 01:51:56 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Subject: Re: [dhcwg] additional comments on dhcpv6-24 In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D428@EAMBUNT705> References: <66F66129A77AD411B76200508B65AC69B4D428@EAMBUNT705> User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 36 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 Wed, 15 May 2002 14:36:37 -0500, >>>>> "Bernie Volz (EUD)" said: > Regarding (1), based on -24 the server shouldn't be sending an > Advertise. And, yes, I think your assumption that the client should > discard it is correct. Having said that, I would like to see the > Rapid Commit change to be more of just an option. A server set up to > respond to Rapid Commit would send the Reply. Other servers could > send an Advertise. The client would use the Reply if received; > otherwise simply start using the Advertises as if a Solicit w/o > Rapid Commit was done. I'm a bit confused...so are you saying the followings? - the client should discard the unexpected advertise *with the current specification*. - but we should change the spec so that the client will accept an advertise. > Regarding (2), good question ... I would say it should. The logic > might simply be send a Solicit, wait IRT, check if any Advertises > received ... if so, go use them otherwise send Solicit again. Okay. I don't have a particular opinion on this as long as the wording is clear. > Regarding (3), your understanding is correct. I can't see that it > hurts for us to indicate that RAND be greater than 0. Okay. I would simplify the specification so that there will be no special case, but I don't make an objection to the current spec. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 13:32:43 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 NAA03234; Thu, 16 May 2002 13:32: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 NAA01221; Thu, 16 May 2002 13:31: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 NAA01200 for ; Thu, 16 May 2002 13:31:52 -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 NAA03208 for ; Thu, 16 May 2002 13:31: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 g4GHVKi14846 for ; Thu, 16 May 2002 12:31:20 -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 g4GHVJ409350 for ; Thu, 16 May 2002 12:31:19 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu May 16 12:31:18 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 16 May 2002 12:31:18 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D438@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'JINMEI Tatuya / ????'" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] additional comments on dhcpv6-24 Date: Thu, 16 May 2002 12:31:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1FCFF.78C21590" 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_01C1FCFF.78C21590 Content-Type: text/plain; charset="iso-2022-jp" Regarding (1), please watch the mailing list as Ralph Droms is issuing update notices for changes being made. - Bernie -----Original Message----- From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshiba.co.jp] Sent: Thursday, May 16, 2002 12:52 PM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: Re: [dhcwg] additional comments on dhcpv6-24 >>>>> On Wed, 15 May 2002 14:36:37 -0500, >>>>> "Bernie Volz (EUD)" said: > Regarding (1), based on -24 the server shouldn't be sending an > Advertise. And, yes, I think your assumption that the client should > discard it is correct. Having said that, I would like to see the > Rapid Commit change to be more of just an option. A server set up to > respond to Rapid Commit would send the Reply. Other servers could > send an Advertise. The client would use the Reply if received; > otherwise simply start using the Advertises as if a Solicit w/o > Rapid Commit was done. I'm a bit confused...so are you saying the followings? - the client should discard the unexpected advertise *with the current specification*. - but we should change the spec so that the client will accept an advertise. > Regarding (2), good question ... I would say it should. The logic > might simply be send a Solicit, wait IRT, check if any Advertises > received ... if so, go use them otherwise send Solicit again. Okay. I don't have a particular opinion on this as long as the wording is clear. > Regarding (3), your understanding is correct. I can't see that it > hurts for us to indicate that RAND be greater than 0. Okay. I would simplify the specification so that there will be no special case, but I don't make an objection to the current spec. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp ------_=_NextPart_001_01C1FCFF.78C21590 Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] additional comments on dhcpv6-24

Regarding (1), please watch the mailing list as Ralph = Droms is issuing update notices for changes being made.

- Bernie

-----Original Message-----
From: jinmei@isl.rdc.toshiba.co.jp [mailto:jinmei@isl.rdc.toshi= ba.co.jp]
Sent: Thursday, May 16, 2002 12:52 PM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] additional comments on = dhcpv6-24


>>>>> On Wed, 15 May 2002 14:36:37 = -0500,
>>>>> "Bernie Volz (EUD)" = <Bernie.Volz@am1.ericsson.se> said:

> Regarding (1), based on -24 the server shouldn't = be sending an
> Advertise. And, yes, I think your assumption = that the client should
> discard it is correct. Having said that, I = would like to see the
> Rapid Commit change to be more of just an = option. A server set up to
> respond to Rapid Commit would send the Reply. = Other servers could
> send an Advertise. The client would use the = Reply if received;
> otherwise simply start using the Advertises as = if a Solicit w/o
> Rapid Commit was done.

I'm a bit confused...so are you saying the = followings?

- the client should discard the unexpected advertise = *with the current
  specification*.
- but we should change the spec so that the client = will accept an
  advertise.

> Regarding (2), good question ... I would say it = should. The logic
> might simply be send a Solicit, wait IRT, check = if any Advertises
> received ... if so, go use them otherwise send = Solicit again.

Okay.  I don't have a particular opinion on this = as long as the
wording is clear.

> Regarding (3), your understanding is correct. I = can't see that it
> hurts for us to indicate that RAND be greater = than 0.

Okay.  I would simplify the specification so = that there will be no
special case, but I don't make an objection to the = current spec.

        =         =         =         =         JINMEI, = Tatuya
        =         =         =         =         Communication = Platform Lab.
        =         =         =         =         Corporate = R&D Center, Toshiba Corp.
        =         =         =         =         jinmei@isl.rdc.toshiba.co.jp

------_=_NextPart_001_01C1FCFF.78C21590-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 16 14:48: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 OAA06019; Thu, 16 May 2002 14:48: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 OAA06127; Thu, 16 May 2002 14:47: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 OAA06102 for ; Thu, 16 May 2002 14:47:30 -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 OAA06000 for ; Thu, 16 May 2002 14:47:15 -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 g4GIk5S11388; Thu, 16 May 2002 11:46:05 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4GIlNd03050; Thu, 16 May 2002 13:47:23 -0500 (CDT) Date: Thu, 16 May 2002 13:47:22 -0500 Subject: Re: [dhcwg] "Options" field Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: "'Katia Linker'" , DHCP IETF mailing list To: "Kostur, Andre" From: Ted Lemon In-Reply-To: <4FB49E60CFBA724E88867317DAA3D1984958A3@homer.incognito.com.> Message-Id: <5BA10180-68FD-11D6-8581-00039367340A@nominum.com> X-Mailer: Apple Mail (2.481) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id OAA06103 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 > I don't disagree that in the absence of information to the contrary, the > largest packet that a server can expect the client to handle is 576 bytes. >   However, if the client sends option 57 specifying that the largest DHCP > packet that it is willing to handle is 1400 bytes, then the options field > is 1400 - 286 = 1136 bytes.  Thus, the maximum size that the options field > may be is much larger than the 312 bytes mentioned in RFC 2131.  (The data > within the options field may not take up the entire field). Ah, I see. We meant different things by "maximum size." Sigh. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 19 07:19: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 HAA03240; Sun, 19 May 2002 07:19:54 -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 HAA01789; Sun, 19 May 2002 07:18:49 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA01762 for ; Sun, 19 May 2002 07:18:47 -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 HAA03201 for ; Sun, 19 May 2002 07:18:30 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-80.cisco.com [10.82.224.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA06935; Sun, 19 May 2002 07:17:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20020519071139.0369c9c0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 19 May 2002 07:13:58 -0400 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] Length of Reconf_Msg option Cc: "'Anders Vestlund'" , dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D327@EAMBUNT705> 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 I'll make this fix in the next rev of the draft... - Ralph At 06:26 PM 4/25/2002 -0500, Bernie Volz (EUD) wrote: >Yeah, this needs to be fixed. I'm also hoping we can change this slightly >- to change the msg-type to use the DHCPv6 message type numbers (in 25.3). >A revised version might be: > >22.20. Reconfigure Message option > > A server includes a Reconfigure Message option in a Reconfigure > message to indicate to the client whether the client responds with a > Renew message or an Information-request message. > > 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_RECONF_MSG | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | msg-type | > +-+-+-+-+-+-+-+-+ > > > option-code OPTION_RECONF_MSG (19) > > option-len 1 > > msg-type 5 for Renew message, 11 for > Information-request message > >-----Original Message----- >From: Anders Vestlund >[mailto:eraaves@al.edt.ericsson.se] >Sent: Thursday, April 25, 2002 10:04 AM >To: dhcwg@ietf.org >Subject: [dhcwg] Length of Reconf_Msg option > >Hi, > >I'm implementing a parse function for dhcp ipv6 messages based on draft >24. > >In chapter 22.20 I noticed that the option length >of Reconfigure Message option is set to 1. > >In the figure msg-type is drawn with 2 bytes length though. > >I assume the length should be one byte , which is enough to >carry the data it's used for. > >Best Regards >Anders Vestlund >Ericsson /// > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun May 19 07:27: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 HAA03453; Sun, 19 May 2002 07:27: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 HAA02048; Sun, 19 May 2002 07:27:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA02011 for ; Sun, 19 May 2002 07:27:15 -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 HAA03436 for ; Sun, 19 May 2002 07:26:58 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-80.cisco.com [10.82.224.80]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA07225; Sun, 19 May 2002 07:26:38 -0400 (EDT) Message-Id: <4.3.2.7.2.20020519071139.0369c9c0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 19 May 2002 07:13:58 -0400 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] Length of Reconf_Msg option Cc: "'Anders Vestlund'" , dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC69B4D327@EAMBUNT705> 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 I'll make this fix in the next rev of the draft... - Ralph At 06:26 PM 4/25/2002 -0500, Bernie Volz (EUD) wrote: >Yeah, this needs to be fixed. I'm also hoping we can change this slightly >- to change the msg-type to use the DHCPv6 message type numbers (in 25.3). >A revised version might be: > >22.20. Reconfigure Message option > > A server includes a Reconfigure Message option in a Reconfigure > message to indicate to the client whether the client responds with a > Renew message or an Information-request message. > > 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_RECONF_MSG | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | msg-type | > +-+-+-+-+-+-+-+-+ > > > option-code OPTION_RECONF_MSG (19) > > option-len 1 > > msg-type 5 for Renew message, 11 for > Information-request message > >-----Original Message----- >From: Anders Vestlund >[mailto:eraaves@al.edt.ericsson.se] >Sent: Thursday, April 25, 2002 10:04 AM >To: dhcwg@ietf.org >Subject: [dhcwg] Length of Reconf_Msg option > >Hi, > >I'm implementing a parse function for dhcp ipv6 messages based on draft >24. > >In chapter 22.20 I noticed that the option length >of Reconfigure Message option is set to 1. > >In the figure msg-type is drawn with 2 bytes length though. > >I assume the length should be one byte , which is enough to >carry the data it's used for. > >Best Regards >Anders Vestlund >Ericsson /// > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 21 12:32: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 MAA17859; Tue, 21 May 2002 12:32:57 -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 MAA29955; Tue, 21 May 2002 12:31:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25715 for ; Tue, 21 May 2002 11:57:04 -0400 (EDT) Received: from zrc2s0jx.us.nortel.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15605 for ; Tue, 21 May 2002 11:56:44 -0400 (EDT) Received: from zrc2c011.us.nortel.com (zrc2c011.us.nortel.com [47.103.120.51]) by zrc2s0jx.us.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g4LFuha17659 for ; Tue, 21 May 2002 10:56:43 -0500 (CDT) Received: by zrc2c011.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 10:56:47 -0500 Message-ID: From: "Afshan Mahmood" To: dhcwg@ietf.org Date: Tue, 21 May 2002 10:56:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C200E0.18950990" Subject: [dhcwg] DHCP SERVER 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_01C200E0.18950990 Content-Type: text/plain; charset="iso-8859-1" Does anyone knows where can i get a DHCP server which can have 20/sec activation and max activation of 800k subscriber. Afshan Mahmood Shasta GGSN Product Test Team esn - 44-51180 ------_=_NextPart_001_01C200E0.18950990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DHCP SERVER

Does anyone knows where can i get a = DHCP server which can have 20/sec  activation  and max = activation of 800k subscriber.

Afshan = Mahmood
Shasta GGSN Product Test Team
esn = - 44-51180


------_=_NextPart_001_01C200E0.18950990-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 21 12:33: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 MAA17882; Tue, 21 May 2002 12:33: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 MAA29976; Tue, 21 May 2002 12:32: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 LAA23948 for ; Tue, 21 May 2002 11:13:50 -0400 (EDT) Received: from mlry.radlan.co.il ([212.117.141.35]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14189 for ; Tue, 21 May 2002 11:13:29 -0400 (EDT) Received: by MLRY with Internet Mail Service (5.5.2653.19) id ; Tue, 21 May 2002 18:12:28 +0200 Message-ID: <42AB6BE23C29D511831E0002B32024885BE115@messenger.radlan.co.il> From: Katia Linker To: DHCP IETF mailing list Date: Tue, 21 May 2002 18:12:35 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="windows-1255" Subject: [dhcwg] DHCP Options 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 Hi ! If I understand correct, DHCP server must send a message which has an option field of no less than 312 bytes. And if max DHCP message size (option code = 57) allows larger size, the option field of larger size will be sent. Anyway, it is impossible to send an option field of less than 312 bytes. Please, tell me if it's right. Thanks in advance. Katya Linker Radlan Computer Communications Ltd. Atidim Technological Park Bldg #4 Tel Aviv 61131, Israel Tel: +972-3-7657900 Fax: +972-3-6487368 Visit us on http://www.radlan.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 21 13:25: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 NAA20643; Tue, 21 May 2002 13:25:51 -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 NAA03530; Tue, 21 May 2002 13:25: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 NAA03505 for ; Tue, 21 May 2002 13:25:13 -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 NAA20603 for ; Tue, 21 May 2002 13:24:54 -0400 (EDT) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g4LHNWS29993; Tue, 21 May 2002 10:23:32 -0700 (PDT) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g4LHP1d08713; Tue, 21 May 2002 12:25:01 -0500 (CDT) Date: Tue, 21 May 2002 12:25:00 -0500 Subject: Re: [dhcwg] DHCP Options Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: DHCP IETF mailing list To: Katia Linker From: Ted Lemon In-Reply-To: <42AB6BE23C29D511831E0002B32024885BE115@messenger.radlan.co.il> 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 > Anyway, > it is impossible to send an option field of less than 312 bytes. > Please, tell me if it's right. I don't think so. RFC2131 says the option field is variable in length, so presumably it could be as small as 64 bytes (the size of a bootp option field). _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 28 07:41: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 HAA13301; Tue, 28 May 2002 07:41: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 HAA02896; Tue, 28 May 2002 07:40: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 HAA02872 for ; Tue, 28 May 2002 07:40:50 -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 HAA13074; Tue, 28 May 2002 07:40:23 -0400 (EDT) Message-Id: <200205281140.HAA13074@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 28 May 2002 07:40:22 -0400 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-25.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 : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s) : J. Bound, M. Carney, C. Perkins, T. Lemon, B. Volz, R. Droms Filename : draft-ietf-dhc-dhcpv6-25.txt Pages : 84 Date : 24-May-02 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' (RFC2462), and can be used separately or concurrently with the latter to obtain configuration parameters A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-25.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-25.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-25.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: <20020524143433.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-25.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-25.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020524143433.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 28 08: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 IAA16129; Tue, 28 May 2002 08:51:29 -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 IAA08071; Tue, 28 May 2002 08:51:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA08044 for ; Tue, 28 May 2002 08:51:08 -0400 (EDT) Received: from mail4.noc.ntt.co.jp (mail4.noc.ntt.co.jp [210.163.32.59]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16119 for ; Tue, 28 May 2002 08:50:43 -0400 (EDT) Received: from ms1-gw.noc.ntt.com (ms1-gw.noc.ntt.com) by mail4.noc.ntt.co.jp (8.9.3/NOC-MAIL4) id VAA14027; Tue, 28 May 2002 21:51:04 +0900 (JST) Received: from mr1-gw.noc.ntt.com by ms1-gw.noc.ntt.com (8.9.3/3.7W) id VAA25744; Tue, 28 May 2002 21:51:03 +0900 (JST) Received: from mail1.noc.ntt.com by mr1-gw.noc.ntt.com (8.9.3/3.7W) id VAA25731; Tue, 28 May 2002 21:51:03 +0900 (JST) Received: from localhost by mail1.noc.ntt.com (8.9.3/3.7W) id VAA26967; Tue, 28 May 2002 21:51:02 +0900 (JST) Date: Tue, 28 May 2002 21:52:45 +0900 (JST) Message-Id: <20020528.215245.123116881.yasuhiro@ntt.com> To: rdroms@cisco.com Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Length of Reconf_Msg option From: SHIRASAKI Yasuhiro In-Reply-To: <4.3.2.7.2.20020519071139.0369c9c0@funnel.cisco.com> References: <66F66129A77AD411B76200508B65AC69B4D327@EAMBUNT705> <4.3.2.7.2.20020519071139.0369c9c0@funnel.cisco.com> X-Mailer: Mew version 1.95b43 on Emacs 20.4 / Mule 4.1 (AOI) Organization: NTT Communications Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit The figure for a Reconfigure Message option is still broken in the -25 draft. -- SHIRASAKI Yasuhiro @ NTT Communications > I'll make this fix in the next rev of the draft... > > - Ralph > > At 06:26 PM 4/25/2002 -0500, Bernie Volz (EUD) wrote: > > >Yeah, this needs to be fixed. I'm also hoping we can change this slightly > >- to change the msg-type to use the DHCPv6 message type numbers (in 25.3). > >A revised version might be: > > > >22.20. Reconfigure Message option > > > > A server includes a Reconfigure Message option in a Reconfigure > > message to indicate to the client whether the client responds with a > > Renew message or an Information-request message. > > > > 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_RECONF_MSG | option-len | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | msg-type | > > +-+-+-+-+-+-+-+-+ > > > > > > option-code OPTION_RECONF_MSG (19) > > > > option-len 1 > > > > msg-type 5 for Renew message, 11 for > > Information-request message _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 28 09:10: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 JAA17017; Tue, 28 May 2002 09:10: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 JAA10387; Tue, 28 May 2002 09:10: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 JAA10364 for ; Tue, 28 May 2002 09:10:20 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17009 for ; Tue, 28 May 2002 09:09:55 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g4SD9lHt004823; Tue, 28 May 2002 06:09:48 -0700 (PDT) Date: Tue, 28 May 2002 09:09:47 -0400 (EDT) From: Ralph Droms To: SHIRASAKI Yasuhiro cc: dhcwg@ietf.org Subject: Re: [dhcwg] Length of Reconf_Msg option In-Reply-To: <20020528.215245.123116881.yasuhiro@ntt.com> 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 Thanks for catching that oversight. I'll fix it right away. - Ralph On Tue, 28 May 2002, SHIRASAKI Yasuhiro wrote: > The figure for a Reconfigure Message option is still broken > in the -25 draft. > > -- > SHIRASAKI Yasuhiro @ NTT Communications > > > I'll make this fix in the next rev of the draft... > > > > - Ralph > > > > At 06:26 PM 4/25/2002 -0500, Bernie Volz (EUD) wrote: > > > > >Yeah, this needs to be fixed. I'm also hoping we can change this slightly > > >- to change the msg-type to use the DHCPv6 message type numbers (in 25.3). > > >A revised version might be: > > > > > >22.20. Reconfigure Message option > > > > > > A server includes a Reconfigure Message option in a Reconfigure > > > message to indicate to the client whether the client responds with a > > > Renew message or an Information-request message. > > > > > > 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_RECONF_MSG | option-len | > > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > | msg-type | > > > +-+-+-+-+-+-+-+-+ > > > > > > > > > option-code OPTION_RECONF_MSG (19) > > > > > > option-len 1 > > > > > > msg-type 5 for Renew message, 11 for > > > Information-request message > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 28 16:59:02 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 QAA01014; Tue, 28 May 2002 16:59:02 -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 QAA16044; Tue, 28 May 2002 16:58: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 QAA16010 for ; Tue, 28 May 2002 16:58:23 -0400 (EDT) Received: from tormail.ntgclarity.com (tormail.ntgi.net [216.13.19.5]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00988 for ; Tue, 28 May 2002 16:57:56 -0400 (EDT) Received: by tormail.ntgi.net with Internet Mail Service (5.5.2655.55) id ; Tue, 28 May 2002 16:57:50 -0400 Message-ID: <42416932F3C5D511935B00508B976386782A39@tormail.ntgi.net> From: Jeffrey Breukelman To: dhcwg@ietf.org Date: Tue, 28 May 2002 16:57:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2068A.5381E370" Subject: [dhcwg] Obtaining DHCP lease information 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_01C2068A.5381E370 Content-Type: text/plain; charset="iso-8859-1" Hello. Forgive me if I'm sending this email to the wrong place - I've attempted to find the right place. I have a request to build an application that can, among other things, retrieve DHCP lease information from a DHCP server. That is, to remotely query a DHCP server, and have it return a list of leases and lease times. I have been able to find no way to do this. Can anyone tell me if this is possible? Thanks for your help. Jeff Breukelman Sr Network Consultant NTG Clarity Networks (647)287-3267(cell) ------_=_NextPart_001_01C2068A.5381E370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Obtaining DHCP lease information

Hello.

Forgive me if I'm sending = this email to the wrong place - I've attempted to find the right = place.

I have a request to build an = application that can, among other things, retrieve DHCP lease = information from a DHCP server.  That is, to remotely query a DHCP = server, and have it return a list of leases and lease times.  I = have been able to find no way to do this.  Can anyone tell me if = this is possible?

Thanks for your help.


Jeff Breukelman
Sr Network = Consultant
NTG Clarity Networks
(647)287-3267(cell)

------_=_NextPart_001_01C2068A.5381E370-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 28 17:46: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 RAA02044; Tue, 28 May 2002 17:46: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 RAA19873; Tue, 28 May 2002 17:43:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA19842 for ; Tue, 28 May 2002 17:43:00 -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 RAA02016 for ; Tue, 28 May 2002 17:42: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 g4SLgSi00098 for ; Tue, 28 May 2002 16:42:28 -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 g4SLgSY17799 for ; Tue, 28 May 2002 16:42:28 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue May 28 16:42:27 2002 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 28 May 2002 16:42:01 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69B4D4DC@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Jeffrey Breukelman'" , dhcwg@ietf.org Subject: RE: [dhcwg] Obtaining DHCP lease information Date: Tue, 28 May 2002 16:42:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C20690.89BD3150" 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_01C20690.89BD3150 Content-Type: text/plain; charset="iso-8859-1" There isn't a mechanism to do this available in DHCP servers. However, there is hope in the future. Check out http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-03.txt. For now, it may be server dependent. For example, with the ISC DHCP Server (www.isc.org), you could scan the lease file. - Bernie Volz -----Original Message----- From: Jeffrey Breukelman [mailto:jbreukelman@ntgclarity.com] Sent: Tuesday, May 28, 2002 4:58 PM To: dhcwg@ietf.org Subject: [dhcwg] Obtaining DHCP lease information Hello. Forgive me if I'm sending this email to the wrong place - I've attempted to find the right place. I have a request to build an application that can, among other things, retrieve DHCP lease information from a DHCP server. That is, to remotely query a DHCP server, and have it return a list of leases and lease times. I have been able to find no way to do this. Can anyone tell me if this is possible? Thanks for your help. Jeff Breukelman Sr Network Consultant NTG Clarity Networks (647)287-3267(cell) ------_=_NextPart_001_01C20690.89BD3150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Obtaining DHCP lease information

There isn't a mechanism to do this available in DHCP = servers. However, there is hope in the future. Check out http://www.ietf.org/internet-drafts/draft-ietf-dhc-lea= sequery-03.txt.

For now, it may be server dependent. For example, = with the ISC DHCP Server (www.isc.org), you could scan the lease = file.

- Bernie Volz

-----Original Message-----
From: Jeffrey Breukelman [mailto:jbreukelman@ntgclarity= .com]
Sent: Tuesday, May 28, 2002 4:58 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Obtaining DHCP lease = information


Hello.
Forgive me if I'm sending this email to the wrong = place - I've attempted to find the right place.
I have a request to build an application that can, = among other things, retrieve DHCP lease information from a DHCP = server.  That is, to remotely query a DHCP server, and have it = return a list of leases and lease times.  I have been able to find = no way to do this.  Can anyone tell me if this is = possible?

Thanks for your help.


Jeff Breukelman
Sr Network Consultant
NTG Clarity Networks
(647)287-3267(cell)

------_=_NextPart_001_01C20690.89BD3150-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue May 28 18:11:43 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 SAA02683; Tue, 28 May 2002 18:11:43 -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 SAA23015; Tue, 28 May 2002 18:11: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 SAA22995 for ; Tue, 28 May 2002 18:11:36 -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 SAA02673 for ; Tue, 28 May 2002 18:11:06 -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 17CoG2-0005Fv-00; Tue, 28 May 2002 14:11:54 -0700 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <2ZV8TKHW>; Tue, 28 May 2002 14:28:54 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198A66E17@homer.incognito.com.> From: "Kostur, Andre" To: "'Jeffrey Breukelman'" , dhcwg@ietf.org Subject: RE: [dhcwg] Obtaining DHCP lease information Date: Tue, 28 May 2002 14:28:44 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2068E.A552E0B0" 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_01C2068E.A552E0B0 Content-Type: text/plain; charset="iso-8859-1" A list of leases? I'm not aware of any draft or RFC that covers that. There is a draft which given an IP address, you can query the DHCP server for information on that lease, but that would depend upon the DHCP server implementing that functionality. As I look at it again, you will be able to query by IP Address, MAC address, or Client-identifier. http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-03.txt Now, if your particular application only ever needs to query a particular vendor's DHCP server, you would have to contact that vendor to see if they have some proprietary extensions to the protocol, or other APIs that you could use to get the list of leases. -----Original Message----- From: Jeffrey Breukelman [mailto:jbreukelman@ntgclarity.com] Sent: Tuesday, May 28, 2002 1:58 PM To: dhcwg@ietf.org Subject: [dhcwg] Obtaining DHCP lease information Hello. Forgive me if I'm sending this email to the wrong place - I've attempted to find the right place. I have a request to build an application that can, among other things, retrieve DHCP lease information from a DHCP server. That is, to remotely query a DHCP server, and have it return a list of leases and lease times. I have been able to find no way to do this. Can anyone tell me if this is possible? Thanks for your help. Jeff Breukelman Sr Network Consultant NTG Clarity Networks (647)287-3267(cell) ------_=_NextPart_001_01C2068E.A552E0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Obtaining DHCP lease information

A list of leases?  I'm not aware of any draft or = RFC that covers that.  There is a draft which given an IP address, = you can query the DHCP server for information on that lease, but that = would depend upon the DHCP server implementing that = functionality.

As I look at it again, you will be able to query by = IP Address, MAC address, or Client-identifier.

http://www.ietf.org/internet-drafts/draft-ietf-dhc-lea= sequery-03.txt

Now, if your particular application only ever needs = to query a particular vendor's DHCP server, you would have to contact = that vendor to see if they have some proprietary extensions to the = protocol, or other APIs that you could use to get the list of = leases.

-----Original Message-----
From: Jeffrey Breukelman [mailto:jbreukelman@ntgclarity= .com]
Sent: Tuesday, May 28, 2002 1:58 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Obtaining DHCP lease = information


Hello.
Forgive me if I'm sending this email to the wrong = place - I've attempted to find the right place.
I have a request to build an application that can, = among other things, retrieve DHCP lease information from a DHCP = server.  That is, to remotely query a DHCP server, and have it = return a list of leases and lease times.  I have been able to find = no way to do this.  Can anyone tell me if this is = possible?

Thanks for your help.


Jeff Breukelman
Sr Network Consultant
NTG Clarity Networks
(647)287-3267(cell)

------_=_NextPart_001_01C2068E.A552E0B0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu May 30 14:27: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 OAA16555; Thu, 30 May 2002 14:27: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 OAA26414; Thu, 30 May 2002 14:27: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 OAA26391 for ; Thu, 30 May 2002 14:27:20 -0400 (EDT) Received: from web13002.mail.yahoo.com (web13002.mail.yahoo.com [216.136.174.12]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16515 for ; Thu, 30 May 2002 14:26:50 -0400 (EDT) Message-ID: <20020530182713.42316.qmail@web13002.mail.yahoo.com> Received: from [63.67.101.5] by web13002.mail.yahoo.com via HTTP; Thu, 30 May 2002 11:27:13 PDT Date: Thu, 30 May 2002 11:27:13 -0700 (PDT) From: Tarun To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] dhcp relay agent & dhcp client 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 We have an application in which an interface has a fixed ip address. But we want to run DHCP over that interface to obtain the filename to be downloaded. At the same time, we want that interface to act as an DHCP relay agent as well. So, is it possible to run a dhcp client daeomon and a dhcp relay agent on the same interface? [we will be using linux as the OS] your help is appreciated, iamtarun __________________________________________________ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 31 22:51: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 WAA09695; Fri, 31 May 2002 22:51:56 -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 WAA19937; Fri, 31 May 2002 22:51: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 MAA26993 for ; Wed, 29 May 2002 12:33:19 -0400 (EDT) Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23438 for ; Wed, 29 May 2002 12:32:54 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id JAA19075 for ; Wed, 29 May 2002 09:12:40 -0700 (MST)] Received: [from il02exb02.corp.mot.com (il02exb02.corp.mot.com [10.0.100.67]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id JAA13899 for ; Wed, 29 May 2002 09:12:40 -0700 (MST)] Received: by il02exb02.corp.mot.com with Internet Mail Service (5.5.2654.52) id ; Wed, 29 May 2002 11:12:39 -0500 Message-ID: From: Narayanan Vidya-CVN065 To: "'dhcp'" Date: Wed, 29 May 2002 11:12:33 -0500 X-MS-TNEF-Correlator: MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C2072B.A4073880" Subject: [dhcwg] DHCP API on Windows 2000 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_000_01C2072B.A4073880 Content-Type: text/plain; charset="iso-8859-1" All, I was wondering if anyone can point me to any examples on the use of DHCP client API on Win2k. The examples I found so far and very few and do not show any of the options other than the most commonly used ones. I am looking at setting the Home Agent option and the Subnet Selection Option in the client. I would greatly appreciate any pointers on how this can be done. I am sorry if this is not the right place to discuss this topic. If there is another mailing list to discuss implementation, I'd appreciate pointers to that. Thanks, Vidya ------_=_NextPart_000_01C2072B.A4073880 Content-Type: application/ms-tnef Content-Transfer-Encoding: base64 eJ8+IigQAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQWAAwAOAAAA0gcFAB0ACwAMACEAAwA2AQEggAMADgAAANIHBQAd AAsADAAmAAMAOwEBCYABACEAAABGNTg1RUUxRDUzQUQzMTRFODdCQTQ2RkJBOERBQUIwMAB2BwEE gAEAGQAAAERIQ1AgQVBJIG9uIFdpbmRvd3MgMjAwMAADBwENgAQAAgAAAAIAAgABA5AGALgHAAAx AAAAAwAAgAggBgAAAAAAwAAAAAAAAEYAAAAAUoUAAPATAAAeAAGACCAGAAAAAADAAAAAAAAARgAA AABUhQAAAQAAAAQAAAA4LjUACwACgAggBgAAAAAAwAAAAAAAAEYAAAAABoUAAAAAAAADAAOACCAG AAAAAADAAAAAAAAARgAAAAABhQAAAAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAOFAAAAAAAA CwAFgAggBgAAAAAAwAAAAAAAAEYAAAAADoUAAAAAAAADAAaACCAGAAAAAADAAAAAAAAARgAAAAAQ hQAAAAAAAAMAB4AIIAYAAAAAAMAAAAAAAABGAAAAABGFAAAAAAAAAwAIgAggBgAAAAAAwAAAAAAA AEYAAAAAGIUAAAAAAAAeAAuACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgAM gAggBgAAAAAAwAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADYAIIAYAAAAAAMAAAAAAAABG AAAAADiFAAABAAAAAQAAAAAAAAALAA6ACyAGAAAAAADAAAAAAAAARgAAAAAAiAAAAAAAAAsAD4AL IAYAAAAAAMAAAAAAAABGAAAAAAWIAAAAAAAAAgEJEAEAAAAeAgAAGgIAALsCAABMWkZ150ZZ1wMA CgByY3BnMTI1FjIA+Atgbg4QMDMzTwH3AqQD4wIAY2gKwHOwZXQwIAcTAoB9CoGSdgiQd2sLgGQ0 DGAeYwBQCwMLtRFgbGwsQwqiCoBJIHdhBCB3pwIgBIELgGcgBpAgAHAieQIgZSBjA5Fwb0cLgAVA B4AgdG8VkiDwZXhhbQtQB5ECIBbQOmgV8HURIBfQFYBESDRDUBYAbAiQFoFBUAsUcBfhVwuAMmsu IF5UGCEXVxRwAhB1EoAgunMW8GYKwQBwG5B2BJAtFzBmB9EcImQW8G5v8QVAc2hvHNIXMBiRGBL6 bwUwaQIgF8EYEQXAGBC3A5EYEgRgcwVABaBtBGC8bmwXMBhRG5AV0XMaQGsUcBdwIAkAbxJhFVBh 3x2BETAewBVBGBJIA3AV8DxBZxlCHqQcExgSU3VeYhXgBUAGYBegYyQzTz8kJAuAGAMZFCGCFNB1 bI8bkAnBInAgwWFwcAlw+mMHMHQV8BcSFlMEkBfD7x2yGBAEABYDYhXwHTAV4N8aQBQUFBYhwRuw chyBFXGfKmMqgR1iGBIFEGdoBUDVC1FjFsNkBABjGFAEIPsqYxbgcA3gIYEeQwlwLWL/AHAfJADA AxAVMhkgIDEu6b8HcBeRB4ACMCJwHtEsGyD+JxuQKHkpZxbhH4EnQSuFTzHBFfAaYABwa3MUBVaw aWR5YRQUEeEAOKAAAB4AcAABAAAAGQAAAERIQ1AgQVBJIG9uIFdpbmRvd3MgMjAwMAAAAAACAXEA AQAAABYAAAABwgcrpHthD085ckwR1r8bABCkxWP+AAALAAIAAQAAAAMA3j+vbwAAQAA5AIA4B6Qr B8IBAwDxPwkEAAAeADFAAQAAAAcAAABDVk4wNjUAAAMAGkAAAAAAHgAwQAEAAAAHAAAAQ1ZOMDY1 AAADABlAAAAAAAMA/T/kBAAAAwAmAAAAAAADADYAAAAAAAMAgBD/////AgFHAAEAAAAwAAAAYz1V UzthPSA7cD1tb3Q7bD1JTDAyRVhNMDUtMDIwNTI5MTYxMjMzWi0yMzE5NjgAAgH5PwEAAABHAAAA AAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAAAC9PPU1PVC9PVT1MTVBTSUwwMi9DTj1SRUNJUElF TlRTL0NOPUNWTjA2NQAAHgD4PwEAAAAXAAAATmFyYXlhbmFuIFZpZHlhLUNWTjA2NQAAHgA4QAEA AAAHAAAAQ1ZOMDY1AAACAfs/AQAAAEcAAAAAAAAA3KdAyMBCEBq0uQgAKy/hggEAAAAAAAAAL089 TU9UL09VPUxNUFNJTDAyL0NOPVJFQ0lQSUVOVFMvQ049Q1ZOMDY1AAAeAPo/AQAAABcAAABOYXJh eWFuYW4gVmlkeWEtQ1ZOMDY1AAAeADlAAQAAAAcAAABDVk4wNjUAAEAABzDMcwKkKwfCAUAACDDW gDOnKwfCAR4APQABAAAAAQAAAAAAAAAeAB0OAQAAABkAAABESENQIEFQSSBvbiBXaW5kb3dzIDIw MDAAAAAAHgA1EAEAAABAAAAAPEY4MkMyQzk3RTYwQUIzNEI5M0Y1QjA0OUIyQTA0QjU2NEY3MDk2 QGlsMDJleG0wNS5jb3JwLm1vdC5jb20+AAsAKQAAAAAACwAjAAAAAAADAAYQQ0BdcwMABxCzAQAA AwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEFMTCxJV0FTV09OREVSSU5HSUZBTllPTkVDQU5Q T0lOVE1FVE9BTllFWEFNUExFU09OVEhFVVNFT0ZESENQQ0xJRU5UQVBJT05XSU4yS1RIRUVYQU1Q TEVTSUZPVU5EU09GQVIAAAAAAgF/AAEAAABAAAAAPEY4MkMyQzk3RTYwQUIzNEI5M0Y1QjA0OUIy QTA0QjU2NEY3MDk2QGlsMDJleG0wNS5jb3JwLm1vdC5jb20+AFuD ------_=_NextPart_000_01C2072B.A4073880-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri May 31 22:55:03 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 WAA09759; Fri, 31 May 2002 22:55:03 -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 WAA20085; Fri, 31 May 2002 22:54: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 MAA16871 for ; Thu, 30 May 2002 12:13:54 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11253 for ; Thu, 30 May 2002 12:13:26 -0400 (EDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4UGDZ863135 for ; Fri, 31 May 2002 01:13:35 +0900 (JST) Date: Fri, 31 May 2002 01:14:30 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. References: MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: multipart/mixed; boundary="Multipart_Fri_May_31_01:14:30_2002-1" X-Dispatcher: imput version 20000228(IM140) Lines: 733 Subject: [dhcwg] unresolved comments in dhcpv6-25 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 --Multipart_Fri_May_31_01:14:30_2002-1 Content-Type: text/plain; charset=US-ASCII (Sorry for the long attachments) I've checked the draft dhcpv6-25 and found that most of my comments to the 24 draft was not addressed in the latest draft. Namely: - the "other questions" part of the first message - all comments except 3 and 14 in the second message - the comments 1 and 2 in the third message - the comment in the fourth message Some of the unresolved comments have been responded in this list, but it seems to me that the responses have not been reflected in the latest draft. Most of them are even not responded at all. Perhaps the reason is just because the comments and questions are so trivial and neglected. But, even so, I'd like to hear a short response like "they are trivial and does not have to be considered in the draft". Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp --Multipart_Fri_May_31_01:14:30_2002-1 Content-Type: message/rfc822 Return-Path: Delivered-To: jinmei@kame.net Received: from sh.wide.ad.jp (sh.wide.ad.jp [2001:200:0:1001::6]) by orange.kame.net (Postfix) with ESMTP id B6A1170E1 for ; Fri, 26 Apr 2002 19:05:39 +0900 (JST) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by sh.wide.ad.jp (8.11.1+3.4W/8.11.0) with ESMTP id g3QA5cq16539; Fri, 26 Apr 2002 19:05:38 +0900 (JST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28008; Fri, 26 Apr 2002 05:50: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 EAA23661 for ; Fri, 26 Apr 2002 04:24:13 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27170 for ; Fri, 26 Apr 2002 04:24:08 -0400 (EDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3Q8O9o15591 for ; Fri, 26 Apr 2002 17:24:09 +0900 (JST) Date: Fri, 26 Apr 2002 17:24:23 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 76 Subject: [dhcwg] some comments and questions on dhcpv6-24 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 X-UIDL: U;V!!SCY!!J54!!YNa!! I have some comments and questions on the latest I-D of DHCPv6, draft-ietf-dhc-dhcpv6-24.txt. 15.10. Reply message Clients MUST discard any received Reply messages that meet any of the following conditions: - the message does not include a Server Identifier option - the "transaction-ID" field in the message does not match the value used in the original message - the message does not include a Client Identifier option and the original message from the client contained a Client Identifier option - the message includes a Client Identifier option and the contents of the Client Identifier option does not match the DUID of the client What if the message includes a Client Identifier option but the client did not send the option in the corresponding request? 17.2.2. Creation and transmission of Advertise messages ... The Advertise message MUST be unicast through the interface on which the Solicit message was received. It seems to me the requirement is too strong. Is this really necessary? 18.2.5. Receipt of Information-request messages The server contructs a Reply message by setting the "msg-type" field ^^^^^^^^^this should be "constructs". There are many other "contructs" in the draft. to REPLY, copying the transaction ID from the Rebind message into the ^^^^^^ transaction-ID field. Should the "Rebind" message be "Information-request"? This sentence seems to be just copied from the previous section... The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Rebind ^^^^^^ message in the Reply message. Again, should the "Rebind" be "Information-request"? Other questions to this section: - what should the receiving server do if the Information-request contains a client Identifier option? I think the server MUST copy the option to the reply, but the draft does not mention this case. - what should the receiving server do if the Information-request contains an IA option? Section 18.1.5 says that: The client MUST NOT include any IA options. But none of this section and Section 15.12 mention this case. BTW: there seem to me several cases for this type of incompleteness. For example, Section 22.6 says "The IA Address option must be encapsulated in the Options field of an Identity Association option." But I'm not sure what a node should do when it receives an IA address option not encapsulated in an IA option. I've not gone through the entire draft, so I may miss something, and if so, I'd apologize in advance. If my guess is correct, however, then I'd suggest to check the consistency of the requirements over the entire draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --Multipart_Fri_May_31_01:14:30_2002-1 Content-Type: message/rfc822 Return-Path: Return-Path: Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.11.6/8.11.6) with ESMTP id g4E0TLZ09730 for ; Tue, 14 May 2002 09:29:21 +0900 (JST) (envelope-from dhcwg-admin@ietf.org) Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-5.9.6) for jinmei@localhost (single-drop); Tue, 14 May 2002 09:29:21 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4DLLv879088 for ; Tue, 14 May 2002 06:21:58 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.11.6/8.11.6) with ESMTP id g4DLLvb17461 for ; Tue, 14 May 2002 06:21:57 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id GAA26375 for ; Tue, 14 May 2002 06:21:57 +0900 (JST) Received: from mx4.toshiba.co.jp (mx4.toshiba.co.jp [133.199.160.112]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id g4DLLuM01022 for ; Tue, 14 May 2002 06:21:56 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id GAA00330; Tue, 14 May 2002 06:21:56 +0900 (JST) Received: from inet-tsb2.toshiba.co.jp (localhost [127.0.0.1]) by tsb-sgw.toshiba.co.jp (8.9.3/3.7W) with ESMTP id GAA29714 for ; Tue, 14 May 2002 06:21:55 +0900 (JST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by inet-tsb2.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id GAA28611 for ; Tue, 14 May 2002 06:21:55 +0900 (JST) Received: by orange.kame.net (Postfix) id 0662D70E2; Tue, 14 May 2002 06:21:55 +0900 (JST) Delivered-To: jinmei@kame.net Received: from sh.wide.ad.jp (sh.wide.ad.jp [2001:200:0:1001::6]) by orange.kame.net (Postfix) with ESMTP id CC34570E0 for ; Tue, 14 May 2002 06:21:54 +0900 (JST) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by sh.wide.ad.jp (8.11.1+3.4W/8.11.0/smtpfeed 1.18) with ESMTP id g4DLLrq12600; Tue, 14 May 2002 06:21:53 +0900 (JST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA21363; Mon, 13 May 2002 05:50: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 DAA12428 for ; Mon, 13 May 2002 03:01:40 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29323 for ; Mon, 13 May 2002 03:01:25 -0400 (EDT) Received: from localhost ([3ffe:501:4819:2000:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4D71U873513 for ; Mon, 13 May 2002 16:01:30 +0900 (JST) Date: Mon, 13 May 2002 16:02:06 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 265 Subject: [dhcwg] comments and qeustions on dhcpv6-24 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 X-UIDL: 2EY"!kk%"!~dJ!!KI-!! I've just gone thorough dhcpv6-24, and have some comments and questions on it. Since most of them are just for clarification or editorial comments, I've put all of them into this message. If we need to discuss some of them separately, please make another thread for the particular items. I've also checked recent discussions on the list based on comments from Thomas and tried to avoid duplicated comments (actually I have one.) I'd apologize in advance, if there is still any duplication. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp 1. Section 4.1. defines binding A binding (or, client binding) is a group of server data records containing the information the server has about the addresses in an IA and any other configuration information assigned to the client. A binding is indexed by the tuple (where IA-type is the type of address in the IA; for example, temporary) Is it always appropriate to contain "IA-TYPE" and "IAID" in the index of a binding? What if a configuration information (that needs a binding) is not associated with an IA? An IPv6 prefix delegated by DHCPv6 can be an example of such binding. 2. Section 15.13. says Clients MUST discard any received Relay-forward messages. What if a relay agent receives a relay-forward message? 3. Section 16. repeatedly says like 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,... I think requiring the client to use an address on the particular "interface" is too strong (though it should be the typical case). The source address MUST be on the "link" to which the interface being configured belongs, since the server may use the information to detect the client's link, but does not necessarily have to be on the exact interface. Using the term "link" instead of "interface" is also consistent with the last paragraph of this section. Also, I don't get why the "default address selection" draft is cited here. If this is just because the draft describes the generic mechanism to select source addresses, I don't think we need to cite it explicitly here. 4. Section 17.1. says A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. The wording is too specific. Since the client may just need other information than addresses, the text should be like "DHCP servers configured to server addresses or other configuration parameters...". 5. Section 17.1.1. says The client MAY include options with data values as hints to the server about parameter values the client would like to have returned. I'm not sure how the data values are specified. An option request option can only specify required option "types"... The same comments applies to Sections 18.1.1 and 18.1.5. 6. Section 17.1.3 says The client MUST ignore any Advertise message that includes a Status Code option containing the value AddrUnavail, with the exception that the client MAY display the associated status message to the user. and Section 17.2.2 has a corresponding text: If the server will not assign any addresses to IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a status code option with the status code set to AddrUnavail and a status message for the user. With the specification, it seems to me that a client cannot configure itself without getting addresses (except via information-request and reply exchanges). For example, suppose that a client wants to be delegated an IPv6 prefix from a provider, and sends a solicit without any IA option. The server is configured to delegate prefixes only (i.e. not addresses), so it sends an Advertise message with an AddrUnavail code. Since the client MUST ignore the advertise message, it cannot proceed any more. So, the specification should be clearer on the procedure when a client does not need addresses. 7. What if a reply message for a solicit with a rapid commit option does *not* contain a rapid commit option? Section 17.2.3 says that the server includes a Rapid Commit option in the Reply message, but Section 17.1.4 says nothing about the case if the rapid commit option is not included. 8. It is not very clear when a server includes a Server Unicast option. Section 18.1.1 (and some succeeding sections) says Use of multicast or anycast on a link and relay agents enables the inclusion of relay agent options in all messages sent by the client. The server should enable the use of unicast only when relay agent options will not be used. But, this only talks about some restrictions of including the option. Even with the text of section 22.13, I'm still not sure when a server should or can send a Server Unicast option. It would be better to describe the allowed (or necessary) cases explicitly. 9. (I've once pointed it out, but I'll do it again) Section 17.2.2 says If the Solicit message was received directly by the server,...The Advertise message MUST be unicast through the interface on which the Solicit message was received. Technically, the requirement is too strong, since links are larger than interfaces according to the IPv6 scoped address architecture. So, more accurately, it should say "The Advertise message MUST be unicast through the link on which the Solicit message was received." (Also see the last paragraph of Section 16.) 10. Section 18.2.1 says When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a status code option with value UseMulticast and no other options. I'm not sure how the client should act when it receives the reply message. Should it resend the request to multicast? Should it restart the entire procedure from the solicit? At least Section 18.1.6 should mention this case. The same comment applies to Sections 18.2.3, 18.2.6, and 18.2.7. 11. Section 18.2.6 says "The server ignores invalid addresses." What does "invalid" exactly mean? In particular, I'm not sure if the source address of the receipt message is "invalid" or not (note that section 18.1.7 prohibits the client to use addresses being released as the source address). The text should clearly define the term "invalid". The same comment applies to Section 18.2.7. 12. Section 19.1.1 says "The server sets the transaction-id field to 0". But I could not found description about the case where the client receives a reconfigure message with a non-0 transaction-id. Should it discard the message, or should it ignore the non-0 value, or others? 13. Why doesn't the timeout and retransmission rule in Section 19.1.2 follow the general rules described in Section 14? Is there something special for reconfigure messages? 14. In the first sentence of Section 19.3 A client MUST accept Reconfigure messages sent to UDP port 546on... we need a white space after "546". 15. What if a client receives a reconfigure message but none of the configuration information was provided by the server (that sends the reconfigure)? What if only a part of the configuration information was provided by the server? Section 19.3.1 is not clear (enough) about the cases. 16. (Relevant to the comment 12 above) Section 19.3.1 says the client ignores any additional Reconfigure messages (regardless of the transaction ID in the Reconfigure message) until the exchange is complete. Subsequent Reconfigure messages (again independent of the transaction ID) cause the client to initiate a new exchange. But, according to Section 19.1.1, the transaction ID should always be 0. So I don't get the rationale about the wording here. Does this simply mean the client should always ignore the transaction-ID? If so, it seems to me more natural to say so explicitly. 17. Section 21.5.2 says A DHCP message MUST NOT contain more than one Authentication option when using the delayed authentication protocol. Then, what if a received message contains more than one Authentication option? Ignore the entire message, ignore the authentication options (but a particular one), or others? (an editorial comment) we need some additional white space in this paragraph: ... in the DHCP message to facilitate processing of the authentication information.The format of the Authentication... after "information". 18. Section 21.5.3 says receiver computes the MAC as described in [9]. The entire DHCP message (except the MAC field of the authentication option itself), is used as input to the HMAC-MDS computation function. This is not very clear to me. Does this mean we should regard the MAC field as an all-0 field when computation? 19. We need a closing parenthesis in the first sentence of Section 21.5.5.4: If the server has selected a key for the client in a previous message exchange (see section 21.5.6.1, the client MUST use the same key to generate the authentication information. The appropriate point should be after "21.5.6.1". 20. Section 22.5 says An identity association for temporary addresses option MUST NOT appear in a Renew or Rebind message. What should the receiving node do if this condition is broken? 21. Section 22.14 specifies to use a UTF-8 encoded text string, but it seems to me too much. I think a simple ascii text is enough. (However, this may be based on a consensus of a former discussion, and if so, I don't oppose to the result.) 22. Section 22.17 says A DHCP message MUST NOT contain more than one Vendor Class option. What should the receiving node do if this condition is broken? 23. Section 22.18 says A DHCP message MUST NOT contain more than one Vendor-specific Information option with the same Enterprise Number. What should the receiving node do if this condition is broken? 24. Section 22.19 says This option MUST NOT appear in any message except a Relay-Forward or Relay-Reply message. What should the receiving node do if this condition is broken? (This question should be extended in a general form; "what should the receiving node do if an option is included in a message in which the option MUST NOT be appeared?") _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --Multipart_Fri_May_31_01:14:30_2002-1 Content-Type: message/rfc822 Return-Path: Return-Path: Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.11.6/8.11.6) with ESMTP id g4G12nZ60063 for ; Thu, 16 May 2002 10:02:50 +0900 (JST) (envelope-from dhcwg-admin@ietf.org) Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-5.9.6) for jinmei@localhost (single-drop); Thu, 16 May 2002 10:02:50 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4FIJm801390 for ; Thu, 16 May 2002 03:19:48 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.11.6/8.11.6) with ESMTP id g4FIJlb03911 for ; Thu, 16 May 2002 03:19:47 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id DAA13058 for ; Thu, 16 May 2002 03:19:47 +0900 (JST) Received: from mx.toshiba.co.jp (mx1.toshiba.co.jp [133.199.160.215]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id g4FIJkM18000 for ; Thu, 16 May 2002 03:19:46 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id DAA21730; Thu, 16 May 2002 03:19:46 +0900 (JST) Received: from inet-tsb2.toshiba.co.jp (localhost [127.0.0.1]) by tsb-sgw.toshiba.co.jp (8.9.3/3.7W) with ESMTP id DAA25144 for ; Thu, 16 May 2002 03:19:45 +0900 (JST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by inet-tsb2.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id DAA07434 for ; Thu, 16 May 2002 03:19:45 +0900 (JST) Received: by orange.kame.net (Postfix) id EB7FD70E9; Thu, 16 May 2002 03:19:44 +0900 (JST) Delivered-To: jinmei@kame.net Received: from sh.wide.ad.jp (sh.wide.ad.jp [2001:200:0:1001::6]) by orange.kame.net (Postfix) with ESMTP id C53DD70E8 for ; Thu, 16 May 2002 03:19:44 +0900 (JST) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by sh.wide.ad.jp (8.11.1+3.4W/8.11.0/smtpfeed 1.18) with ESMTP id g4FIJgq08543; Thu, 16 May 2002 03:19:42 +0900 (JST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18523; Wed, 15 May 2002 14:17:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA18395 for ; Wed, 15 May 2002 14:16:09 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16419 for ; Wed, 15 May 2002 14:15:53 -0400 (EDT) Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4FIG2801378 for ; Thu, 16 May 2002 03:16:02 +0900 (JST) Date: Thu, 16 May 2002 03:16:39 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 54 Subject: [dhcwg] additional comments on dhcpv6-24 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 X-UIDL: %)6"!0/Z!!>>-"!Ao+!! I have some additional comments (and questions) on dhcpv6-24, particularly about server solicitation. (1) If the client sent a solicit message with a rapid commit option but the server responds to the solicitation with an advertise message, what should the client do? Should it ignore the advertise, should it accept the advertise and send a request, or others? Section 17.1.4 says ...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, the client should probably ignore the advertise (and keep waiting for a reply.) But I'm not 100% sure about this. (2) Section 17.1.2 says: If the client is waiting for an Advertise message, the mechanism in section 14 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before IRT has elapsed. Rather, the client collects Advertise messages until IRT has elapsed. Should this rule apply if the client is retransmitting solicit messages? For example, suppose that there is no advertise in response to the first solicit, and so the client retransmit the solicit. If the client then receives a first advertise, should it still wait until IRT elapses? (3) The paragraph above then says: Also, the first RT MUST be selected to be strictly greater than IRT by choosing RAND to be strictly greater than 0. However, according to Section 13, the first RT should be RT = 2*IRT + RAND*IRT where RAND is a random number chosen with a uniform distribution between -0.1 and +0.1. Thus, RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT (the rightmost '=' is satisfied only when IRT is 0) So the RT should always be greater than IRT regardless of the value of RAND, and "by choosing RAND to be strictly greater than 0" seems to be redundant. Is my understanding correct? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --Multipart_Fri_May_31_01:14:30_2002-1 Content-Type: message/rfc822 Return-Path: Return-Path: Received: from localhost (localhost [127.0.0.1]) by ocean.jinmei.org (8.11.6/8.11.6) with ESMTP id g4GDsOZ62659 for ; Thu, 16 May 2002 22:54:24 +0900 (JST) (envelope-from dhcwg-admin@ietf.org) Received: from shuttle.wide.toshiba.co.jp [202.249.10.124] by localhost with POP3 (fetchmail-5.9.6) for jinmei@localhost (single-drop); Thu, 16 May 2002 22:54:24 +0900 (JST) Received: from tsbgw.wide.toshiba.co.jp (tsbgw.wide.toshiba.co.jp [202.249.10.123]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4GBvl810298 for ; Thu, 16 May 2002 20:57:47 +0900 (JST) Received: from maltese.wide.toshiba.co.jp (maltese.wide.toshiba.co.jp [202.249.10.99]) by tsbgw.wide.toshiba.co.jp (8.11.6/8.11.6) with ESMTP id g4GBvkb10135 for ; Thu, 16 May 2002 20:57:46 +0900 (JST) Received: from isl.rdc.toshiba.co.jp (spiffy.isl.rdc.toshiba.co.jp [133.196.10.10]) by maltese.wide.toshiba.co.jp (8.9.1/8.9.1) with ESMTP id UAA18913 for ; Thu, 16 May 2002 20:57:46 +0900 (JST) Received: from mx.toshiba.co.jp (mx1.toshiba.co.jp [133.199.160.215]) by isl.rdc.toshiba.co.jp (8.11.6/8.11.6/1.4) with ESMTP id g4GBvjM00487 for ; Thu, 16 May 2002 20:57:45 +0900 (JST) Received: from tsb-sgw.toshiba.co.jp by toshiba.co.jp (8.7.1+2.6Wbeta4/3.3W9-TOSHIBA-GLOBAL SERVER) id UAA10340; Thu, 16 May 2002 20:57:45 +0900 (JST) Received: from inet-tsb2.toshiba.co.jp (localhost [127.0.0.1]) by tsb-sgw.toshiba.co.jp (8.9.3/3.7W) with ESMTP id UAA09568 for ; Thu, 16 May 2002 20:57:44 +0900 (JST) Received: from orange.kame.net (orange.kame.net [203.178.141.194]) by inet-tsb2.toshiba.co.jp (3.7W:TOSHIBA-ISC-2000030918) with ESMTP id UAA22718 for ; Thu, 16 May 2002 20:57:44 +0900 (JST) Received: by orange.kame.net (Postfix) id E1A4670E2; Thu, 16 May 2002 20:57:43 +0900 (JST) Delivered-To: jinmei@kame.net Received: from sh.wide.ad.jp (sh.wide.ad.jp [2001:200:0:1001::6]) by orange.kame.net (Postfix) with ESMTP id D45E970D5 for ; Thu, 16 May 2002 20:57:43 +0900 (JST) Received: from optimus.ietf.org (ietf.org [132.151.1.19]) by sh.wide.ad.jp (8.11.1+3.4W/8.11.0/smtpfeed 1.18) with ESMTP id g4GBvgq24841; Thu, 16 May 2002 20:57:42 +0900 (JST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA06884; Thu, 16 May 2002 07:51: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 BAA11255 for ; Thu, 16 May 2002 01:40:26 -0400 (EDT) Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05271 for ; Thu, 16 May 2002 01:40:10 -0400 (EDT) Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4G5eL806688 for ; Thu, 16 May 2002 14:40:21 +0900 (JST) Date: Thu, 16 May 2002 14:41:01 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: dhcwg@ietf.org User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII X-Dispatcher: imput version 20000228(IM140) Lines: 28 Subject: [dhcwg] [dhcpv6] UseMulticast 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 X-UIDL: TUa!!U9!"!h:o"!)[J!! Status: U Section 18.2.1 of dhcpv6-24 says: When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a status code option with value UseMulticast and no other options. On the other hand, section 15.10 says - the message does not include a Server Identifier option (snip) - the message does not include a Client Identifier option and the original message from the client contained a Client Identifier option Those two requirements seem to be inconsistent, or at least be confusing. Should the reply message contain the Server Identifier option (and the Client Identifier option if the original message contained it) in the Reply even if the server is responding with a status code option with UseMulticast? Or should the client loosen the validation in 15.10 if the reply contains a status code option? Or others? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --Multipart_Fri_May_31_01:14:30_2002-1-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg