From owner-dhcp-v4@bucknell.edu Mon Jul 2 10:59:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12908 for ; Mon, 2 Jul 2001 10:59:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f62Eu4L03682; Mon, 2 Jul 2001 10:56:05 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f62EtrL20473 for ; Mon, 2 Jul 2001 10:55: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 KAA09366; Mon, 2 Jul 2001 10:55:08 -0400 (EDT) Message-Id: <200107021455.KAA09366@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-ldap-schema-00.txt Date: Mon, 02 Jul 2001 10:55:06 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 : LDAP Schema for DHCP Author(s) : M. Meredith, V. Nanjundaswamy, M. Hinckley Filename : draft-ietf-dhc-ldap-schema-00.txt Pages : 18 Date : 29-Jun-01 This document defines a schema for representing DHCP configuration in an LDAP directory. It can be used to represent the DHCP Service configuration(s) for an entire enterprise network, a subset of the network, or even a single server. Representing DHCP configuration in an LDAP directory enables centralized management of DHCP services offered by one or more DHCP Servers within the enterprise. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ldap-schema-00.txt 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-ldap-schema-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-ldap-schema-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010629141319.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ldap-schema-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ldap-schema-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010629141319.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Mon Jul 2 16:05:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03379; Mon, 2 Jul 2001 16:05:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f62K4NL17266; Mon, 2 Jul 2001 16:04:24 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f62K4JL07424 for ; Mon, 2 Jul 2001 16:04:19 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA21336 for ; Mon, 2 Jul 2001 16:02:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20010702102856.00b54ea0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 02 Jul 2001 16:01:10 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Plans for DHCPv6 spec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've posted the -19 rev of the DHCPv6 spec, which is available as: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-19.txt There are a couple of open issues in the draft: DHCP-DNS interaction, DUID selection and syntax, options to be specified in base spec. We (the authors) expect to close those open issues and post the -20 rev of the draft before the London meeting deadline. We then want to take the -20 rev to last call. We need to collect all of your input from the -19 draft for inclusion in the -20 draft for last call. To give us enough time to rev the draft and publish by the London deadline, WE HAVE TO GET YOUR INPUT BY 7/10!!! Although this week is interrupted (for some of us) by a holiday, it's *crucial* that the WG review and discuss the -19 draft. Please post any comments to the mailing list for group discussion, so we can make any changes needed in the -20 rev to prepare for last call. - Ralph From owner-dhcp-v4@bucknell.edu Mon Jul 2 22:33:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA06447 for ; Mon, 2 Jul 2001 22:33:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f632SuL32162; Mon, 2 Jul 2001 22:28:56 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f632SsL12667 for ; Mon, 2 Jul 2001 22:28:54 -0400 (EDT) Received: from localhost by boreas.isi.edu (8.11.2/8.11.2) with SMTP id f632So225164 for ; Mon, 2 Jul 2001 19:28:50 -0700 (PDT) Date: Mon, 2 Jul 2001 19:28:50 -0700 (PDT) From: Yu-Shun Wang To: DHCPv4 discussion list Subject: Number of interfaces? In-Reply-To: <200001310459.XAA23909@mail.bucknell.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: yushunwa@ISI.EDU Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi, Is there a limit on max number of interface the dhcp server and client can see? I am using 3.0.r8.2 on a laptop running FreeBSD 4.2 with a lot (64) of gifs (virtual tunnel interfaces) which come before the real NIC ed0 since it's PCCARD. If there is, how can I change that? Thanks, yushun. ____________________________________________________________________________ Yu-Shun Wang Information Sciences Institute University of Southern California From owner-dhcp-v4@bucknell.edu Tue Jul 3 00:13:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08089 for ; Tue, 3 Jul 2001 00:13:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6349BL16769; Tue, 3 Jul 2001 00:09:11 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6348sL28149 for ; Tue, 3 Jul 2001 00:08:54 -0400 (EDT) Received: from grosse.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 f6344hZ11329; Mon, 2 Jul 2001 21:04:56 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f63480D09217; Mon, 2 Jul 2001 21:08:00 -0700 (MST) Message-Id: <200107030408.f63480D09217@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Number of interfaces? In-Reply-To: Message from Yu-Shun Wang of "Mon, 02 Jul 2001 19:28:50 PDT." Date: Mon, 02 Jul 2001 23:07:59 -0500 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Is there a limit on max number of interface the dhcp > server and client can see? I am using 3.0.r8.2 on a > laptop running FreeBSD 4.2 with a lot (64) of gifs > (virtual tunnel interfaces) which come before the real > NIC ed0 since it's PCCARD. If there is, how can I > change that? Upgrade. This was fixed long ago. _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Jul 3 20:21:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20012 for ; Tue, 3 Jul 2001 20:21:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f640IKL00495; Tue, 3 Jul 2001 20:18:21 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f640IFL12908 for ; Tue, 3 Jul 2001 20:18:15 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id RAA03248 for ; Tue, 3 Jul 2001 17:18:13 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 3 Jul 2001 17:16:20 +0100 Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id RAA20040; Tue, 3 Jul 2001 17:18:04 -0700 (PDT) Message-Id: <200107040018.RAA20040@scv1.apple.com> Subject: Re: I-D ACTION:draft-guttman-dhc-mdns-enable-00.txt Date: Tue, 3 Jul 2001 17:18:04 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : DHCP mDNS Enable Option > Author(s) : E. Guttman > Filename : draft-guttman-dhc-mdns-enable-00.txt > Pages : > Date : 27-Jun-01 I'm generally uneasy about the apparently unending process our community has, of repeatedly stuffing "just one more" configuration option into DHCP packets, with no end in sight. However, with that caveat stated, two comments: 1. I think we all agree now that it is not a good idea to use the search list to control anything other than strings to be appended to unqualified names. Any implicit semantics associated with whether a particular string is in the search list or not is confusing. I think the sections of this draft dealing with why overloading the search list is a bad idea, can be safely deleted. 2. Instead of an 'order' byte and a 'scopes' bitfield, how about this: The option consists of a sequence of zero or more bytes, indicating the allowable scopes and the order in which they are to be tried. A byte with value zero means unicast. A byte with value one means link-local multicast. A byte with value two means site-local multicast, etc. That way, if we want, any number of scopes can be specified in any arbitrary order. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-dhcp-v4@bucknell.edu Thu Jul 5 06:57:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06815 for ; Thu, 5 Jul 2001 06:57:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f65ArLL25863; Thu, 5 Jul 2001 06:53:21 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f65ArAL01249 for ; Thu, 5 Jul 2001 06:53:10 -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 GAA06332; Thu, 5 Jul 2001 06:52:21 -0400 (EDT) Message-Id: <200107051052.GAA06332@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-pv4-reconfigure-05.txt Date: Thu, 05 Jul 2001 06:52:21 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP reconfigure extension Author(s) : P. De Schrijver, Y. T'Joens, C. Hublet Filename : draft-ietf-dhc-pv4-reconfigure-05.txt Pages : 6 Date : 03-Jul-01 This draft defines extensions to DHCP [DHCP] to allow dynamic reconfiguration of a single host triggered by the DHCP server (eg. a new IP address and/or local configuration parameters). This is achieved by introducing a unicast FORCERENEW message which forces the client to the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pv4-reconfigure-05.txt 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-pv4-reconfigure-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-pv4-reconfigure-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010703124449.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pv4-reconfigure-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pv4-reconfigure-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010703124449.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Thu Jul 5 14:45:56 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA23317 for ; Thu, 5 Jul 2001 14:45:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f65IggL30138; Thu, 5 Jul 2001 14:42:42 -0400 (EDT) Received: from dev-2.lemurnetworks.net (tconl91223.tconl.com [204.26.91.223]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f65IgSL23210 for ; Thu, 5 Jul 2001 14:42:28 -0400 (EDT) Received: (from jayhawk@localhost) by dev-2.lemurnetworks.net (8.11.0/8.11.0) id f65JffR01390; Thu, 5 Jul 2001 14:41:41 -0500 Date: Thu, 5 Jul 2001 14:41:40 -0500 From: Ryan Moats To: DHCPv4 discussion list Cc: mark_meredith@novell.com, knvijay@novell.com, mhinckley@novell.com Subject: Comments on draft-ietf-dhc-ldap-schema-00.txt Message-ID: <20010705144140.A1381@armada.local.windrose.omaha.ne.us> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Reply-To: rmoats@lemurnetworks.net Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I find this to be much better than the -02 draft it was based on and I have the following comments on this draft: >The schema uses a few naming conventions - all object classes and >attributes are prefixed with "dhcp" to decrease the chance that object >classes and attributes will have the same name. The schema also uses >standard naming attributes ("cn", "ou", etc) for all objects. This statement indicates that the schema uses standard naming attributes, it does not *require* them. Later in the object class descriptions, it does in fact require them. I would prefer strongly that the following object class definitions do not require the "standard" naming attributes as they will (IMHO) lead to administrator confusion (is this cn=... entry a dhcpServer, a person, or something else?). In general I suggest the addition of dhcp*Name attributes as possible naming attributes. This is the same approach that is being followed for the policy schema work (draft-ietf-policy-core-schema-xx). > 8. LDIF format for attributes and classes. While not necessary, some line unfolding would make the LDIF easier to read. In addition. An example comparison of a ISC dhcpd.conf file and the resulting objects would be of aid to implementors. Ryan Moats From owner-dhcp-v6@bucknell.edu Fri Jul 6 11:11:17 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07200; Fri, 6 Jul 2001 11:11:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f66FAhL24484; Fri, 6 Jul 2001 11:10:43 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f66FAfL03966; Fri, 6 Jul 2001 11:10:41 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02328; Fri, 6 Jul 2001 11:10:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20010706105702.037b5e48@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jul 2001 11:08:33 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Scheduling for DHC WG meeting in London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm about to schedule the DHC WG meeting in London. Please let me know of any conflicts you'd like to avoid. I intentionally used the singular "meeting"; I expect that the work and the bulk of the remaining discussion on the DHCPv6 spec will be completed before we go to London and we won't need a separate WG slot for DHCPv6. If you have DHC WG agenda items, please get them to me as soon as possible. The new DHC WG mailing list (which will replace the existing dhcp-v4 and dhcp-v6 lists) will be ready within the next day or two. I'll post an announcement (and test message) when it is in place. - Ralph From owner-dhcp-v4@bucknell.edu Fri Jul 6 11:17:29 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07571 for ; Fri, 6 Jul 2001 11:17:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f66FAhL09099; Fri, 6 Jul 2001 11:10:54 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f66FAfL03966; Fri, 6 Jul 2001 11:10:41 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA02328; Fri, 6 Jul 2001 11:10:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20010706105702.037b5e48@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jul 2001 11:08:33 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Scheduling for DHC WG meeting in London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm about to schedule the DHC WG meeting in London. Please let me know of any conflicts you'd like to avoid. I intentionally used the singular "meeting"; I expect that the work and the bulk of the remaining discussion on the DHCPv6 spec will be completed before we go to London and we won't need a separate WG slot for DHCPv6. If you have DHC WG agenda items, please get them to me as soon as possible. The new DHC WG mailing list (which will replace the existing dhcp-v4 and dhcp-v6 lists) will be ready within the next day or two. I'll post an announcement (and test message) when it is in place. - Ralph From owner-dhcp-v6@bucknell.edu Fri Jul 6 11:59:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09727; Fri, 6 Jul 2001 11:59:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f66FxfL12202; Fri, 6 Jul 2001 11:59:41 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f66FxQL19353 for ; Fri, 6 Jul 2001 11:59:26 -0400 (EDT) Received: from BarrFS9RB01 (dhcp-242.rc.vix.com [204.152.187.242]) by shell.nominum.com (Postfix) with SMTP id D45713190E for ; Fri, 6 Jul 2001 08:57:58 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Scheduling for DHC WG meeting in London Date: Fri, 6 Jul 2001 08:59:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20010706105702.037b5e48@funnel.cisco.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I'd like to avoid conflicts with DNS-EXT, IDN, and SNMPCONF if possible, and hope we can schedule early in the week. --Barr > -----Original Message----- > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > Behalf Of Ralph Droms > Sent: Friday, July 06, 2001 08:09 > To: DHCPv6 discussion list > Subject: Scheduling for DHC WG meeting in London > > > I'm about to schedule the DHC WG meeting in London. Please let > me know of > any conflicts you'd like to avoid. > > I intentionally used the singular "meeting"; I expect that the > work and the > bulk of the remaining discussion on the DHCPv6 spec will be completed > before we go to London and we won't need a separate WG slot for DHCPv6. > > If you have DHC WG agenda items, please get them to me as soon as > possible. > > The new DHC WG mailing list (which will replace the existing dhcp-v4 and > dhcp-v6 lists) will be ready within the next day or two. I'll post an > announcement (and test message) when it is in place. > > - Ralph > > From owner-dhcp-v6@bucknell.edu Fri Jul 6 12:55:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12481; Fri, 6 Jul 2001 12:55:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f66GtRL26180; Fri, 6 Jul 2001 12:55:27 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f66GtLL09205 for ; Fri, 6 Jul 2001 12:55:21 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA11802 for ; Fri, 6 Jul 2001 12:55:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20010706125004.03749660@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jul 2001 12:53:58 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Latest DHCPv6 spec Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've only received a couple of responses to my request for review of the latest rev of the DHCPv6 spec, ftp://search.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-19.txt Thanks to those who have responded. ***IT'S IMPORTANT THAT WE GET FEEDBACK AS SOON AS POSSIBLE!!*** We plan to rev the draft once more before the London publication cutoff. That rev will go to last call. Please respond with comments or with an ACK that you have no issues with the current draft. - Ralph From owner-dhcp-v4@bucknell.edu Mon Jul 9 15:45:14 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26954 for ; Mon, 9 Jul 2001 15:45:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f69JeIL05806; Mon, 9 Jul 2001 15:40:18 -0400 (EDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f69Je8L31363 for ; Mon, 9 Jul 2001 15:40:08 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Mon, 09 Jul 2001 13:39:47 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Mon, 09 Jul 2001 13:39:41 -0600 From: "Mark Meredith" To: DHCPv4 discussion list Cc: "Vijay KN" , "Mark Hinckley" Subject: Re: Comments on draft-ietf-dhc-ldap-schema-00.txt Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_82D8FE93.7514C684" Reply-To: MMEREDIT@novell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_82D8FE93.7514C684 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable We can change the wording to say it requires the standard naming attributes= , but I think it is ok the way it is??? =20 =20 I do not see a reason to add a new attribute just for naming when one = exists that the majority of schema is using, The object class will show = you what object you are talking about, so I do not understand how an = administrator will get confused? So I propose that it we use CN, OU etc. = because they are well defined and a standard schema for this purpose. =20 I agree with the folding issue we will work on making it fold better and = easier to read. =20 I would like some more input on the example from a dhcpd.conf file to the = resulting objects, before we add this. =20 -Mark =20 =20 Mark Meredith Senior Software Engineer Novell Inc 1800 Novell Place, Provo UT 84606 mark_meredith@novell.com=20 801-861-2645 =20 Novell, Inc., the leading provider of Net service software www.novell.com=20 =20 --------------------- A boat in the harbor is safe,=20 but that is not what boats are for. --John A. Shed --------------------- >>> Ryan Moats 07/05/01 01:41PM >>> I find this to be much better than the -02 draft it was based on and I have the following comments on this draft: >The schema uses a few naming conventions - all object classes and >attributes are prefixed with "dhcp" to decrease the chance that object >classes and attributes will have the same name. The schema also uses >standard naming attributes ("cn", "ou", etc) for all objects. This statement indicates that the schema uses standard naming attributes, it does not *require* them. Later in the object class descriptions, it does in fact require them. I would prefer strongly that the following object class definitions do not require the "standard" naming attributes as they will (IMHO) lead to administrator confusion (is this cn=3D... = entry a dhcpServer, a person, or something else?). In general I suggest the addition of dhcp*Name attributes as possible naming attributes. This is the same approach that is being followed for the policy schema work (draft-ietf-policy-core-schema-xx). > 8. LDIF format for attributes and classes. While not necessary, some line unfolding would make the LDIF easier=20 to read. In addition. An example comparison of a ISC dhcpd.conf file and the resulting objects would be of aid to implementors. Ryan Moats --=_82D8FE93.7514C684 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
We can change the wording to say it requires the = standard=20 naming attributes, but I think it is ok the way it=20 is???  
 
I do not see a reason to add a new attribute just for = naming=20 when one exists that the majority of schema is using, The object class = will show=20 you what object you are talking about, so I do not understand how an=20 administrator will get confused? So I propose that it we use CN, OU etc. = because=20 they are well defined and a standard schema for this purpose.
 
I agree with the folding issue we will work on making = it fold=20 better and easier to read.
 
I would like some more input on the example from a = dhcpd.conf=20 file to the resulting objects, before we add this.
 
-Mark
 
 
Mark Meredith
Senior Software Engineer
Novell Inc
1800 = Novell=20 Place, Provo UT 84606
mark_meredith@novell.com
80= 1-861-2645
 
Novell, Inc., the leading provider of Net service software
www.novell.com
 
---------------------
A boat in the harbor is safe,
but that = is not=20 what boats are for.
--John A.=20 Shed
---------------------

>>> Ryan Moats=20 <rmoats@lemurnetworks.net> 07/05/01 01:41PM >>>
I find = this to=20 be much better than the -02 draft it was based on and
I have the = following=20 comments on this draft:

>The schema uses a few naming conventions= -=20 all object classes and
>attributes are prefixed with "dhcp" to = decrease=20 the chance that object
>classes and attributes will have the same=20 name.  The schema also uses
>standard naming attributes ("cn", = "ou",=20 etc) for all objects.

This statement indicates that the schema = uses=20 standard naming attributes,
it does not *require* them.  Later in = the=20 object class descriptions,
it does in fact require them.  I would = prefer=20 strongly that the following
object class definitions do not require = the=20 "standard" naming attributes
as they will (IMHO) lead to administrator= =20 confusion (is this cn=3D... entry
a dhcpServer, a person, or = something=20 else?).  In general I suggest
the addition of dhcp*Name attributes = as=20 possible naming attributes.
This is the same approach that is being = followed=20 for the policy schema
work (draft-ietf-policy-core-schema-xx).

&g= t; 8.=20 LDIF format for attributes and classes.

While not necessary, some = line=20 unfolding would make the LDIF easier
to read.

In addition. = An=20 example comparison of a ISC dhcpd.conf file and the
resulting objects = would=20 be of aid to implementors.

Ryan Moats
--=_82D8FE93.7514C684-- From owner-dhcp-v4@bucknell.edu Mon Jul 9 15:59:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27292 for ; Mon, 9 Jul 2001 15:59:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f69JxbL27354; Mon, 9 Jul 2001 15:59:37 -0400 (EDT) Received: from dev-2.lemurnetworks.net (tconl91223.tconl.com [204.26.91.223]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f69JxTL17144 for ; Mon, 9 Jul 2001 15:59:30 -0400 (EDT) Received: (from jayhawk@localhost) by dev-2.lemurnetworks.net (8.11.0/8.11.0) id f69KwWU07424; Mon, 9 Jul 2001 15:58:32 -0500 Date: Mon, 9 Jul 2001 15:58:31 -0500 From: Ryan Moats To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu, Vijay KN , Mark Hinckley Subject: Re: Comments on draft-ietf-dhc-ldap-schema-00.txt Message-ID: <20010709155831.A7414@armada.local.windrose.omaha.ne.us> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from MMEREDIT@novell.com on Mon, Jul 09, 2001 at 01:39:41PM -0600 Reply-To: rmoats@lemurnetworks.net Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN On Mon, Jul 09, 2001 at 01:39:41PM -0600, Mark Meredith wrote: | We can change the wording to say it requires the standard naming attributes, | but I think it is ok the way it is??? | | I do not see a reason to add a new attribute just for naming when one exists | that the majority of schema is using, The object class will show you what | object you are talking about, so I do not understand how an administrator | will get confused? So I propose that it we use CN, OU etc. because they are | well defined and a standard schema for this purpose. Naming is very application/administration specific and schema (IMHO) should be flexible. Specifying only *one* naming attribute will lead to arguments ( like this :-) ). Further, from my administration experience, overloading the cn and ou (and other) attributes for classes other than what they were initially defined for is a Bad Thing because it *does* leads to confusion. Because of these reasons, the policy schema allows an administrator to use cn *or* a different attribute. That is what I am looking for here: a schema that I can use in my directory implementations. With the present restriction on naming, I have a barrier to using it. | I would like some more input on the example from a dhcpd.conf file to the | resulting objects, before we add this. My point is that I *think* I know how this would work, because I've implemented a partial dhc schema that looks similar. However, one of my big comments about the previous -02 draft was that it wouldn't be clear to a new administartor (heck I couldn't figure that out) how everything played together. An example (could be in an Appendix) of a (could be simple) dhcp.conf file and how it would be represented in the directory would add clarity for folks not familiar with the schema. Ryan From owner-dhcp-v6@bucknell.edu Tue Jul 10 09:56:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29514; Tue, 10 Jul 2001 09:56:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6ADuWL13428; Tue, 10 Jul 2001 09:56:32 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6ADuLL11141 for ; Tue, 10 Jul 2001 09:56:23 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6ADu6515158 for ; Tue, 10 Jul 2001 08:56:06 -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 f6ADu5F28108 for ; Tue, 10 Jul 2001 08:56:05 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jul 10 08:56:05 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP2R2WB>; Tue, 10 Jul 2001 08:56:05 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3237@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: Discussion items for dhcpv6 -19 draft ... Date: Tue, 10 Jul 2001 08:56:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10948.0DA2C170" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10948.0DA2C170 Content-Type: text/plain; charset="iso-8859-1" Some discussion items from the DHCPv6 -19 draft for the Working Group to consider: 1. I like the format of the option as per the -19 draft - in particular, the DUID-type. However, it seems as if the DUID len is either not necessary (since it is just option-len - 2) OR making it one byte would be more than sufficient (since we probably should set a reasonable upper limit of something like 32 bytes for the DUID). I do like the fact that it is variable - so I do NOT suggest we make it a fixed length field. 2. Should there be any recommendation (requirement) on the ordering of the DUID option? It might make server processing simplier and easier if the DUID is always required to be BEFORE any IA options (avoids needing to look ahead for it). Also, for relays and servers that will be load balancing, finding this quickly means that relays can forward the message quicker and servers can ignore the message sooner (if not in their load balancing range). As it is required in every client message, making it first would be beneficial. While it would be nice to make this a MUST, I would be happy with a SHOULD. I guess one other option might be to make it part of the header, but I like it better as an option. 3. Is the 16-bit Transaction ID really sufficient? I would like to understand why reducing the number of bits from 32 (DHCPv4) to 16 is justified. A 1 out of 65536 chance is a lot higher than a 1 out of 2^32 chance of a collision. Especially if clients don't have stable storage to save the last transaction ID (or don't want the 'cost' of using stable storage for this). 4. Is there any need for a 'secs' field? While the current specification is really based on the assumption that (request)/Reply messages are exchanged between client and one server, with the use of the anycast address or multicast addresses for a "pool" of DHCP servers, having a 'secs' field does allow for another member of the "pool" of servers to answer should the server assigned to answer not be available. Note that servers could do this without a secs field, but it does mean they need to save some state of these requests. Note that perhaps with issue 3 and 4 a new header can be defined that incorporates both a 32-bit transaction ID and a secs-like field? - Bernie Volz Ericsson ------_=_NextPart_001_01C10948.0DA2C170 Content-Type: text/html; charset="iso-8859-1" Discussion items for dhcpv6 -19 draft ...

Some discussion items from the DHCPv6 -19 draft for the Working Group to
consider:

1. I like the format of the option as per the -19 draft - in particular, the
DUID-type. However, it seems as if the DUID len is either not necessary
(since it is just option-len - 2) OR making it one byte would be more than
sufficient (since we probably should set a reasonable upper limit of something
like 32 bytes for the DUID). I do like the fact that it is variable - so I
do NOT suggest we make it a fixed length field.

2. Should there be any recommendation (requirement) on the ordering of the
DUID option? It might make server processing simplier and easier if the
DUID is always required to be BEFORE any IA options (avoids needing to
look ahead for it). Also, for relays and servers that will be load balancing,
finding this quickly means that relays can forward the message quicker and
servers can ignore the message sooner (if not in their load balancing range).

As it is required in every client message, making it first would be beneficial.
While it would be nice to make this a MUST, I would be happy with a SHOULD.

I guess one other option might be to make it part of the header, but I like it
better as an option.

3. Is the 16-bit Transaction ID really sufficient? I would like to understand
why reducing the number of bits from 32 (DHCPv4) to 16 is justified. A 1 out
of 65536 chance is a lot higher than a 1 out of 2^32 chance of a collision.
Especially if clients don't have stable storage to save the last transaction ID
(or don't want the 'cost' of using stable storage for this).

4. Is there any need for a 'secs' field? While the current specification is
really based on the assumption that (request)/Reply messages are exchanged
between client and one server, with the use of the anycast address or multicast
addresses for a "pool" of DHCP servers, having a 'secs' field does allow for
another member of the "pool" of servers to answer should the server assigned to
answer not be available. Note that servers could do this without a secs field,
but it does mean they need to save some state of these requests.

Note that perhaps with issue 3 and 4 a new header can be defined that
incorporates both a 32-bit transaction ID and a secs-like field?

- Bernie Volz
  Ericsson

------_=_NextPart_001_01C10948.0DA2C170-- From owner-dhcp-v6@bucknell.edu Tue Jul 10 16:28:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21989; Tue, 10 Jul 2001 16:28:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6AKS5L13623; Tue, 10 Jul 2001 16:28:05 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6AKRnL18100; Tue, 10 Jul 2001 16:27:49 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-128-107-134-62.cisco.com [128.107.134.62]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA04580; Tue, 10 Jul 2001 16:27:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20010710162353.037a1ec0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Jul 2001 16:26:16 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: DHC WG scheduling for London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The DHC WG will meet Wed AM (see below). This meeting will cover both DHCPv4 and DHCPv6 issues. Please let me know if you have items to be added to the agenda. - Ralph WEDNESDAY, August 8, 2001 0900-1130 Morning Sessions APP calsch Calendaring and Scheduling WG INT dhc Dynamic Host Configuration WG OPS opsarea Operations & Management Open Area RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC smime S/MIME Mail Security WG SUB-IP ccamp Common Control and Measurement Plane WG TSV avt Audio/Video Transport WG TSV midcom Middlebox Communication WG From owner-dhcp-v4@bucknell.edu Tue Jul 10 16:30:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22283 for ; Tue, 10 Jul 2001 16:30:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6AKS5L03143; Tue, 10 Jul 2001 16:28:07 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6AKRnL18100; Tue, 10 Jul 2001 16:27:49 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-128-107-134-62.cisco.com [128.107.134.62]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA04580; Tue, 10 Jul 2001 16:27:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20010710162353.037a1ec0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 10 Jul 2001 16:26:16 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: DHC WG scheduling for London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The DHC WG will meet Wed AM (see below). This meeting will cover both DHCPv4 and DHCPv6 issues. Please let me know if you have items to be added to the agenda. - Ralph WEDNESDAY, August 8, 2001 0900-1130 Morning Sessions APP calsch Calendaring and Scheduling WG INT dhc Dynamic Host Configuration WG OPS opsarea Operations & Management Open Area RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC smime S/MIME Mail Security WG SUB-IP ccamp Common Control and Measurement Plane WG TSV avt Audio/Video Transport WG TSV midcom Middlebox Communication WG From owner-dhcp-v4@bucknell.edu Wed Jul 11 14:38:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15276 for ; Wed, 11 Jul 2001 14:38:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6BIWvL14024; Wed, 11 Jul 2001 14:32:57 -0400 (EDT) Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6BIWnL05806 for ; Wed, 11 Jul 2001 14:32:49 -0400 (EDT) Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 11 Jul 2001 12:32:29 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Wed, 11 Jul 2001 12:32:20 -0600 From: "Mark Meredith" To: DHCPv4 discussion list Cc: , "Vijay KN" , "Mark Hinckley" Subject: Re: Comments on draft-ietf-dhc-ldap-schema-00.txt Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f6BIWnL11790 Reply-To: MMEREDIT@novell.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit My thoughts on the schema is this is the mandatory minimum specified, but it can be extended for different server requirements. So if you need to have a different naming attribute you should be able to add it to the May list and your server would use that attribute. I do not see multiple (different vendors) servers accessing the same directory, although it could happen, but even with a specified multiple naming routine, the names would have to match so that all of the servers would access the same information. In talking with different people about extending schema in general the feeling I get is that you should not create new attributes when there are existing attributes that will work. -Mark >>> Ryan Moats 07/09/01 02:58PM >>> On Mon, Jul 09, 2001 at 01:39:41PM -0600, Mark Meredith wrote: | We can change the wording to say it requires the standard naming attributes, | but I think it is ok the way it is??? | | I do not see a reason to add a new attribute just for naming when one exists | that the majority of schema is using, The object class will show you what | object you are talking about, so I do not understand how an administrator | will get confused? So I propose that it we use CN, OU etc. because they are | well defined and a standard schema for this purpose. Naming is very application/administration specific and schema (IMHO) should be flexible. Specifying only *one* naming attribute will lead to arguments ( like this :-) ). Further, from my administration experience, overloading the cn and ou (and other) attributes for classes other than what they were initially defined for is a Bad Thing because it *does* leads to confusion. Because of these reasons, the policy schema allows an administrator to use cn *or* a different attribute. That is what I am looking for here: a schema that I can use in my directory implementations. With the present restriction on naming, I have a barrier to using it. | I would like some more input on the example from a dhcpd.conf file to the | resulting objects, before we add this. My point is that I *think* I know how this would work, because I've implemented a partial dhc schema that looks similar. However, one of my big comments about the previous -02 draft was that it wouldn't be clear to a new administartor (heck I couldn't figure that out) how everything played together. An example (could be in an Appendix) of a (could be simple) dhcp.conf file and how it would be represented in the directory would add clarity for folks not familiar with the schema. Ryan From owner-dhcp-v4@bucknell.edu Wed Jul 11 19:48:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25124 for ; Wed, 11 Jul 2001 19:48:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6BNjiL30200; Wed, 11 Jul 2001 19:45:44 -0400 (EDT) Received: from mailout4-0.nyroc.rr.com (mailout4-1.nyroc.rr.com [24.92.226.166]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6BNjUL06663 for ; Wed, 11 Jul 2001 19:45:30 -0400 (EDT) Received: from chris (roc-24-93-8-132.rochester.rr.com [24.93.8.132]) by mailout4-0.nyroc.rr.com (8.11.2/RoadRunner 1.03) with SMTP id f6BNiD810891 for ; Wed, 11 Jul 2001 19:44:13 -0400 (EDT) Message-ID: <001801c10a5b$e2ed51b0$6401a8c0@chris> From: "Chris Chapin" To: DHCPv4 discussion list Subject: Having trouble understanding how routing works with Linksys router Date: Wed, 11 Jul 2001 19:50:30 -0300 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.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Reply-To: dirkdirt@rochester.rr.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hey, I'm new to the list - hello everyone. Ok here's the scenario. I subscribe to broadband through a cable modem. I have purchased only 1 IP address from the cable company. But of course I have more than 1 computer at my home that I want to connect to the internet simultaneously, so naturally I need more than 1 IP address. So I bought a Linksys router, enabled DHCP and boom everyone on my LAN has an unique IP address. But no one on the WAN could ever send a packet to the Linksys assigned IP addresses on my LAN. WAN people can only send packets to IP address given to me by my cable company. So my question is - how do packets get delivered to the correct computer on my LAN when they come in from the WAN? At first I thought that maybe the router would just broadcast the data to all the attached interfaces, but that wouldn't work for people playing the same game online but in different servers. I have been unable to discover or figure this out on my home. Could someone please point me in the right direction? Thank you, Chris From owner-dhcp-v4@bucknell.edu Wed Jul 11 20:07:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25632 for ; Wed, 11 Jul 2001 20:07:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6C083L30673; Wed, 11 Jul 2001 20:08:03 -0400 (EDT) Received: from mailserver.sylantro.com ([65.200.90.207]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6C080L13655 for ; Wed, 11 Jul 2001 20:08:01 -0400 (EDT) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Wed, 11 Jul 2001 17:05:18 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id <3CRJ1W2Y>; Wed, 11 Jul 2001 17:05:18 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD966340@mailserver.sylantro.com> From: "Joe Aiello" To: DHCPv4 discussion list Subject: RE: Having trouble understanding how routing works with Linksys r outer Date: Wed, 11 Jul 2001 17:05:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 17523634132380-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Reply-To: Joe.Aiello@sylantro.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit The intention of the broadband routers are not to allow inbound access to the private LAN as much as they provide simple NAT and link sharing for the private LAN to The Internet. However, the Linksys happens to have some features that allow you to pass some addresses, create a DMZ, etc. One feature most folks are unaware of is that the Linksys will route inbound quite well. The caveat is that folks must be on the same public subnet as you. They will not be able to route across public routers to addresses on your private LAN. Before I get to that, most broadband routers allow you some NAPT (Network Address Port Translation) for inbound connections. For example, if you are running a web server on a PC on the private LAN on PC 192.168.1.10, you can configure the Linksys to forward requests that come into the ISP assigned IP address (that is configured as the WAN IP address on the Linksys) on port 80 to port 80 on 192.168.1.10. You can add some of your own as long as you know the TCP or UDP ports the game server is using. OK, the Linksys will also route to addresses on your private LAN from folks on your public subnet. All they have to do is add a route on their system for the addresses on your private LAN. So, if you are 198.179.201.10 anyone on 198.179.201.xxx can put a route in their broadband router or PC to access the 192.168.1.x addresses on your private LAN through 198.179.201.10. This works great. This rarely known feature allows folks to access any PC on your private LAN through the Linksys. Again, they have to be on the same public subnet since the ISP routers will not forward the 192.168.1.x (for example) to your Linksys. Note: personal firewalls should be on each PC behind the Linksys. Note 2: Not all broadband routers act this way. Joe Aiello System Engineer Sylantro Systems http://www.sylantro.com/ VoIP Polls 408-626-3032 -----Original Message----- From: Chris Chapin [mailto:dirkdirt@rochester.rr.com] Sent: Wednesday, July 11, 2001 3:51 PM To: DHCPv4 discussion list Subject: Having trouble understanding how routing works with Linksys router Hey, I'm new to the list - hello everyone. Ok here's the scenario. I subscribe to broadband through a cable modem. I have purchased only 1 IP address from the cable company. But of course I have more than 1 computer at my home that I want to connect to the internet simultaneously, so naturally I need more than 1 IP address. So I bought a Linksys router, enabled DHCP and boom everyone on my LAN has an unique IP address. But no one on the WAN could ever send a packet to the Linksys assigned IP addresses on my LAN. WAN people can only send packets to IP address given to me by my cable company. So my question is - how do packets get delivered to the correct computer on my LAN when they come in from the WAN? At first I thought that maybe the router would just broadcast the data to all the attached interfaces, but that wouldn't work for people playing the same game online but in different servers. I have been unable to discover or figure this out on my home. Could someone please point me in the right direction? Thank you, Chris From owner-dhcp-v6@bucknell.edu Thu Jul 12 02:09:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA00085; Thu, 12 Jul 2001 02:09:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6C69RL02008; Thu, 12 Jul 2001 02:09:27 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6C69NL21701 for ; Thu, 12 Jul 2001 02:09:23 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6C65Rf01058 for ; Wed, 11 Jul 2001 23:05:28 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6C63cb00481 for ; Wed, 11 Jul 2001 23:03:38 -0700 (MST) Message-Id: <200107120603.f6C63cb00481@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Discussion items for dhcpv6 -19 draft ... In-Reply-To: Message from "Bernie Volz (EUD)" of "Tue, 10 Jul 2001 08:56:01 EST." <66F66129A77AD411B76200508B65AC697B3237@eambunt705.ena-east.ericsson.se> Date: Wed, 11 Jul 2001 23:03:38 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > 1. I like the format of the option as per the -19 draft - in > particular, the DUID-type. However, it seems as if the DUID len is > either not necessary (since it is just option-len - 2) OR making it > one byte would be more than sufficient (since we probably should set > a reasonable upper limit of something like 32 bytes for the DUID). I > do like the fact that it is variable - so I do NOT suggest we make > it a fixed length field. Yup, I second the idea of getting rid of the DUID length field. > 2. Should there be any recommendation (requirement) on the ordering of the > DUID option? It might make server processing simplier and easier if the > DUID is always required to be BEFORE any IA options (avoids needing to > look ahead for it). Also, for relays and servers that will be load balancing, > finding this quickly means that relays can forward the message quicker and > servers can ignore the message sooner (if not in their load balancing range). I don't think this is worth specifying. The difference we're talking about here is really minor compared to the overhead of, e.g., signing packets or actually doing the hash on the identifier. > I guess one other option might be to make it part of the header, but > I like it better as an option. Me too. If you put it in the header, you have to choose a length for it, and live with the choice later. > 3. Is the 16-bit Transaction ID really sufficient? I would like to > understand why reducing the number of bits from 32 (DHCPv4) to 16 is > justified. A 1 out of 65536 chance is a lot higher than a 1 out of > 2^32 chance of a collision. Especially if clients don't have stable > storage to save the last transaction ID (or don't want the 'cost' of > using stable storage for this). If the server is required to send back the DUID (and it probably should be, IMHO) then sixteen bits should be fine. > 4. Is there any need for a 'secs' field? While the current specification is I think you're right about this - we probably do need a 'secs' field. We haven't really talked about failover for DHCPv6 yet, but failover+load balancing for DHCPv4 would be a real pain to implement without the 'secs' field. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 12 13:32:29 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24014; Thu, 12 Jul 2001 13:32:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6CHWOL21628; Thu, 12 Jul 2001 13:32:24 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6CHWEL25535 for ; Thu, 12 Jul 2001 13:32:14 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6CHSEf02446 for ; Thu, 12 Jul 2001 10:28:14 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6CHPcb01391 for ; Thu, 12 Jul 2001 10:25:38 -0700 (MST) Message-Id: <200107121725.f6CHPcb01391@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Discussion items for dhcpv6 -19 draft ... In-Reply-To: Message from "Bernie Volz (EUD)" of "Tue, 10 Jul 2001 08:56:01 EST." <66F66129A77AD411B76200508B65AC697B3237@eambunt705.ena-east.ericsson.se> Date: Thu, 12 Jul 2001 10:25:38 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > 3. Is the 16-bit Transaction ID really sufficient? I would like to > understand why reducing the number of bits from 32 (DHCPv4) to 16 is > justified. A 1 out of 65536 chance is a lot higher than a 1 out of > 2^32 chance of a collision. Especially if clients don't have stable > storage to save the last transaction ID (or don't want the 'cost' of > using stable storage for this). Hm, on second thought, here's the thing: the packet is being unicast through the relay agent (or directly) to the client's link-local address. This is a completely different situation from DHCPv4, where all responses to unconfigured clients were broadcast, and therefore an XID collision was a real possibility. So we don't have to consider statistical odds of a collision - as long as the client doesn't use a transaction ID number for any transaction that it remembers, there will never be a collision. So there's no need for a 32-bit xid after all - 16 bits should be plenty. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 12 14:21:18 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00333; Thu, 12 Jul 2001 14:21:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6CIL1L17116; Thu, 12 Jul 2001 14:21:01 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6CIKtL07112 for ; Thu, 12 Jul 2001 14:20:55 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6CIKd510090 for ; Thu, 12 Jul 2001 13:20: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 f6CIKdw19973 for ; Thu, 12 Jul 2001 13:20:39 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Jul 12 13:20:38 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPJ8324>; Thu, 12 Jul 2001 13:20:38 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3259@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Discussion items for dhcpv6 -19 draft ... Date: Thu, 12 Jul 2001 13:20:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10AFF.57AEB450" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10AFF.57AEB450 Content-Type: text/plain; charset="iso-8859-1" Ted: My only concern is the one I raised as to why I think the 32-bit XID should be considered and that is exactly what you state in your response: "as long as the client doesn't use a transaction ID number for any transaction that it remembers, there will never be a collision." The issue is that if DHCPv6 is on a client that has limited resources (and hence no stable storage), how can it be sure that when it starts DHCPv6 and has to 'randomly' pick an XID that it isn't one that was recently used? A 1 out of 65536 chance is fairly decent odds that you'll get a collision. Using 32 bits would reduce this chance by 65536 times! [Note that if there is NO stable storage, then perhaps the DHID will be different each time and hence this isn't an issue; however the DHID could be based on a serial number and hence could be the same each time regardless of the lack of stable storage.] Perhaps a compromise is to add a 8-bit 'secs' field (perhaps calling it a 'retry' field and simply counting the number of retransmissions with the counter staying at 255 once it reaches that) and increase the XID from 16-bits to 24-bits? At least that reduces the chance by 256 times over the 16-bit value. While it doesn't align the header on a 32-bit boundry, it would align it on a 16-bit boundry. One other minor point to consider for the XID cache ... depending on how the lifetimes are determined for addresses, the server MIGHT need to update these in the response to the client. For example, if a server has a configuration that says give out a lifetime of X with an expiration of the prefix at Y, then as the current time approaches Y, the lifetime has to be reduced. If the cache is allowed to exist for several minutes, the lifetimes won't be run down and the client might consider an address valid for longer than it should. So, cache times should be short. We might even ask is the cache really worth it? If we REMOVED it, it would solve all the problems and we can use a 16-bit XID since all that would be used for is to match up active transactions, not past transactions. (Well, there is always the case that an old reply that was delayed by the network is received for a new request when the client reboots. But that's hopefully unlikely because of the time for reboots, etc.) - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, July 12, 2001 1:26 PM To: DHCPv6 discussion list Subject: Re: Discussion items for dhcpv6 -19 draft ... > 3. Is the 16-bit Transaction ID really sufficient? I would like to > understand why reducing the number of bits from 32 (DHCPv4) to 16 is > justified. A 1 out of 65536 chance is a lot higher than a 1 out of > 2^32 chance of a collision. Especially if clients don't have stable > storage to save the last transaction ID (or don't want the 'cost' of > using stable storage for this). Hm, on second thought, here's the thing: the packet is being unicast through the relay agent (or directly) to the client's link-local address. This is a completely different situation from DHCPv4, where all responses to unconfigured clients were broadcast, and therefore an XID collision was a real possibility. So we don't have to consider statistical odds of a collision - as long as the client doesn't use a transaction ID number for any transaction that it remembers, there will never be a collision. So there's no need for a 32-bit xid after all - 16 bits should be plenty. _MelloN_ ------_=_NextPart_001_01C10AFF.57AEB450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Discussion items for dhcpv6 -19 draft ...

Ted:

My only concern is the one I raised as to why I think = the 32-bit XID should be considered and that is exactly what you state = in your response:

"as long as the client doesn't use a transaction = ID number for any transaction that it remembers, there will never be a = collision."

The issue is that if DHCPv6 is on a client that has = limited resources (and hence no stable storage), how can it be sure = that when it starts DHCPv6 and has to 'randomly' pick an XID that it = isn't one that was recently used? A 1 out of 65536 chance is fairly = decent odds that you'll get a collision. Using 32 bits would reduce = this chance by 65536 times! [Note that if there is NO stable storage, = then perhaps the DHID will be different each time and hence this isn't = an issue; however the DHID could be based on a serial number and hence = could be the same each time regardless of the lack of stable = storage.]

Perhaps a compromise is to add a 8-bit 'secs' field = (perhaps calling it a 'retry' field and simply counting the number of = retransmissions with the counter staying at 255 once it reaches that) = and increase the XID from 16-bits to 24-bits? At least that reduces the = chance by 256 times over the 16-bit value. While it doesn't align the = header on a 32-bit boundry, it would align it on a 16-bit = boundry.


One other minor point to consider for the XID cache = ... depending on how the lifetimes are determined for addresses, the = server MIGHT need to update these in the response to the client. For = example, if a server has a configuration that says give out a lifetime = of X with an expiration of the prefix at Y, then as the current time = approaches Y, the lifetime has to be reduced. If the cache is allowed = to exist for several minutes, the lifetimes won't be run down and the = client might consider an address valid for longer than it should. So, = cache times should be short.

We might even ask is the cache really worth it? If we = REMOVED it, it would solve all the problems and we can use a 16-bit XID = since all that would be used for is to match up active transactions, = not past transactions. (Well, there is always the case that an old = reply that was delayed by the network is received for a new request = when the client reboots. But that's hopefully unlikely because of the = time for reboots, etc.)

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Thursday, July 12, 2001 1:26 PM
To: DHCPv6 discussion list
Subject: Re: Discussion items for dhcpv6 -19 draft = ...



> 3. Is the 16-bit Transaction ID really = sufficient? I would like to
> understand why reducing the number of bits from = 32 (DHCPv4) to 16 is
> justified. A 1 out of 65536 chance is a lot = higher than a 1 out of
> 2^32 chance of a collision.  Especially if = clients don't have stable
> storage to save the last transaction ID (or = don't want the 'cost' of
> using stable storage for this).

Hm, on second thought, here's the thing: the packet = is being unicast
through the relay agent (or directly) to the = client's link-local
address.   This is a completely different = situation from DHCPv4, where
all responses to unconfigured clients were = broadcast, and therefore
an XID collision was a real possibility.

So we don't have to consider statistical odds of a = collision - as long
as the client doesn't use a transaction ID number = for any transaction
that it remembers, there will never be a = collision.

So there's no need for a 32-bit xid after all - 16 = bits should be
plenty.

        =         =                _MelloN_

------_=_NextPart_001_01C10AFF.57AEB450-- From owner-dhcp-v6@bucknell.edu Thu Jul 12 14:40:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03008; Thu, 12 Jul 2001 14:40:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6CIdmL24266; Thu, 12 Jul 2001 14:39:48 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6CIdfL23055 for ; Thu, 12 Jul 2001 14:39:41 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6CIZhf02529 for ; Thu, 12 Jul 2001 11:35:43 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6CIX2b01442 for ; Thu, 12 Jul 2001 11:33:02 -0700 (MST) Message-Id: <200107121833.f6CIX2b01442@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Discussion items for dhcpv6 -19 draft ... In-Reply-To: Message from "Bernie Volz (EUD)" of "Thu, 12 Jul 2001 13:20:34 EST." <66F66129A77AD411B76200508B65AC697B3259@eambunt705.ena-east.ericsson.se> Date: Thu, 12 Jul 2001 11:33:02 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The issue is that if DHCPv6 is on a client that has limited > resources (and hence no stable storage), how can it be sure that > when it starts DHCPv6 and has to 'randomly' pick an XID that it > isn't one that was recently used? A 1 out of 65536 chance is fairly > decent odds that you'll get a collision. Using 32 bits would reduce > this chance by 65536 times! I don't understand what sort of problem you expect this to cause. Can you describe a real-world scenario where this could result in something bad happening? _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 12 15:37:43 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12460; Thu, 12 Jul 2001 15:37:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6CJbWL28111; Thu, 12 Jul 2001 15:37:32 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6CJbIL23695 for ; Thu, 12 Jul 2001 15:37:18 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6CJb2519371 for ; Thu, 12 Jul 2001 14:37:02 -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 f6CJb2311117 for ; Thu, 12 Jul 2001 14:37:02 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Jul 12 14:36:22 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPJ8T8T>; Thu, 12 Jul 2001 14:36:23 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B325B@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Discussion items for dhcpv6 -19 draft ... Date: Thu, 12 Jul 2001 14:36:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10B09.EE76D160" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10B09.EE76D160 Content-Type: text/plain; charset="iso-8859-1" 1. Client issues a DHCPv6 Renew to renew IA 565 with XID 10. 2. Client crashes before getting response from server. 3. Client boots (and doesn't have stable storage regarding XIDs) and issues a DHCPv6 Request for IA 123 with XID 10. 4. Client gets back the cached Reply for IA 565 and not IA 123 as a Reply to its request (XID 10). Now, it depends on how the client processes this. Based on some new language in the -19 draft, the client might assume that IA 565 was already allocated to it and add it to its addresses (this is to allow for Reconfigure-Init processing). Or, perhaps the client 'ignores' the Reply? In any case, the client still has no assignment for IA 123 so does it assume XID 10 is done or re-request it? If it re-requests it, it will still get the cached reply (and hence still have no valid response). Etc. Especially if the server restarts the timer on flushing that particular XID with reach request. So, perhaps the client gets no address for the IA (or it takes a while until the cached entry expires) AND/OR it uses addresses that it really didn't request (in this boot). Does this really break anything? Perhaps not. Is it proper behavoir, NO. There are other ways to fix this issue: - Add the client 'request' type to the XID cache. - Add the IAIDs to the XID cache (this may be more to simply match up the IAIDs in the cached reply with those in the request). Note that a 32-bit XID doesn't really solve the problem, it just reduces the chance it will happen. Does this answer you request for a 'real-world scenario'? Or, is my scenario broken in some way? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, July 12, 2001 2:33 PM To: DHCPv6 discussion list Subject: Re: Discussion items for dhcpv6 -19 draft ... > The issue is that if DHCPv6 is on a client that has limited > resources (and hence no stable storage), how can it be sure that > when it starts DHCPv6 and has to 'randomly' pick an XID that it > isn't one that was recently used? A 1 out of 65536 chance is fairly > decent odds that you'll get a collision. Using 32 bits would reduce > this chance by 65536 times! I don't understand what sort of problem you expect this to cause. Can you describe a real-world scenario where this could result in something bad happening? _MelloN_ ------_=_NextPart_001_01C10B09.EE76D160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Discussion items for dhcpv6 -19 draft ...

1. Client issues a DHCPv6 Renew to renew IA 565 with = XID 10.

2. Client crashes before getting response from = server.

3. Client boots (and doesn't have stable storage = regarding XIDs) and issues a DHCPv6 Request for IA 123 with XID = 10.

4. Client gets back the cached Reply for IA 565 and = not IA 123 as a Reply to its request (XID 10).

Now, it depends on how the client processes this. = Based on some new language in the -19 draft, the client might assume = that IA 565 was already allocated to it and add it to its addresses = (this is to allow for Reconfigure-Init processing). Or, perhaps the = client 'ignores' the Reply?

In any case, the client still has no assignment for = IA 123 so does it assume XID 10 is done or re-request it? If it = re-requests it, it will still get the cached reply (and hence still = have no valid response). Etc. Especially if the server restarts the = timer on flushing that particular XID with reach request.

So, perhaps the client gets no address for the IA (or = it takes a while until the cached entry expires) AND/OR it uses = addresses that it really didn't request (in this boot).

Does this really break anything? Perhaps not. Is it = proper behavoir, NO.


There are other ways to fix this issue:
- Add the client 'request' type to the XID = cache.
- Add the IAIDs to the XID cache (this may be more = to simply match up the IAIDs in the cached reply with those in the = request).

Note that a 32-bit XID doesn't really solve the = problem, it just reduces the chance it will happen.

Does this answer you request for a 'real-world = scenario'? Or, is my scenario broken in some way?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Thursday, July 12, 2001 2:33 PM
To: DHCPv6 discussion list
Subject: Re: Discussion items for dhcpv6 -19 draft = ...



> The issue is that if DHCPv6 is on a client that = has limited
> resources (and hence no stable storage), how = can it be sure that
> when it starts DHCPv6 and has to 'randomly' = pick an XID that it
> isn't one that was recently used? A 1 out of = 65536 chance is fairly
> decent odds that you'll get a collision. Using = 32 bits would reduce
> this chance by 65536 times!

I don't understand what sort of problem you expect = this to cause.
Can you describe a real-world scenario where this = could result in
something bad happening?

        =         =                _MelloN_

------_=_NextPart_001_01C10B09.EE76D160-- From owner-dhcp-v6@bucknell.edu Thu Jul 12 16:54:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA22782; Thu, 12 Jul 2001 16:54:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6CKrZL26448; Thu, 12 Jul 2001 16:53:35 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6CKrIL10727 for ; Thu, 12 Jul 2001 16:53:18 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6CKnLf02687 for ; Thu, 12 Jul 2001 13:49:21 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6CKkUb01557 for ; Thu, 12 Jul 2001 13:46:30 -0700 (MST) Message-Id: <200107122046.f6CKkUb01557@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Discussion items for dhcpv6 -19 draft ... In-Reply-To: Message from "Bernie Volz (EUD)" of "Thu, 12 Jul 2001 14:36:22 EST." <66F66129A77AD411B76200508B65AC697B325B@eambunt705.ena-east.ericsson.se> Date: Thu, 12 Jul 2001 13:46:30 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Does this really break anything? Perhaps not. Is it proper > behaviour? NO. A client with no non-volatile storage probably can't form a different query after it crashes, so the cached response should be identical to the previous response anyway. The DHCP server has to check the outgoing packet to make sure it's to the right client, based on the DUID, so I think that your proposed solution of making it check the IAIDs as well is probably the right one - this is a _lot_ less work than a database lookup, so it's still a win. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 12 16:58:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23371; Thu, 12 Jul 2001 16:58:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6CKxPL01432; Thu, 12 Jul 2001 16:59:25 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6CKxHL11228 for ; Thu, 12 Jul 2001 16:59:17 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6CKx1529228 for ; Thu, 12 Jul 2001 15:59:01 -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 f6CKx1w16785 for ; Thu, 12 Jul 2001 15:59:01 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 12 15:59:01 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPJ8Z7X>; Thu, 12 Jul 2001 15:59:01 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3262@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Discussion items for dhcpv6 -19 draft ... Date: Thu, 12 Jul 2001 15:58:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10B15.78C9E2C0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10B15.78C9E2C0 Content-Type: text/plain; charset="iso-8859-1" OK. I'm happy if we add the IAIDs (and I'd also suggest the request type just to be safe). Then we can leave the XID as 16-bits. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, July 12, 2001 4:47 PM To: DHCPv6 discussion list Subject: Re: Discussion items for dhcpv6 -19 draft ... > Does this really break anything? Perhaps not. Is it proper > behaviour? NO. A client with no non-volatile storage probably can't form a different query after it crashes, so the cached response should be identical to the previous response anyway. The DHCP server has to check the outgoing packet to make sure it's to the right client, based on the DUID, so I think that your proposed solution of making it check the IAIDs as well is probably the right one - this is a _lot_ less work than a database lookup, so it's still a win. _MelloN_ ------_=_NextPart_001_01C10B15.78C9E2C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Discussion items for dhcpv6 -19 draft ...

OK. I'm happy if we add the IAIDs (and I'd also = suggest the request type just to be safe). Then we can leave the XID as = 16-bits.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Thursday, July 12, 2001 4:47 PM
To: DHCPv6 discussion list
Subject: Re: Discussion items for dhcpv6 -19 draft = ...



> Does this really break anything?   = Perhaps not.   Is it proper
> behaviour?   NO.

A client with no non-volatile storage probably can't = form a different
query after it crashes, so the cached response = should be identical to
the previous response anyway.

The DHCP server has to check the outgoing packet to = make sure it's to
the right client, based on the DUID, so I think that = your proposed
solution of making it check the IAIDs as well is = probably the right
one - this is a _lot_ less work than a database = lookup, so it's still
a win.

        =         =                _MelloN_

------_=_NextPart_001_01C10B15.78C9E2C0-- From owner-dhcp-v6@bucknell.edu Thu Jul 12 19:39:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13335; Thu, 12 Jul 2001 19:39:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6CNd1L06843; Thu, 12 Jul 2001 19:39:01 -0400 (EDT) Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6CNcqL05463 for ; Thu, 12 Jul 2001 19:38:52 -0400 (EDT) Received: from 157.54.9.104 by mail2.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 12 Jul 2001 16:38:36 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 12 Jul 2001 16:38:36 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 12 Jul 2001 16:38:36 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 12 Jul 2001 16:37:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10B2B.A39E7A88" Subject: FW: Discussion items for dhcpv6 -19 draft ... Date: Thu, 12 Jul 2001 16:37:39 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10191DFE7@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Discussion items for dhcpv6 -19 draft ... Thread-Index: AcEJSGSOGVhm78/gSKqP1MLKmIJevABuDPBgAArERaA= From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 12 Jul 2001 23:37:39.0986 (UTC) FILETIME=[A3A19720:01C10B2B] Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------_=_NextPart_001_01C10B2B.A39E7A88 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on Bernie's suggestions inline: =20 -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]=20 Sent: Tuesday, July 10, 2001 6:56 AM To: DHCPv6 discussion list Subject: Discussion items for dhcpv6 -19 draft ... =20 Some discussion items from the DHCPv6 -19 draft for the Working Group to consider:=20 1. I like the format of the option as per the -19 draft - in particular, the=20 DUID-type. However, it seems as if the DUID len is either not necessary=20 (since it is just option-len - 2) OR making it one byte would be more than=20 sufficient (since we probably should set a reasonable upper limit of something=20 like 32 bytes for the DUID). I do like the fact that it is variable - so I=20 do NOT suggest we make it a fixed length field.=20 There is a need to have a limit on the length of DUID. If the length of DUID is the option length the max length of DUID is 64K bytes. This is going to put a burden on the server to store it and compare it to the client's DUID every single time. I would say one octet for DUID length should suffice. 2. Should there be any recommendation (requirement) on the ordering of the=20 DUID option? It might make server processing simplier and easier if the=20 DUID is always required to be BEFORE any IA options (avoids needing to=20 look ahead for it). Also, for relays and servers that will be load balancing,=20 finding this quickly means that relays can forward the message quicker and=20 servers can ignore the message sooner (if not in their load balancing range).=20 As it is required in every client message, making it first would be beneficial.=20 While it would be nice to make this a MUST, I would be happy with a SHOULD.=20 I guess one other option might be to make it part of the header, but I like it=20 better as an option.=20 3. Is the 16-bit Transaction ID really sufficient? I would like to understand=20 why reducing the number of bits from 32 (DHCPv4) to 16 is justified. A 1 out=20 of 65536 chance is a lot higher than a 1 out of 2^32 chance of a collision.=20 Especially if clients don't have stable storage to save the last transaction ID=20 (or don't want the 'cost' of using stable storage for this).=20 This is relevant if XID is used to check duplicate packets on the client or server side. The chances of collision is somewhat unlikely in the client if it keeps incrementing a counter. 4. Is there any need for a 'secs' field? While the current specification is=20 really based on the assumption that (request)/Reply messages are exchanged=20 between client and one server, with the use of the anycast address or multicast=20 addresses for a "pool" of DHCP servers, having a 'secs' field does allow for=20 another member of the "pool" of servers to answer should the server assigned to=20 answer not be available. Note that servers could do this without a secs field,=20 but it does mean they need to save some state of these requests.=20 =20 Secs field can also be used by a router to do load balancing/fault tolerance. Eg: relay can forward the packet to a different dhcp server if seconds field is non zero or above a certain threshold. If there are other mechanisms to do it - this field may not be needed. Note that perhaps with issue 3 and 4 a new header can be defined that=20 incorporates both a 32-bit transaction ID and a secs-like field?=20 - Bernie Volz=20 Ericsson=20 ------_=_NextPart_001_01C10B2B.A39E7A88 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Discussion items for dhcpv6 -19 draft ...

Comments on Bernie’s = suggestions inline:

 

-----Original = Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Tuesday, July 10, 2001 6:56 = AM
To: DHCPv6 discussion = list
Subject: Discussion items = for dhcpv6 -19 draft ...

 

Some discussion = items from the DHCPv6 -19 draft for the Working Group to
consider:

1. I like the = format of the option as per the -19 draft - in particular, the
DUID-type. However, it seems as if the DUID len is either not = necessary
(since it is just option-len - 2) OR making it one byte would be more = than
sufficient (since we probably should set a reasonable upper limit of = something
like 32 bytes for the DUID). I do like the fact that it is variable - so = I
do NOT suggest we make it a fixed length field.

         &= nbsp;  There is a need to have a limit on the length of DUID. If the length of = DUID is the option length the max length of DUID is 64K bytes. This is going to = put a burden on the server to store it and compare it to the client’s = DUID every single time. I would say one octet for DUID length should = suffice.

2. Should there be = any recommendation (requirement) on the ordering of the
DUID option? It might make server processing simplier and easier if the =
DUID is always required to be BEFORE any IA options (avoids needing to =
look ahead for it). Also, for relays and servers that will be load = balancing,
finding this quickly means that relays can forward the message quicker = and
servers can ignore the message sooner (if not in their load balancing = range).

As it is required = in every client message, making it first would be beneficial.
While it would be nice to make this a MUST, I would be happy with a = SHOULD.

I guess one other = option might be to make it part of the header, but I like it
better as an option.

3. Is the 16-bit = Transaction ID really sufficient? I would like to understand
why reducing the number of bits from 32 (DHCPv4) to 16 is justified. A 1 = out
of 65536 chance is a lot higher than a 1 out of 2^32 chance of a = collision.
Especially if clients don't have stable storage to save the last transaction = ID
(or don't want the 'cost' of using stable storage for this). =

         &= nbsp;  This is relevant if XID is used to check duplicate packets on the client = or server side. The chances of collision is somewhat unlikely in the client = if it keeps incrementing a counter.

4. Is there any = need for a 'secs' field? While the current specification is
really based on the assumption that (request)/Reply messages are = exchanged
between client and one server, with the use of the anycast address or = multicast
addresses for a "pool" of DHCP servers, having a 'secs' field does allow = for
another member of the "pool" of servers to answer should the server = assigned to
answer not be available. Note that servers could do this without a secs = field,
but it does mean they need to save some state of these = requests.

 

         &= nbsp;  Secs field can also be used by a router to do load balancing/fault = tolerance. Eg: relay can forward the packet to a different dhcp server if seconds = field is non zero or above a certain threshold. If there are other mechanisms to = do it – this field may not be needed.

Note that perhaps = with issue 3 and 4 a new header can be defined that
incorporates both a 32-bit transaction ID and a secs-like field?

- Bernie = Volz
  Ericsson

=00 ------_=_NextPart_001_01C10B2B.A39E7A88-- From owner-dhcp-v6@bucknell.edu Fri Jul 13 01:07:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23158; Fri, 13 Jul 2001 01:07:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6D57hL11322; Fri, 13 Jul 2001 01:07:43 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6D57bL27757 for ; Fri, 13 Jul 2001 01:07:38 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6D53df03200 for ; Thu, 12 Jul 2001 22:03:39 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6D50Fb01834 for ; Thu, 12 Jul 2001 22:00:15 -0700 (MST) Message-Id: <200107130500.f6D50Fb01834@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Discussion items for dhcpv6 -19 draft ... In-Reply-To: Message from "Bernie Volz (EUD)" of "Thu, 12 Jul 2001 15:58:59 EST." <66F66129A77AD411B76200508B65AC697B3262@eambunt705.ena-east.ericsson.se> Date: Thu, 12 Jul 2001 22:00:15 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > OK. I'm happy if we add the IAIDs (and I'd also suggest the request > type just to be safe). Then we can leave the XID as 16-bits. Actually, I just checked, and it's already there. The current draft calls for entries in the cache to be indexed by {xid, binding}. A binding includes both the IAID and the DUID. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Jul 13 01:10:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23873; Fri, 13 Jul 2001 01:10:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6D5AUL17491; Fri, 13 Jul 2001 01:10:30 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6D5APL18396 for ; Fri, 13 Jul 2001 01:10:26 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6D56Rf03204 for ; Thu, 12 Jul 2001 22:06:27 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6D533b01842 for ; Thu, 12 Jul 2001 22:03:03 -0700 (MST) Message-Id: <200107130503.f6D533b01842@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: DHCPNAK for DHCPv6? Date: Thu, 12 Jul 2001 22:03:03 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN One thing I just noticed about the latest draft is that there is no equivalent of a DHCPNAK sent in response to a request to renew an address when the client has moved to a different network link. This behaviour is extremely important - without it, whenever the client changes networks it has to wait for its lease to expire before it can get a new IP address. Am I correct in thinking that this is missing, or is it I who am missing something? _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Jul 13 06:39:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA14917; Fri, 13 Jul 2001 06:39:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DAe9L04395; Fri, 13 Jul 2001 06:40:09 -0400 (EDT) Received: from prv-mail25.provo.novell.com (prv-mail25.provo.novell.com [137.65.81.121]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6DAe4L18476 for ; Fri, 13 Jul 2001 06:40:04 -0400 (EDT) Received: from INET-PRV1-MTA by prv-mail25.provo.novell.com with Novell_GroupWise; Fri, 13 Jul 2001 04:32:19 -0600 Message-Id: X-Mailer: Novell GroupWise Internet Agent 6.0 Date: Fri, 13 Jul 2001 04:32:05 -0600 From: "Vijay KN" To: DHCPv6 discussion list Cc: "Mark Hinckley" , "Mark Meredith" Subject: Re: DHC WG scheduling for London Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=_F7AD8F24.4524931B" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_F7AD8F24.4524931B Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Ralph, =20 We would like to include the new DHCP LDAP Schema draft (draft-ietf-dhc-lda= p-schema-00.txt) for discussion at the DHC WG meet. I had sent an e-mail = earlier about this. Can this be included in the DHC WG agenda ? =20 Regards Vijay >>> rdroms@cisco.com 07/11/01 01:56AM >>> The DHC WG will meet Wed AM (see below). This meeting will cover both=20 DHCPv4 and DHCPv6 issues. Please let me know if you have items to be = added=20 to the agenda. - Ralph WEDNESDAY, August 8, 2001 0900-1130 Morning Sessions APP calsch Calendaring and Scheduling WG INT dhc Dynamic Host Configuration WG OPS opsarea Operations & Management Open Area RTG mobileip IP Routing for Wireless/Mobile Hosts WG SEC smime S/MIME Mail Security WG SUB-IP ccamp Common Control and Measurement Plane WG TSV avt Audio/Video Transport WG TSV midcom Middlebox Communication WG --=_F7AD8F24.4524931B Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Ralph,
 
We would like to include the new DHCP LDAP Schema = draft=20 (draft-ietf-dhc-ldap-schema-00.txt) for discussion at the DHC WG meet. I = had=20 sent an e-mail earlier about this. Can this be included in the DHC WG = agenda=20 ?
 
Regards
Vijay

>>> rdroms@cisco.com 07/11/01 01:56AM >>>
The= DHC=20 WG will meet Wed AM (see below).  This meeting will cover both =
DHCPv4=20 and DHCPv6 issues.  Please let me know if you have items to be added =
to=20 the agenda.

- Ralph

WEDNESDAY, August 8, 2001

0900-113= 0=20 Morning Sessions
APP    =20 calsch          Calendaring = and=20 Scheduling WG
INT    =20 dhc            = =20 Dynamic Host Configuration WG
OPS    =20 opsarea         Operations = &=20 Management Open Area
RTG    =20 mobileip        IP Routing for=20 Wireless/Mobile Hosts WG
SEC    =20 smime           S/MIME = Mail=20 Security WG
SUB-IP =20 ccamp           Common = Control=20 and Measurement Plane WG
TSV    =20 avt            = =20 Audio/Video Transport WG
TSV    =20 midcom          Middlebox=20 Communication WG

--=_F7AD8F24.4524931B-- From owner-dhcp-v6@bucknell.edu Fri Jul 13 09:30:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06643; Fri, 13 Jul 2001 09:30:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DDU3L27345; Fri, 13 Jul 2001 09:30:03 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6DDTpL28702 for ; Fri, 13 Jul 2001 09:29:51 -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 f6DDTnp17322 for ; Fri, 13 Jul 2001 08:29:50 -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 f6DDTnM25847 for ; Fri, 13 Jul 2001 08:29:49 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Fri Jul 13 08:29:49 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP2XGDW>; Fri, 13 Jul 2001 08:29:48 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3269@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? Date: Fri, 13 Jul 2001 08:29:47 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10B9F.E2ABCCA0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10B9F.E2ABCCA0 Content-Type: text/plain; charset="iso-8859-1" I believe this is covered in the status field in the IA option. Section 7.4 has various error codes that can be returned in IA status or addr status (the text isn't as clear as to which status codes are where as it could be). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IA status | num-addrs |T| addr status | prefix length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note however that I did comment to Ralph that the -19 draft has no mechanism for the server (or client) to communicate any status if there is no IA option. So, I think that a general error status option (with perhaps a 16-bit code followed by a variable length string for human consumption) be considered. I think it is fine to use the Reply message type since that that is a generic reply message. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Friday, July 13, 2001 1:03 AM To: DHCPv6 discussion list Subject: DHCPNAK for DHCPv6? One thing I just noticed about the latest draft is that there is no equivalent of a DHCPNAK sent in response to a request to renew an address when the client has moved to a different network link. This behaviour is extremely important - without it, whenever the client changes networks it has to wait for its lease to expire before it can get a new IP address. Am I correct in thinking that this is missing, or is it I who am missing something? _MelloN_ ------_=_NextPart_001_01C10B9F.E2ABCCA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

I believe this is covered in the status field in the = IA option. Section 7.4 has various error codes that can be returned in = IA status or addr status (the text isn't as clear as to which status = codes are where as it could be).

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     |   IA = status   |   num-addrs   |T| addr status = | prefix length |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=

Note however that I did comment to Ralph that the -19 = draft has no mechanism for the server (or client) to communicate any = status if there is no IA option. So, I think that a general error = status option (with perhaps a 16-bit code followed by a variable length = string for human consumption) be considered.

I think it is fine to use the Reply message type = since that that is a generic reply message.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Friday, July 13, 2001 1:03 AM
To: DHCPv6 discussion list
Subject: DHCPNAK for DHCPv6?



One thing I just noticed about the latest draft is = that there is no
equivalent of a DHCPNAK sent in response to a = request to renew an
address when the client has moved to a different = network link.  This
behaviour is extremely important - without it, = whenever the client
changes networks it has to wait for its lease to = expire before it can
get a new IP address.

Am I correct in thinking that this is missing, or is = it I who am
missing something?

        =         =                _MelloN_

------_=_NextPart_001_01C10B9F.E2ABCCA0-- From owner-dhcp-v6@bucknell.edu Fri Jul 13 09:32:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07038; Fri, 13 Jul 2001 09:32:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DDX9L32426; Fri, 13 Jul 2001 09:33:09 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6DDX8L31035 for ; Fri, 13 Jul 2001 09:33:09 -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 f6DDX7p19624 for ; Fri, 13 Jul 2001 08:33:08 -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 f6DDX7M26969 for ; Fri, 13 Jul 2001 08:33:07 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Fri Jul 13 08:33:07 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP2XGKP>; Fri, 13 Jul 2001 08:33:07 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B326A@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Discussion items for dhcpv6 -19 draft ... Date: Fri, 13 Jul 2001 08:33:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10BA0.59820290" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10BA0.59820290 Content-Type: text/plain; charset="iso-8859-1" OK. I was thinking that binding just referred to the DHID but it does say it includes that IAID (in section 6.2). So, we are hopefully OK. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Friday, July 13, 2001 1:00 AM To: DHCPv6 discussion list Subject: Re: Discussion items for dhcpv6 -19 draft ... > OK. I'm happy if we add the IAIDs (and I'd also suggest the request > type just to be safe). Then we can leave the XID as 16-bits. Actually, I just checked, and it's already there. The current draft calls for entries in the cache to be indexed by {xid, binding}. A binding includes both the IAID and the DUID. _MelloN_ ------_=_NextPart_001_01C10BA0.59820290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Discussion items for dhcpv6 -19 draft ...

OK. I was thinking that binding just referred to the = DHID but it does say it includes that IAID (in section 6.2). So, we are = hopefully OK.

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Friday, July 13, 2001 1:00 AM
To: DHCPv6 discussion list
Subject: Re: Discussion items for dhcpv6 -19 draft = ...



> OK. I'm happy if we add the IAIDs (and I'd also = suggest the request
> type just to be safe). Then we can leave the = XID as 16-bits.

Actually, I just checked, and it's already = there.   The current draft
calls for entries in the cache to be indexed by = {xid, binding}.
A binding includes both the IAID and the = DUID.

        =         =                _MelloN_

------_=_NextPart_001_01C10BA0.59820290-- From owner-dhcp-v6@bucknell.edu Fri Jul 13 12:31:15 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02589; Fri, 13 Jul 2001 12:31:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DGVHL00505; Fri, 13 Jul 2001 12:31:17 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6DGV1L29148 for ; Fri, 13 Jul 2001 12:31:02 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6DGR1f04518 for ; Fri, 13 Jul 2001 09:27:01 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6DGMob02691 for ; Fri, 13 Jul 2001 09:22:50 -0700 (MST) Message-Id: <200107131622.f6DGMob02691@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: Message from "Bernie Volz (EUD)" of "Fri, 13 Jul 2001 08:29:47 EST." <66F66129A77AD411B76200508B65AC697B3269@eambunt705.ena-east.ericsson.se> Date: Fri, 13 Jul 2001 09:22:50 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I believe this is covered in the status field in the IA > option. Section 7.4 has various error codes that can be returned in > IA status or addr status (the text isn't as clear as to which status > codes are where as it could be). No, that's not the problem. I agree that the DHCP Reply status code "InvalidSource" solves the problem of sending a DHCPNAK - the problem is that the draft doesn't say when one would be generated, or how, or what the client should do when one is received. Here's the problem: the draft never says *what* IAs you can configure in a message. So as an implementor, how do I program my client to handle the case where there is more than one interface? It looks from the protocol specification like I can just send a DHCP Solicit on any one interface listing IAs for each interface to be configured. Or maybe I should send the Solicit on *all* interfaces? Of course, we are DHCP geeks, and we know that we should send one Solicit out each interface containing one IA that is specific to the interface being configured. But the draft doesn't say this. Then, there's no guidance in the draft about how the server chooses IP addresses. Presumably, if the client message is received encapsulated in a Relay-forward message, the server should assign an IP address that will work on the subnet on which the relay agent reported that the message was received, and if the message was not received in a Relay-forward message, the server assigns an IP address on the network segment to which the network interface on which the packet was received is connected. But again, this is never mentioned in the draft. Further, once you *have* an address configured, it would be very tempting to clump all the IAs into one unicast message for renewals. This would probably work fine in a Renew message, but what about in a Confirm message? Obviously this won't work, but the draft offers no guidance. I think that the language for the Confirm message does a reasonable job of solving this problem *if* we add language to the other messages offering guidance about what IAs can be mentioned. We could attach language to the Solicit, Request and Confirm messages saying that only IAs for addresses for the interface on which the message is being sent may be included in these messages, and that if the client is trying to configure more than one interface, it should send one of these messages on each interface. I *think* that would solve the problem, but the language that talks about how to handle responses in that case still doesn't seem right. Shouldn't it be possible for *any* server listening on the link on which the client is trying to Confirm to send a message saying "you're on the wrong link?" The present language implies that only the server that issued the original IA will respond, and doesn't mention any sort of response that says "you're on the wrong network." Here's the language for servers: When the server receives a Confirm and an IA option is included the client is requesting confirmation that the addresses in the IA are valid. The server SHOULD locate the clients binding and verify the information in the IA from the client matches the information stored for that client. If the server cannot find a client entry for this IA the server SHOULD return an empty IA with status set to NoBinding. If the server finds that the information for the client does not match what is in the server's records for that client the server should send back an empty IA with status set to Conf_NoMatch. If the server finds a match to the Confirm then the server should send back the IA to the client with status set to success. There's nothing in here about validating the address as to whether or not it is correct for the link to which the client is attached. There is an InvalidSource error message, but its use isn't documented. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Jul 13 12:33:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02808; Fri, 13 Jul 2001 12:33:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DGXKL24642; Fri, 13 Jul 2001 12:33:20 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DGXKL17073 for ; Fri, 13 Jul 2001 12:33:20 -0400 (EDT) Received: from 157.54.9.101 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Jul 2001 09:30:22 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 13 Jul 2001 09:32:08 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 13 Jul 2001 09:32:04 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 13 Jul 2001 09:31:26 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10BB9.42BEB4B5" Subject: RE: DHCPNAK for DHCPv6? Date: Fri, 13 Jul 2001 09:31:25 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC162B6B9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: DHCPNAK for DHCPv6? Thread-Index: AcELoBPJ6b55ywhwSp63fpwlkRvmXwAGIx3Q From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 13 Jul 2001 16:31:26.0126 (UTC) FILETIME=[42D5FCE0:01C10BB9] Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------_=_NextPart_001_01C10BB9.42BEB4B5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think not having NAK is fine. It caused a lot of grief in V4 to get the NAK part right.=20 =20 The main problem when changing networks is the amount of time it takes to get a new address in the absence of a NAK. Let us say you switch from network A to network B - you try to contact the DHCP server to verify that you can continue using the leases. You have to wait for your request to time out before going to the init state and requesting another address if there isnt a NAK. This process can take more than a minute in a V4 network. =20 In the absence of a NAK - the client can directly go to the INIT state with its DUID on changing networks. It can get the same set of addresses or a different set of addresses depending on the DHCP Server it is now talking to. =20 thx =20 -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]=20 Sent: Friday, July 13, 2001 6:30 AM To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? =20 I believe this is covered in the status field in the IA option. Section 7.4 has various error codes that can be returned in IA status or addr status (the text isn't as clear as to which status codes are where as it could be). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | IA status | num-addrs |T| addr status | prefix length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 Note however that I did comment to Ralph that the -19 draft has no mechanism for the server (or client) to communicate any status if there is no IA option. So, I think that a general error status option (with perhaps a 16-bit code followed by a variable length string for human consumption) be considered. I think it is fine to use the Reply message type since that that is a generic reply message.=20 - Bernie=20 -----Original Message-----=20 From: Ted Lemon [mailto:mellon@nominum.com]=20 Sent: Friday, July 13, 2001 1:03 AM=20 To: DHCPv6 discussion list=20 Subject: DHCPNAK for DHCPv6?=20 =20 One thing I just noticed about the latest draft is that there is no=20 equivalent of a DHCPNAK sent in response to a request to renew an=20 address when the client has moved to a different network link. This=20 behaviour is extremely important - without it, whenever the client=20 changes networks it has to wait for its lease to expire before it can=20 get a new IP address.=20 Am I correct in thinking that this is missing, or is it I who am=20 missing something?=20 _MelloN_=20 ------_=_NextPart_001_01C10BB9.42BEB4B5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

I think not having NAK is fine. It = caused a lot of grief in V4 to get the NAK part right.

 

The main problem when changing = networks is the amount of time it takes to get a new address in the absence of a = NAK. Let us say you switch from network A to network B – you try to contact = the DHCP server to verify that you can continue using the leases. You have = to wait for your request to time out before going to the init state and = requesting another address if there isnt a NAK. This process can take more than a = minute in a V4 network.

 

In the absence of a NAK – the = client can directly go to the INIT state with its DUID on changing networks. =  It can get the same set of addresses or a different set of addresses = depending on the DHCP Server it is now talking to.

 

thx

 

-----Original = Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Friday, July 13, = 2001 6:30 AM
To: DHCPv6 discussion = list
Subject: RE: DHCPNAK for = DHCPv6?

 

I believe this is covered in the status field = in the IA option. Section 7.4 has various error codes that can be returned in = IA status or addr status (the text isn't as clear as to which status codes = are where as it could be).

     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>
     |   IA status   |   num-addrs   = |T| addr status | prefix length |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

Note however that I did comment to Ralph that = the -19 draft has no mechanism for the server (or client) to communicate any = status if there is no IA option. So, I think that a general error status option = (with perhaps a 16-bit code followed by a variable length string for human consumption) be considered.

I think it is fine to use the Reply message = type since that that is a generic reply message.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]<= /font>
Sent: Friday, July 13, = 2001 1:03 AM
To: DHCPv6 discussion = list
Subject: DHCPNAK for = DHCPv6?

 

One thing I just noticed about the latest = draft is that there is no
equivalent of a DHCPNAK = sent in response to a request to renew an
address when the client = has moved to a different network link.  This
behaviour is extremely = important - without it, whenever the client
changes networks it has = to wait for its lease to expire before it can
get a new IP = address.

Am I correct in thinking that this is = missing, or is it I who am
missing = something?

                =                _MelloN_

=00 ------_=_NextPart_001_01C10BB9.42BEB4B5-- From owner-dhcp-v6@bucknell.edu Fri Jul 13 12:49:29 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05309; Fri, 13 Jul 2001 12:49:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DGnoL25302; Fri, 13 Jul 2001 12:49:50 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6DGnjL06961 for ; Fri, 13 Jul 2001 12:49:46 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6DGjjf04540 for ; Fri, 13 Jul 2001 09:45:45 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6DGfXb02721 for ; Fri, 13 Jul 2001 09:41:33 -0700 (MST) Message-Id: <200107131641.f6DGfXb02721@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: Message from "Thirumalesh Bhat" of "Fri, 13 Jul 2001 09:31:25 MST." <2E33960095B58E40A4D3345AB9F65EC162B6B9@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 13 Jul 2001 09:41:33 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I think not having NAK is fine. It caused a lot of grief in V4 to get > the NAK part right.=20 That had more to do with figuring out what state the client is in than it did with anything else. We don't have the problem of figuring out the client state, so this is a non-issue. More to the point, DHCPNAK *does* something. We can't just leave it out. > In the absence of a NAK - the client can directly go to the INIT state > with its DUID on changing networks. It can get the same set of > addresses or a different set of addresses depending on the DHCP Server > it is now talking to. That's not what the specification says right now. According to the spec as it stands, we would have to wait for the timeout. When I change networks, I want a new address immediately, not after some long tiemout period has expired. But moving straight to sending a Solicit isn't right either. When the client detects a "link change", it may not actually have moved - it just suspects that it *may* have moved. So I want to keep my old IA if I can. So using Confirm is correct. The problem isn't that. The problem is that the spec doesn't say what the server should do when I send a Confirm while I'm on the wrong network, or what the client should do when it gets a Reply saying "you're on the wrong network." _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Jul 13 13:12:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08636; Fri, 13 Jul 2001 13:12:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DHDCL15437; Fri, 13 Jul 2001 13:13:12 -0400 (EDT) Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DHCwL24913 for ; Fri, 13 Jul 2001 13:12:59 -0400 (EDT) Received: from 157.54.9.104 by mail5.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 13 Jul 2001 10:12:43 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 13 Jul 2001 10:12:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 13 Jul 2001 10:12:17 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 13 Jul 2001 10:11:39 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: DHCPNAK for DHCPv6? Date: Fri, 13 Jul 2001 10:11:39 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC162B6BB@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: DHCPNAK for DHCPv6? Thread-Index: AcELu8NkTAOq4VKhSdKZv21lGrxZaAAAbLgg From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 13 Jul 2001 17:11:39.0878 (UTC) FILETIME=[E18B5060:01C10BBE] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f6DHCxL22903 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit You point is correct as far as DHCP is concerned in a V4 network. In a V6 network, I don't see that there is as strong a reason to have NAK implementation. Also, we are not addressing every state the client can be in -examples are client gets a media connect/disconnect event, client going to standby or hibernation. The main reason is that DHCP won't be as critical in a V6 network for address distribution as it is in a V4 network. DHCP will be more useful in handing out options in a V6 network. Secondly, what happens if the relay is configured to forward the DHCP messages to more than one server? (a common config in V4 network ) In this case - the faster server can NAK the client causing it to go to the INIT state unnecessarily. thx -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Friday, July 13, 2001 9:42 AM To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? > I think not having NAK is fine. It caused a lot of grief in V4 to get > the NAK part right.=20 That had more to do with figuring out what state the client is in than it did with anything else. We don't have the problem of figuring out the client state, so this is a non-issue. More to the point, DHCPNAK *does* something. We can't just leave it out. > In the absence of a NAK - the client can directly go to the INIT state > with its DUID on changing networks. It can get the same set of > addresses or a different set of addresses depending on the DHCP Server > it is now talking to. That's not what the specification says right now. According to the spec as it stands, we would have to wait for the timeout. When I change networks, I want a new address immediately, not after some long tiemout period has expired. But moving straight to sending a Solicit isn't right either. When the client detects a "link change", it may not actually have moved - it just suspects that it *may* have moved. So I want to keep my old IA if I can. So using Confirm is correct. The problem isn't that. The problem is that the spec doesn't say what the server should do when I send a Confirm while I'm on the wrong network, or what the client should do when it gets a Reply saying "you're on the wrong network." _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Jul 13 14:05:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16057; Fri, 13 Jul 2001 14:05:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DI57L17837; Fri, 13 Jul 2001 14:05:07 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6DI4pL32039 for ; Fri, 13 Jul 2001 14:04:51 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6DI0hf04642 for ; Fri, 13 Jul 2001 11:00:43 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6DI4cb02780 for ; Fri, 13 Jul 2001 11:04:38 -0700 (MST) Message-Id: <200107131804.f6DI4cb02780@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: Message from "Thirumalesh Bhat" of "Fri, 13 Jul 2001 10:11:39 MST." <2E33960095B58E40A4D3345AB9F65EC162B6BB@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Fri, 13 Jul 2001 11:04:38 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The main reason is that DHCP won't be as critical in a V6 network > for address distribution as it is in a V4 network. DHCP will be more > useful in handing out options in a V6 network. So you are arguing that because DHCP isn't critical, it doesn't have to work? I think this is a bad basis upon which to implement a protocol specification - either we shouldn't do it at all, or we should take out the parts that aren't needed, or we should do it right. The feature set that is in the specification is the one we agreed to. I don't think the WG would agree that we should take out the address assignment part - I certainly don't. So we should specify it in a way that will work. > Secondly, what happens if the relay is configured to forward the DHCP > messages to more than one server? (a common config in V4 network ) In > this case - the faster server can NAK the client causing it to go to the > INIT state unnecessarily. This is true of V4 as well, and this doesn't happen if the DHCP servers are configured properly. If they are not configured properly, that is hardly the protocol's fault. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Jul 13 19:25:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27853; Fri, 13 Jul 2001 19:25:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DNPBL02393; Fri, 13 Jul 2001 19:25:11 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6DNOtL06711 for ; Fri, 13 Jul 2001 19:24:55 -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 f6DNOsp08226 for ; Fri, 13 Jul 2001 18:24:55 -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 f6DNOsN23913 for ; Fri, 13 Jul 2001 18:24:54 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Fri Jul 13 18:24:54 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP2YQJA>; Fri, 13 Jul 2001 18:24:54 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B326E@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? Date: Fri, 13 Jul 2001 18:24:51 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10BF3.04175140" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10BF3.04175140 Content-Type: text/plain; charset="iso-8859-1" Ted: I had raised this issue a long time ago. I wanted status codes for a CONFIRM that a server could send that said: - Prefixes are correct, but I can't say your addresses are. This was to be used by a server that served the network but did not assign the addresses to the client. It also means that the client can know it has not moved in such a way that its addresses are bad. - Prefixes are not correct. Now, what I'd suggested is that if a client receives an "Success" from a server, it can use the addresses. If it receives a "prefixes are correct" from the server it can use the addresses (it should wait around a bit to see if a server does response with success). If it receives "prefixes are not correct", then it should take steps to get new addresses. Note that the above two status codes say nothing about the binding because the server can't - it has no information on the bindings (perhaps the Prefixes are not correct is not needed since an existing error covers it). - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Friday, July 13, 2001 12:42 PM To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? > I think not having NAK is fine. It caused a lot of grief in V4 to get > the NAK part right.=20 That had more to do with figuring out what state the client is in than it did with anything else. We don't have the problem of figuring out the client state, so this is a non-issue. More to the point, DHCPNAK *does* something. We can't just leave it out. > In the absence of a NAK - the client can directly go to the INIT state > with its DUID on changing networks. It can get the same set of > addresses or a different set of addresses depending on the DHCP Server > it is now talking to. That's not what the specification says right now. According to the spec as it stands, we would have to wait for the timeout. When I change networks, I want a new address immediately, not after some long tiemout period has expired. But moving straight to sending a Solicit isn't right either. When the client detects a "link change", it may not actually have moved - it just suspects that it *may* have moved. So I want to keep my old IA if I can. So using Confirm is correct. The problem isn't that. The problem is that the spec doesn't say what the server should do when I send a Confirm while I'm on the wrong network, or what the client should do when it gets a Reply saying "you're on the wrong network." _MelloN_ ------_=_NextPart_001_01C10BF3.04175140 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

Ted:

I had raised this issue a long time ago. I wanted = status codes for a CONFIRM that a server could send that said:

- Prefixes are correct, but I can't say your = addresses are. This was to be used by a server that served the network = but did not assign the addresses to the client. It also means that the = client can know it has not moved in such a way that its addresses are = bad.

- Prefixes are not correct.

Now, what I'd suggested is that if a client receives = an "Success" from a server, it can use the addresses. If it = receives a "prefixes are correct" from the server it can use = the addresses (it should wait around a bit to see if a server does = response with success). If it receives "prefixes are not = correct", then it should take steps to get new = addresses.

Note that the above two status codes say nothing = about the binding because the server can't - it has no information on = the bindings (perhaps the Prefixes are not correct is not needed since = an existing error covers it).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Friday, July 13, 2001 12:42 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6?



> I think not having NAK is fine. It caused a lot = of grief in V4 to get
> the NAK part right.=3D20

That had more to do with figuring out what state the = client is in than
it did with anything else.   We don't have = the problem of figuring out
the client state, so this is a non-issue.

More to the point, DHCPNAK *does* = something.   We can't just leave it
out.

> In the absence of a NAK - the client can = directly go to the INIT state
> with its DUID on changing networks.  It = can get the same set of
> addresses or a different set of addresses = depending on the DHCP Server
> it is now talking to.

That's not what the specification says right = now.  According to the
spec as it stands, we would have to wait for the = timeout.  When I
change networks, I want a new address immediately, = not after some long
tiemout period has expired.   But moving = straight to sending a Solicit
isn't right either.   When the client = detects a "link change", it may
not actually have moved - it just suspects that it = *may* have moved.
So I want to keep my old IA if I can.   So = using Confirm is correct.
The problem isn't that.   The problem is = that the spec doesn't say
what the server should do when I send a Confirm = while I'm on the wrong
network, or what the client should do when it gets a = Reply saying
"you're on the wrong network."

        =         =                _MelloN_

------_=_NextPart_001_01C10BF3.04175140-- From owner-dhcp-v6@bucknell.edu Fri Jul 13 19:57:52 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02290; Fri, 13 Jul 2001 19:57:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6DNwIL16018; Fri, 13 Jul 2001 19:58:18 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6DNwAL22352 for ; Fri, 13 Jul 2001 19:58:10 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6DNs9f05084 for ; Fri, 13 Jul 2001 16:54:10 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6DNvhb05468 for ; Fri, 13 Jul 2001 16:57:43 -0700 (MST) Message-Id: <200107132357.f6DNvhb05468@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: Message from "Bernie Volz (EUD)" of "Fri, 13 Jul 2001 18:24:51 EST." <66F66129A77AD411B76200508B65AC697B326E@eambunt705.ena-east.ericsson.se> Date: Fri, 13 Jul 2001 16:57:43 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Note that the above two status codes say nothing about the binding > because the server can't - it has no information on the bindings > (perhaps the Prefixes are not correct is not needed since an > existing error covers it). What you described seems like it would work, with one caveat. We need to explicitly say that in DHCP Solicit, Request and Confirm message, only IAs for the interface on which the packet is transmitted may be included. Otherwise, the server isn't in a position to make address allocation decisions based on network topology information. It might also be necessary to place this restriction on the DHCP Rebind message - I'm not sure. _MelloN_ From owner-dhcp-v6@bucknell.edu Sun Jul 15 23:37:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15036; Sun, 15 Jul 2001 23:37:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6G3auL29751; Sun, 15 Jul 2001 23:36:56 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6G3ahL03982 for ; Sun, 15 Jul 2001 23:36:44 -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 f6G3ahp17629 for ; Sun, 15 Jul 2001 22:36:43 -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 f6G3ahN25551 for ; Sun, 15 Jul 2001 22:36:43 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Jul 15 22:36:42 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKB16T>; Sun, 15 Jul 2001 22:36:42 -0500 Message-ID: <66F66129A77AD411B76200508B65AC696D1B2F@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? Date: Sun, 15 Jul 2001 22:36:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10DA8.87154730" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10DA8.87154730 Content-Type: text/plain; charset="iso-8859-1" Ted: I agree that we likely need to tighten up the specification. I think the assumption is that an IA (IAID) is bound to a specific interface and that IA (IAID) should only be used on that interface as long as it is in use (has a prefix that hasn't become invalid). Now, this might have some impact if I change my NIC card because I may now loose all of my old addresses. But, I think that's a small price to pay (it also has some attractions since if I plug in different cards at home and at work, I can retain my home addresses while I'm at work since the IAIDs for the home interface continue to exist and will be valid again when I plug in at home). >Then, there's no guidance in the draft about how the server chooses IP >addresses. I've always thought we needed text around this subject. I agree that we're kind of assuming a lot - the obvious is for the server to assign addresses with the correct prefixes. But, we should also have recommendations with regards to servers generating addresses. For example, simply incrementing addresses by 1 or some fixed number might be bad (predictive and leaks information). Also, perhaps there should be recommendations against using addresses that could be generated by stateless (with the 'u' bit set) since there could be issues if one switches between stateful/stateless? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Friday, July 13, 2001 12:23 PM To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? > I believe this is covered in the status field in the IA > option. Section 7.4 has various error codes that can be returned in > IA status or addr status (the text isn't as clear as to which status > codes are where as it could be). No, that's not the problem. I agree that the DHCP Reply status code "InvalidSource" solves the problem of sending a DHCPNAK - the problem is that the draft doesn't say when one would be generated, or how, or what the client should do when one is received. Here's the problem: the draft never says *what* IAs you can configure in a message. So as an implementor, how do I program my client to handle the case where there is more than one interface? It looks from the protocol specification like I can just send a DHCP Solicit on any one interface listing IAs for each interface to be configured. Or maybe I should send the Solicit on *all* interfaces? Of course, we are DHCP geeks, and we know that we should send one Solicit out each interface containing one IA that is specific to the interface being configured. But the draft doesn't say this. Then, there's no guidance in the draft about how the server chooses IP addresses. Presumably, if the client message is received encapsulated in a Relay-forward message, the server should assign an IP address that will work on the subnet on which the relay agent reported that the message was received, and if the message was not received in a Relay-forward message, the server assigns an IP address on the network segment to which the network interface on which the packet was received is connected. But again, this is never mentioned in the draft. Further, once you *have* an address configured, it would be very tempting to clump all the IAs into one unicast message for renewals. This would probably work fine in a Renew message, but what about in a Confirm message? Obviously this won't work, but the draft offers no guidance. I think that the language for the Confirm message does a reasonable job of solving this problem *if* we add language to the other messages offering guidance about what IAs can be mentioned. We could attach language to the Solicit, Request and Confirm messages saying that only IAs for addresses for the interface on which the message is being sent may be included in these messages, and that if the client is trying to configure more than one interface, it should send one of these messages on each interface. I *think* that would solve the problem, but the language that talks about how to handle responses in that case still doesn't seem right. Shouldn't it be possible for *any* server listening on the link on which the client is trying to Confirm to send a message saying "you're on the wrong link?" The present language implies that only the server that issued the original IA will respond, and doesn't mention any sort of response that says "you're on the wrong network." Here's the language for servers: When the server receives a Confirm and an IA option is included the client is requesting confirmation that the addresses in the IA are valid. The server SHOULD locate the clients binding and verify the information in the IA from the client matches the information stored for that client. If the server cannot find a client entry for this IA the server SHOULD return an empty IA with status set to NoBinding. If the server finds that the information for the client does not match what is in the server's records for that client the server should send back an empty IA with status set to Conf_NoMatch. If the server finds a match to the Confirm then the server should send back the IA to the client with status set to success. There's nothing in here about validating the address as to whether or not it is correct for the link to which the client is attached. There is an InvalidSource error message, but its use isn't documented. _MelloN_ ------_=_NextPart_001_01C10DA8.87154730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

Ted:

I agree that we likely need to tighten up the = specification. I think the assumption is that an IA (IAID) is bound to = a specific interface and that IA (IAID) should only be used on that = interface as long as it is in use (has a prefix that hasn't become = invalid).

Now, this might have some impact if I change my NIC = card because I may now loose all of my old addresses. But, I think = that's a small price to pay (it also has some attractions since if I = plug in different cards at home and at work, I can retain my home = addresses while I'm at work since the IAIDs for the home interface = continue to exist and will be valid again when I plug in at = home).

>Then, there's no guidance in the draft about how = the server chooses IP
>addresses.

I've always thought we needed text around this = subject. I agree that we're kind of assuming a lot - the obvious is for = the server to assign addresses with the correct prefixes. But, we = should also have recommendations with regards to servers generating = addresses. For example, simply incrementing addresses by 1 or some = fixed number might be bad (predictive and leaks information). Also, = perhaps there should be recommendations against using addresses that = could be generated by stateless (with the 'u' bit set) since there = could be issues if one switches between stateful/stateless?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Friday, July 13, 2001 12:23 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6?



> I believe this is covered in the status field in = the IA
> option. Section 7.4 has various error codes = that can be returned in
> IA status or addr status (the text isn't as = clear as to which status
> codes are where as it could be).

No, that's not the problem.  I agree that the = DHCP Reply status code
"InvalidSource" solves the problem of = sending a DHCPNAK - the problem
is that the draft doesn't say when one would be = generated, or how, or
what the client should do when one is = received.

Here's the problem: the draft never says *what* IAs = you can configure
in a message.  So as an implementor, how do I = program my client to
handle the case where there is more than one = interface?  It looks from
the protocol specification like I can just send a = DHCP Solicit on any
one interface listing IAs for each interface to be = configured.  Or
maybe I should send the Solicit on *all* = interfaces?  Of course, we
are DHCP geeks, and we know that we should send one = Solicit out each
interface containing one IA that is specific to the = interface being
configured.   But the draft doesn't say = this.

Then, there's no guidance in the draft about how the = server chooses IP
addresses.  Presumably, if the client message = is received encapsulated
in a Relay-forward message, the server should assign = an IP address
that will work on the subnet on which the relay = agent reported that
the message was received, and if the message was not = received in a
Relay-forward message, the server assigns an IP = address on the network
segment to which the network interface on which the = packet was
received is connected.   But again, this = is never mentioned in the
draft.

Further, once you *have* an address configured, it = would be very
tempting to clump all the IAs into one unicast = message for renewals.
This would probably work fine in a Renew message, = but what about in a
Confirm message?   Obviously this won't = work, but the draft offers no
guidance.

I think that the language for the Confirm message = does a reasonable
job of solving this problem *if* we add language to = the other messages
offering guidance about what IAs can be = mentioned.  We could attach
language to the Solicit, Request and Confirm = messages saying that only
IAs for addresses for the interface on which the = message is being sent
may be included in these messages, and that if the = client is trying to
configure more than one interface, it should send = one of these
messages on each interface.   I *think* = that would solve the problem,
but the language that talks about how to handle = responses in that case
still doesn't seem right.   Shouldn't it = be possible for *any* server
listening on the link on which the client is trying = to Confirm to send
a message saying "you're on the wrong = link?"   The present language
implies that only the server that issued the = original IA will respond,
and doesn't mention any sort of response that says = "you're on the
wrong network."   Here's the language = for servers:

   When the server receives a Confirm and = an IA option is included the
   client is requesting confirmation that = the addresses in the IA are
   valid.  The server SHOULD locate = the clients binding and verify the
   information in the IA from the client = matches the information stored
   for that client.

   If the server cannot find a client entry = for this IA the server
   SHOULD return an empty IA with status = set to NoBinding.

   If the server finds that the information = for the client does not
   match what is in the server's records = for that client the server
   should send back an empty IA with = status set to Conf_NoMatch.

   If the server finds a match to the = Confirm then the server should
   send back the IA to the client with = status set to success.

There's nothing in here about validating the address = as to whether or
not it is correct for the link to which the client = is attached.
There is an InvalidSource error message, but its use = isn't documented.

        =         =                _MelloN_

------_=_NextPart_001_01C10DA8.87154730-- From owner-dhcp-v6@bucknell.edu Sun Jul 15 23:37:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15164; Sun, 15 Jul 2001 23:37:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6G3c9L00061; Sun, 15 Jul 2001 23:38:09 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6G3afL32741 for ; Sun, 15 Jul 2001 23:36:41 -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 f6G3aep17623 for ; Sun, 15 Jul 2001 22:36:40 -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 f6G3aeN25547 for ; Sun, 15 Jul 2001 22:36:40 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Sun Jul 15 22:36:39 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKB16S>; Sun, 15 Jul 2001 22:36:39 -0500 Message-ID: <66F66129A77AD411B76200508B65AC696D1B2E@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? Date: Sun, 15 Jul 2001 22:36:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10DA8.85B6C8A0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10DA8.85B6C8A0 Content-Type: text/plain; charset="iso-8859-1" >The problem is that the spec doesn't say >what the server should do when I send a Confirm while I'm on the wrong >network, or what the client should do when it gets a Reply saying >"you're on the wrong network." I think the server should send an indication that the prefixes are bad for the link. When the client receives that indication, it should go to Solicit state at that point to restart the DHCP process (and discard the old addresses). Note: If the client wants added security, it could require authentication. In that case, a *bad* server can't tell the client that the addresses are bad (unless it knows how to authenticate to the client). - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Friday, July 13, 2001 12:42 PM To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? > I think not having NAK is fine. It caused a lot of grief in V4 to get > the NAK part right.=20 That had more to do with figuring out what state the client is in than it did with anything else. We don't have the problem of figuring out the client state, so this is a non-issue. More to the point, DHCPNAK *does* something. We can't just leave it out. > In the absence of a NAK - the client can directly go to the INIT state > with its DUID on changing networks. It can get the same set of > addresses or a different set of addresses depending on the DHCP Server > it is now talking to. That's not what the specification says right now. According to the spec as it stands, we would have to wait for the timeout. When I change networks, I want a new address immediately, not after some long tiemout period has expired. But moving straight to sending a Solicit isn't right either. When the client detects a "link change", it may not actually have moved - it just suspects that it *may* have moved. So I want to keep my old IA if I can. So using Confirm is correct. The problem isn't that. The problem is that the spec doesn't say what the server should do when I send a Confirm while I'm on the wrong network, or what the client should do when it gets a Reply saying "you're on the wrong network." _MelloN_ ------_=_NextPart_001_01C10DA8.85B6C8A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

>The problem is that the spec doesn't say
>what the server should do when I send a Confirm = while I'm on the wrong
>network, or what the client should do when it = gets a Reply saying
>"you're on the wrong network."

I think the server should send an indication that the = prefixes are bad for the link.

When the client receives that indication, it should = go to Solicit state at that point to restart the DHCP process (and = discard the old addresses).

Note: If the client wants added security, it could = require authentication. In that case, a *bad* server can't tell the = client that the addresses are bad (unless it knows how to authenticate = to the client).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Friday, July 13, 2001 12:42 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6?



> I think not having NAK is fine. It caused a lot = of grief in V4 to get
> the NAK part right.=3D20

That had more to do with figuring out what state the = client is in than
it did with anything else.   We don't have = the problem of figuring out
the client state, so this is a non-issue.

More to the point, DHCPNAK *does* = something.   We can't just leave it
out.

> In the absence of a NAK - the client can = directly go to the INIT state
> with its DUID on changing networks.  It = can get the same set of
> addresses or a different set of addresses = depending on the DHCP Server
> it is now talking to.

That's not what the specification says right = now.  According to the
spec as it stands, we would have to wait for the = timeout.  When I
change networks, I want a new address immediately, = not after some long
tiemout period has expired.   But moving = straight to sending a Solicit
isn't right either.   When the client = detects a "link change", it may
not actually have moved - it just suspects that it = *may* have moved.
So I want to keep my old IA if I can.   So = using Confirm is correct.
The problem isn't that.   The problem is = that the spec doesn't say
what the server should do when I send a Confirm = while I'm on the wrong
network, or what the client should do when it gets a = Reply saying
"you're on the wrong network."

        =         =                _MelloN_

------_=_NextPart_001_01C10DA8.85B6C8A0-- From owner-dhcp-v6@bucknell.edu Sun Jul 15 23:37:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15211; Sun, 15 Jul 2001 23:37:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6G3cGL29619; Sun, 15 Jul 2001 23:38:16 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6G3auL26193 for ; Sun, 15 Jul 2001 23:36:56 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6G3ae515415 for ; Sun, 15 Jul 2001 22:36:40 -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 f6G3aee04562 for ; Sun, 15 Jul 2001 22:36:40 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Jul 15 22:36:39 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKB16R>; Sun, 15 Jul 2001 22:36:39 -0500 Message-ID: <66F66129A77AD411B76200508B65AC696D1B2D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? Date: Sun, 15 Jul 2001 22:36:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10DA8.84BA1920" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10DA8.84BA1920 Content-Type: text/plain; charset="iso-8859-1" Regarding the 2nd point (relays configured to forward) ... don't forget that this is normal for DHCPv6 anyway because it is multicasting - therefore, if you have two servers on the link, they'll both receive the messages. Again, that's exactly why I wanted the servers to be able to send an indication that the prefix is correct for the client but the server can NOT verify the accuracy of the addresses OTHER than for the prefix. This would allow the client to know if it is on the correct link quickly because *ANY* server can answer this request. Of course, if the server has the client's bindings, it should indicate the full status to the client. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Friday, July 13, 2001 2:05 PM To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? > The main reason is that DHCP won't be as critical in a V6 network > for address distribution as it is in a V4 network. DHCP will be more > useful in handing out options in a V6 network. So you are arguing that because DHCP isn't critical, it doesn't have to work? I think this is a bad basis upon which to implement a protocol specification - either we shouldn't do it at all, or we should take out the parts that aren't needed, or we should do it right. The feature set that is in the specification is the one we agreed to. I don't think the WG would agree that we should take out the address assignment part - I certainly don't. So we should specify it in a way that will work. > Secondly, what happens if the relay is configured to forward the DHCP > messages to more than one server? (a common config in V4 network ) In > this case - the faster server can NAK the client causing it to go to the > INIT state unnecessarily. This is true of V4 as well, and this doesn't happen if the DHCP servers are configured properly. If they are not configured properly, that is hardly the protocol's fault. _MelloN_ ------_=_NextPart_001_01C10DA8.84BA1920 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

Regarding the 2nd point (relays configured to = forward) ... don't forget that this is normal for DHCPv6 anyway because = it is multicasting - therefore, if you have two servers on the link, = they'll both receive the messages.

Again, that's exactly why I wanted the servers to be = able to send an indication that the prefix is correct for the client = but the server can NOT verify the accuracy of the addresses OTHER than = for the prefix. This would allow the client to know if it is on the = correct link quickly because *ANY* server can answer this request. Of = course, if the server has the client's bindings, it should indicate the = full status to the client.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Friday, July 13, 2001 2:05 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6?



> The main reason is that DHCP won't be as = critical in a V6 network
> for address distribution as it is in a V4 = network. DHCP will be more
> useful in handing out options in a V6 = network.

So you are arguing that because DHCP isn't critical, = it doesn't have
to work?   I think this is a bad basis = upon which to implement a
protocol specification - either we shouldn't do it = at all, or we
should take out the parts that aren't needed, or we = should do it
right.   The feature set that is in the = specification is the one we
agreed to.   I don't think the WG would = agree that we should take out
the address assignment part - I certainly = don't.   So we should
specify it in a way that will work.

> Secondly, what happens if the relay is = configured to forward the DHCP
> messages to more than one server? (a common = config in V4 network ) In
> this case - the faster server can NAK the = client causing it to go to the
> INIT state unnecessarily.

This is true of V4 as well, and this doesn't happen = if the DHCP
servers are configured properly.   If they = are not configured
properly, that is hardly the protocol's = fault.

        =         =                _MelloN_

------_=_NextPart_001_01C10DA8.84BA1920-- From owner-dhcp-v6@bucknell.edu Sun Jul 15 23:38:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA15478; Sun, 15 Jul 2001 23:38:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6G3dAL13397; Sun, 15 Jul 2001 23:39:10 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6G3d4L04306 for ; Sun, 15 Jul 2001 23:39:05 -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 f6G3d4p17877 for ; Sun, 15 Jul 2001 22:39:04 -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 f6G3d4N25809 for ; Sun, 15 Jul 2001 22:39:04 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Sun Jul 15 22:39:03 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKB17X>; Sun, 15 Jul 2001 22:39:03 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B326F@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? Date: Sun, 15 Jul 2001 22:39:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10DA8.DB48C250" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10DA8.DB48C250 Content-Type: text/plain; charset="iso-8859-1" Ted: I think we should state that *ONLY* IAs for that interface are ever included. I kind of assumed there was one "DHCP Client" process per interface and that each interface behaves independently. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Friday, July 13, 2001 7:58 PM To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? > Note that the above two status codes say nothing about the binding > because the server can't - it has no information on the bindings > (perhaps the Prefixes are not correct is not needed since an > existing error covers it). What you described seems like it would work, with one caveat. We need to explicitly say that in DHCP Solicit, Request and Confirm message, only IAs for the interface on which the packet is transmitted may be included. Otherwise, the server isn't in a position to make address allocation decisions based on network topology information. It might also be necessary to place this restriction on the DHCP Rebind message - I'm not sure. _MelloN_ ------_=_NextPart_001_01C10DA8.DB48C250 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

Ted:

I think we should state that *ONLY* IAs for that = interface are ever included. I kind of assumed there was one "DHCP = Client" process per interface and that each interface behaves = independently.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Friday, July 13, 2001 7:58 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6?



> Note that the above two status codes say nothing = about the binding
> because the server can't - it has no = information on the bindings
> (perhaps the Prefixes are not correct is not = needed since an
> existing error covers it).

What you described seems like it would work, with one = caveat.  We need
to explicitly say that in DHCP Solicit, Request and = Confirm message,
only IAs for the interface on which the packet is = transmitted may be
included.  Otherwise, the server isn't in a = position to make address
allocation decisions based on network topology = information.  It might
also be necessary to place this restriction on the = DHCP Rebind message
- I'm not sure.

        =         =                _MelloN_

------_=_NextPart_001_01C10DA8.DB48C250-- From owner-dhcp-v6@bucknell.edu Mon Jul 16 14:05:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07683; Mon, 16 Jul 2001 14:05:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6GI3XL27781; Mon, 16 Jul 2001 14:03:33 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6GI3LL03078 for ; Mon, 16 Jul 2001 14:03:21 -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 f6GI3Kp26532 for ; Mon, 16 Jul 2001 13:03:20 -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 f6GI3KC23510 for ; Mon, 16 Jul 2001 13:03:20 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Jul 16 13:03:19 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKCG9G>; Mon, 16 Jul 2001 13:03:19 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3283@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: DHCPv6 -19 Draft Comments Date: Mon, 16 Jul 2001 13:03:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10E21.985AC640" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10E21.985AC640 Content-Type: text/plain; charset="iso-8859-1" Ralph, et al: In some further internal discussions and reviews, here are some other issues to address in the revision to the DHCPv6 -19 draft: 1. In Section 14.3.1 (Creation and sending of Request messages), there is no mention of using any of the "information" supplied by a server in the Advertise message (in response to a Solicit). In DHCPv4, the client sent information received in the Offer. We probably should be explicit about this and perhaps even suggest that the information received by a client in an Advertise is basically for information purposes only to help it determine whether this server will offer it what it needs. Perhaps the addresses assigned in the Advertise should even just be prefixes (interface portion all 0's)? If instead we want the server to assign "real" addresses, should something be said about how long those should be valid and whether the server should attempt to assign those same addresses to the client in a subsequent Request/Reply exchange for the IA? Perhaps we could punt and say this is a server implementation issue (whether it assigns real addresses and whether those are held for some (short) time for the client)? NOTE: If real addresses are returned, perhaps a client might even initiate DAD during the Request/Reply in which case it can do these two items in parallel (though this would be somewhat tricky since it would not want to Decline the addresses before receiving the Reply). Also, while checking the draft regarding this issue, I noticed: - Section 13.4.2 (Creation and sending of Advertise messages) does not even say anything about the ORO option that a client might have specified. Shouldn't we indicate that the Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option? - Section 14.3.1 (Creation and sending of Request messages) the first sentence says "If a client has no valid IPv6 addresses of sufficient scope to communicate with a DHCP server, ..." Huh? Even if it *DOES* have an address of sufficient scope, we don't want the client sending messages directly to the server. This must be some old text that should be dropped. 2. In Section 14.3.1, we should perhaps explicitly indicate that the client should add an ORO option (it now says "The client adds any appropriate options" ... but in many cases that just means an ORO option with appropriate options specified in that option. 3. During the WG / Design Team (I forget which, if not both) we did discuss designing a "quick" handshake for allowing a client to assign an address. I would assume we'd define a new option that the client could use to communicate to the server that it is doing this. Would we use Solicit/Advertise or Request/Reply for this (in many ways, Request/Reply seems like a better mechanism - the Request could simply leave the "server address" field as all 0's and that could even be the flag to the server). Perhaps we decided to defer this for now and do it later? 4. At another time we also discussed using the server to just advertise prefixes and allowing the client to generate the addresses? What about adding a "P" bit (next to the "T"-temporary bit) to indicate that this is a prefix from which the client should generate an address (or simply allowing it to do so if the link-identifier field is all 0's). > Bernie Volz > Chief Technical Officer - DNS & DHCP Development Unit > Ericsson, Inc. > Tel: +1-508-875-3162 > Fax: +1-508-875-3018 > Mobile: +1-617-513-9060 > mailto:bernie.volz@ericsson.com > > ------_=_NextPart_001_01C10E21.985AC640 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable DHCPv6 -19 Draft Comments

Ralph, et al:

In some further internal discussions = and reviews, here are some other issues to address in the revision to = the DHCPv6 -19 draft:

1. In Section 14.3.1 (Creation and = sending of Request messages), there is no mention of using any of the = "information" supplied by a server in the Advertise message = (in response to a Solicit). In DHCPv4, the client sent information = received in the Offer. We probably should be explicit about this and = perhaps even suggest that the information received by a client in an = Advertise is basically for information purposes only to help it = determine whether this server will offer it what it needs. Perhaps the = addresses assigned in the Advertise should even just be prefixes = (interface portion all 0's)?

If instead we want the server to = assign "real" addresses, should something be said about how = long those should be valid and whether the server should attempt to = assign those same addresses to the client in a subsequent Request/Reply = exchange for the IA? Perhaps we could punt and say this is a server = implementation issue (whether it assigns real addresses and whether = those are held for some (short) time for the client)?

NOTE: If real addresses are returned, = perhaps a client might even initiate DAD during the Request/Reply in = which case it can do these two items in parallel (though this would be = somewhat tricky since it would not want to Decline the addresses before = receiving the Reply).

Also, while checking the draft = regarding this issue, I noticed:
- Section 13.4.2 (Creation and = sending of Advertise messages) does not even say anything about the ORO = option that a client might have specified. Shouldn't we indicate that = the Advertise message SHOULD include options for all OROs that were = included in the Solicit if the server is willing/capable of offering a = value for that option?

- Section 14.3.1 (Creation and sending = of Request messages) the first sentence says "If a client has no = valid IPv6 addresses of sufficient scope to communicate with a DHCP = server, ..." Huh? Even if it *DOES* have an address of sufficient = scope, we don't want the client sending messages directly to the = server. This must be some old text that should be dropped.

2. In Section 14.3.1, we should = perhaps explicitly indicate that the client should add an ORO option = (it now says "The client adds any appropriate options" ... = but in many cases that just means an ORO option with appropriate = options specified in that option.

3. During the WG / Design Team (I = forget which, if not both) we did discuss designing a "quick" = handshake for allowing a client to assign an address. I would assume = we'd define a new option that the client could use to communicate to = the server that it is doing this. Would we use Solicit/Advertise or = Request/Reply for this (in many ways, Request/Reply seems like a better = mechanism - the Request could simply leave the "server = address" field as all 0's and that could even be the flag to the = server). Perhaps we decided to defer this for now and do it = later?

4. At another time we also discussed = using the server to just advertise prefixes and allowing the client to = generate the addresses? What about adding a "P" bit (next to = the "T"-temporary bit) to indicate that this is a prefix from = which the client should generate an address (or simply allowing it to = do so if the link-identifier field is all 0's).

Bernie Volz
Chief Technical Officer - = DNS & DHCP Development Unit
Ericsson, Inc.
Tel: +1-508-875-3162
Fax: +1-508-875-3018
Mobile: = +1-617-513-9060
mailto:bernie.volz@ericsson.com=


------_=_NextPart_001_01C10E21.985AC640-- From owner-dhcp-v6@bucknell.edu Mon Jul 16 20:31:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17256; Mon, 16 Jul 2001 20:31:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H0VsL08481; Mon, 16 Jul 2001 20:31:54 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6H0VgL26829 for ; Mon, 16 Jul 2001 20:31:42 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn2-42.cisco.com [10.21.112.42]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA07059 for ; Mon, 16 Jul 2001 20:31:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20010716202951.032de298@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 16 Jul 2001 20:30:12 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Definition of DUID Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here's is text from Ted Lemon (thanks, Ted!) proposing a definition for the DUID. Please take a look at this text and post comments to the mailing list as soon as possible so I can finish the -20 rev of the draft by this Friday's deadline. - Ralph ===== 11. DHCP unique identifier (DUID) Each DHCP client has a DUID. DHCP servers use DUIDs to identify clients for the selection of configuration parameters and in the association of IAs with clients. See section 18.2 for the representation of a DUID in a DHCP message. The DUID is carried in an option because it may be variable length and because it is not required in all DHCP options (e.g., messages sent by servers need not include a DUID). The DUID must be unique across all DHCP clients, and it must also be consistent across uses of the same client - that is, a client's DUID SHOULD NOT change over time, or as a result of network hardware reconfiguration. The motivation for having more than one type of DUID is that the DUID must be globally unique, and must also be easy to generate. The sort of globally-unique identifier that is easy to generate for any given application can differ quite widely. Also, some devices may not contain any persistent storage. Retaining a generated DUID in such a device is not possible, so the DUID scheme must accomodate such devices. 11.1 DUID contents A DUID consists of a sixteen-bit type code represented in network byte order, followed by a variable number of bytes that make up the actual identifier. The following types are currently defined: 1 Link-layer address plus time 2 Vendor-assigned unique ID 3 Link-layer address 4 IMSI 5 IMEI Although cell phone IMSI (International Mobile Subscriber Identifier) and IMEI (International Mobile Equipment Identity) can be used as unique identifiers, the mobile phone telephone number MUST NOT be used, because the mobile phone telephone number is not guaranteed to remain stable across the lifetime of the phone - it is possible to have two phones which have been programmed with the same telephone number. Formats for the variable field of the DUID for each of the above types are shown below. New types may be defined in future standards, and must be allocated by the IANA. 11.1.1 DUID based on link-layer address plus time This type of DUID consists of four octets containing a time value, followed by a two octet network hardware type code, followed by link-layer address of any one network interface that is connected to the DHCP client device at the time that the DUID is generated. The time value is the time that the DUID is generated represented in seconds since January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by the IANA as described in the section on ARP in [23]. Both the time and the hardware type are stored in network byte order. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hardware type (16 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . link-layer address (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The choice of network interface can be completely arbitrary, as long as that interface provides a unique link-layer address, and the same DUID should be used in configuring all network interfaces connected to the device, regardless of which interface's link-layer address was used to generate the DUID. DHCP clients using this type of DUID MUST store the DUID in stable storage, and MUST continue to use this DUID even if the network interface used to generate the DUID is removed. DHCP clients that do not have any stable storage MUST NOT use this type of DUID. DHCP clients that use this DUID SHOULD attempt to configure the time prior to generating the DUID, if that is possible, and MUST use some sort of time source (e.g., a real-time clock) in generating the DUID, even if that time source is not configured by the user prior to generating the DUID. The use of a time source makes it unlikely that if the network interface is removed from the client and another client then uses the same network interface to generate a DUID, that two identical DUIDs will be generated. A DUID collision is very unlikely even if the clocks haven't been configured prior to generating the DUID. This method of DUID generation is recommended for all general purpose computing devices such as desktop computers and laptop computers, and also for devices such as printers, routers, and so on, that contain some form of writable non-volatile storage. 11.1.2 Vendor-assigned unique ID. The vendor-assigned unique ID consists of an eight-octet vendor-unique identifier, followed by the vendor's registered domain name. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | VUID (64 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . domain name (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The structure of the VUID is left up to the vendor defining it, but each device containing such a VUID MUST be unique to each device that is using it, and MUST be assigned to the device at the time of manufacture and stored in some form of non-volatile storage. The VUID SHOULD be recorded in non-erasable storage. The domain name is simply any domain name that has been legally registered by the vendor in the domain name system, stored in canonical form. An example DUID of this type might look like this: +--+---+---+---+-+-+--+---+---+--+---+---+---+---+--+--+---+---+ |12|192|132|221|3|9|18|101|120|97|109|112|108|101|46|99|111|109| +--+---+---+---+-+-+--+---+---+--+---+---+---+---+--+--+---+---+ This is eight octets of VUID data, followed by "example.com" represented in ASCII. 11.1.3 Link-layer address This type of DUID consists of a two octet network hardware type code, followed by the link-layer address of any one network interface that is permanently connected to the DHCP client device. The time value is the time that the DUID is generated represented in seconds since January 1, 2000, modulo 2^32. The hardware type MUST be a valid hardware type assigned by the IANA as described in the section on ARP in [23]. The hardware type is stored in network byte order. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hardware type (16 bits) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . . . link-layer address (variable length) . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The choice of network interface can be completely arbitrary, as long as that interface provides a unique link-layer address and is permanently attached to the device on which the DUID is being generated. The same DUID should be used in configuring all network interfaces connected to the device, regardless of which interface's link-layer address was used to generate the DUID. This type of DUID is recommended for devices that have a permanently-connected network interface with a link-layer address and do not have nonvolatile, writable stable storage. This type of DUID MUST NOT be used by DHCP clients that cannot tell whether or not a network interface is permanently attached to the device on which the DHCP client is running. 11.1.4 DUID based on IMEI and IMSI Because IMEI and IMSI are both globally-unique numbers, a DUID based on either one simply consists of the binary identifier, represented in its canonical form. [Hayulp! I have no idea what the format of these numbers is - can anybody (nokia guys?) help to adjust this language? Also, if we can cleanly capture all the extant identifiers being used by the cell phone industry here, that would be Really Nice [TM]. E.g., what identifier is used in AMPS and CDMA? Also, can anybody provide references to be cited?] From owner-dhcp-v6@bucknell.edu Mon Jul 16 21:56:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03347; Mon, 16 Jul 2001 21:56:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H1q7L28848; Mon, 16 Jul 2001 21:52:07 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H1q1L01831 for ; Mon, 16 Jul 2001 21:52:01 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA18055; Mon, 16 Jul 2001 21:52:00 -0400 Date: Mon, 16 Jul 2001 21:52:00 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? In-Reply-To: <66F66129A77AD411B76200508B65AC696D1B2F@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN stateless can generate addresses with the u bit set. we should say no more about how addresses are generated by a dhcpv6 server than a router does for stateless. also your iaid may not last for inifinity and it should not. /jim On Sun, 15 Jul 2001, Bernie Volz (EUD) wrote: > Ted: > > I agree that we likely need to tighten up the specification. I think the assumption is that an IA (IAID) is bound to a specific interface and that IA (IAID) should only be used on that interface as long as it is in use (has a prefix that hasn't become invalid). > > Now, this might have some impact if I change my NIC card because I may now loose all of my old addresses. But, I think that's a small price to pay (it also has some attractions since if I plug in different cards at home and at work, I can retain my home addresses while I'm at work since the IAIDs for the home interface continue to exist and will be valid again when I plug in at home). > > >Then, there's no guidance in the draft about how the server chooses IP > >addresses. > > I've always thought we needed text around this subject. I agree that we're kind of assuming a lot - the obvious is for the server to assign addresses with the correct prefixes. But, we should also have recommendations with regards to servers generating addresses. For example, simply incrementing addresses by 1 or some fixed number might be bad (predictive and leaks information). Also, perhaps there should be recommendations against using addresses that could be generated by stateless (with the 'u' bit set) since there could be issues if one switches between stateful/stateless? > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Friday, July 13, 2001 12:23 PM > To: DHCPv6 discussion list > Subject: Re: DHCPNAK for DHCPv6? > > > > > I believe this is covered in the status field in the IA > > option. Section 7.4 has various error codes that can be returned in > > IA status or addr status (the text isn't as clear as to which status > > codes are where as it could be). > > No, that's not the problem. I agree that the DHCP Reply status code > "InvalidSource" solves the problem of sending a DHCPNAK - the problem > is that the draft doesn't say when one would be generated, or how, or > what the client should do when one is received. > > Here's the problem: the draft never says *what* IAs you can configure > in a message. So as an implementor, how do I program my client to > handle the case where there is more than one interface? It looks from > the protocol specification like I can just send a DHCP Solicit on any > one interface listing IAs for each interface to be configured. Or > maybe I should send the Solicit on *all* interfaces? Of course, we > are DHCP geeks, and we know that we should send one Solicit out each > interface containing one IA that is specific to the interface being > configured. But the draft doesn't say this. > > Then, there's no guidance in the draft about how the server chooses IP > addresses. Presumably, if the client message is received encapsulated > in a Relay-forward message, the server should assign an IP address > that will work on the subnet on which the relay agent reported that > the message was received, and if the message was not received in a > Relay-forward message, the server assigns an IP address on the network > segment to which the network interface on which the packet was > received is connected. But again, this is never mentioned in the > draft. > > Further, once you *have* an address configured, it would be very > tempting to clump all the IAs into one unicast message for renewals. > This would probably work fine in a Renew message, but what about in a > Confirm message? Obviously this won't work, but the draft offers no > guidance. > > I think that the language for the Confirm message does a reasonable > job of solving this problem *if* we add language to the other messages > offering guidance about what IAs can be mentioned. We could attach > language to the Solicit, Request and Confirm messages saying that only > IAs for addresses for the interface on which the message is being sent > may be included in these messages, and that if the client is trying to > configure more than one interface, it should send one of these > messages on each interface. I *think* that would solve the problem, > but the language that talks about how to handle responses in that case > still doesn't seem right. Shouldn't it be possible for *any* server > listening on the link on which the client is trying to Confirm to send > a message saying "you're on the wrong link?" The present language > implies that only the server that issued the original IA will respond, > and doesn't mention any sort of response that says "you're on the > wrong network." Here's the language for servers: > > When the server receives a Confirm and an IA option is included the > client is requesting confirmation that the addresses in the IA are > valid. The server SHOULD locate the clients binding and verify the > information in the IA from the client matches the information stored > for that client. > > If the server cannot find a client entry for this IA the server > SHOULD return an empty IA with status set to NoBinding. > > If the server finds that the information for the client does not > match what is in the server's records for that client the server > should send back an empty IA with status set to Conf_NoMatch. > > If the server finds a match to the Confirm then the server should > send back the IA to the client with status set to success. > > There's nothing in here about validating the address as to whether or > not it is correct for the link to which the client is attached. > There is an InvalidSource error message, but its use isn't documented. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Mon Jul 16 22:10:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05024; Mon, 16 Jul 2001 22:10:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H2AsL01322; Mon, 16 Jul 2001 22:10:54 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H2AdL25740 for ; Mon, 16 Jul 2001 22:10:39 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AB18403; Mon, 16 Jul 2001 22:10:38 -0400 Date: Mon, 16 Jul 2001 22:10:38 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? In-Reply-To: <66F66129A77AD411B76200508B65AC697B326F@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN IAs are tied to Interfaces. This has been our assumption. /jim On Sun, 15 Jul 2001, Bernie Volz (EUD) wrote: > Ted: > > I think we should state that *ONLY* IAs for that interface are ever included. I kind of assumed there was one "DHCP Client" process per interface and that each interface behaves independently. > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Friday, July 13, 2001 7:58 PM > To: DHCPv6 discussion list > Subject: Re: DHCPNAK for DHCPv6? > > > > > Note that the above two status codes say nothing about the binding > > because the server can't - it has no information on the bindings > > (perhaps the Prefixes are not correct is not needed since an > > existing error covers it). > > What you described seems like it would work, with one caveat. We need > to explicitly say that in DHCP Solicit, Request and Confirm message, > only IAs for the interface on which the packet is transmitted may be > included. Otherwise, the server isn't in a position to make address > allocation decisions based on network topology information. It might > also be necessary to place this restriction on the DHCP Rebind message > - I'm not sure. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Mon Jul 16 22:10:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05053; Mon, 16 Jul 2001 22:10:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H2A2L10213; Mon, 16 Jul 2001 22:10:03 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H29xL06595 for ; Mon, 16 Jul 2001 22:09:59 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA18140; Mon, 16 Jul 2001 22:09:59 -0400 Date: Mon, 16 Jul 2001 22:09:58 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? In-Reply-To: <66F66129A77AD411B76200508B65AC696D1B2D@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN yes we lost this behavior which we had in older versions of the spec by catching the prefix per Mike Carney awhile ago. We can do this by looking at the relay address. Simple fix. thanks /jim On Sun, 15 Jul 2001, Bernie Volz (EUD) wrote: > Regarding the 2nd point (relays configured to forward) ... don't forget that this is normal for DHCPv6 anyway because it is multicasting - therefore, if you have two servers on the link, they'll both receive the messages. > > Again, that's exactly why I wanted the servers to be able to send an indication that the prefix is correct for the client but the server can NOT verify the accuracy of the addresses OTHER than for the prefix. This would allow the client to know if it is on the correct link quickly because *ANY* server can answer this request. Of course, if the server has the client's bindings, it should indicate the full status to the client. > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Friday, July 13, 2001 2:05 PM > To: DHCPv6 discussion list > Subject: Re: DHCPNAK for DHCPv6? > > > > > The main reason is that DHCP won't be as critical in a V6 network > > for address distribution as it is in a V4 network. DHCP will be more > > useful in handing out options in a V6 network. > > So you are arguing that because DHCP isn't critical, it doesn't have > to work? I think this is a bad basis upon which to implement a > protocol specification - either we shouldn't do it at all, or we > should take out the parts that aren't needed, or we should do it > right. The feature set that is in the specification is the one we > agreed to. I don't think the WG would agree that we should take out > the address assignment part - I certainly don't. So we should > specify it in a way that will work. > > > Secondly, what happens if the relay is configured to forward the DHCP > > messages to more than one server? (a common config in V4 network ) In > > this case - the faster server can NAK the client causing it to go to the > > INIT state unnecessarily. > > This is true of V4 as well, and this doesn't happen if the DHCP > servers are configured properly. If they are not configured > properly, that is hardly the protocol's fault. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Mon Jul 16 22:11:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA05072; Mon, 16 Jul 2001 22:10:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H28ZL13037; Mon, 16 Jul 2001 22:08:35 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H28SL06398 for ; Mon, 16 Jul 2001 22:08:28 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA18840; Mon, 16 Jul 2001 22:08:27 -0400 Date: Mon, 16 Jul 2001 22:08:27 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? In-Reply-To: <66F66129A77AD411B76200508B65AC696D1B2E@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN we should send back prefix not match if the relay prefix does not match *any* addresses for the IA for the client. Should be new error code. In the current spec I catch this and use nobinding. better to have prefix no match or some such code we will come up with. /jim On Sun, 15 Jul 2001, Bernie Volz (EUD) wrote: > >The problem is that the spec doesn't say > >what the server should do when I send a Confirm while I'm on the wrong > >network, or what the client should do when it gets a Reply saying > >"you're on the wrong network." > > I think the server should send an indication that the prefixes are bad for the link. > > When the client receives that indication, it should go to Solicit state at that point to restart the DHCP process (and discard the old addresses). > > Note: If the client wants added security, it could require authentication. In that case, a *bad* server can't tell the client that the addresses are bad (unless it knows how to authenticate to the client). > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Friday, July 13, 2001 12:42 PM > To: DHCPv6 discussion list > Subject: Re: DHCPNAK for DHCPv6? > > > > > I think not having NAK is fine. It caused a lot of grief in V4 to get > > the NAK part right.=20 > > That had more to do with figuring out what state the client is in than > it did with anything else. We don't have the problem of figuring out > the client state, so this is a non-issue. > > More to the point, DHCPNAK *does* something. We can't just leave it > out. > > > In the absence of a NAK - the client can directly go to the INIT state > > with its DUID on changing networks. It can get the same set of > > addresses or a different set of addresses depending on the DHCP Server > > it is now talking to. > > That's not what the specification says right now. According to the > spec as it stands, we would have to wait for the timeout. When I > change networks, I want a new address immediately, not after some long > tiemout period has expired. But moving straight to sending a Solicit > isn't right either. When the client detects a "link change", it may > not actually have moved - it just suspects that it *may* have moved. > So I want to keep my old IA if I can. So using Confirm is correct. > The problem isn't that. The problem is that the spec doesn't say > what the server should do when I send a Confirm while I'm on the wrong > network, or what the client should do when it gets a Reply saying > "you're on the wrong network." > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Mon Jul 16 22:52:18 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10802; Mon, 16 Jul 2001 22:52:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H2n0L23432; Mon, 16 Jul 2001 22:49:00 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H2mpL28650 for ; Mon, 16 Jul 2001 22:48:51 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA19976; Mon, 16 Jul 2001 22:48:51 -0400 Date: Mon, 16 Jul 2001 22:48:51 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPv6 -19 Draft Comments In-Reply-To: <66F66129A77AD411B76200508B65AC697B3283@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN On Mon, 16 Jul 2001, Bernie Volz (EUD) wrote: wordwrap of 72 chars and using plain text with ms would be nice... > Ralph, et al: > > In some further internal discussions and reviews, here are some other > issues to address in the revision to the DHCPv6 -19 draft: > > 1. In Section 14.3.1 (Creation and sending of Request messages), there > is no mention of using any of the "information" supplied by a server in > the Advertise message (in response to a Solicit). In DHCPv4, the client > sent information received in the Offer. We probably should be explicit > about this and perhaps even suggest that the information received by a > client in an Advertise is basically for information purposes only to > help it determine whether this server will offer it what it needs. > Perhaps the addresses assigned in the Advertise should even just be > prefixes (interface portion all 0's)? This is implementable for now. Client can get options. Options are defined. But we easy fix. We want to permit future extensions so we need to be careful here and not over specify. > > If instead we want the server to assign "real" addresses, should > something be said about how long those should be valid and whether the > server should attempt to assign those same addresses to the client in a > subsequent Request/Reply exchange for the IA? Perhaps we could punt and > say this is a server implementation issue (whether it assigns real > addresses and whether those are held for some (short) time for the > client)? This is the default if we don't say. Its up to the server. > > NOTE: If real addresses are returned, perhaps a client might even > initiate DAD during the Request/Reply in which case it can do these two > items in parallel (though this would be somewhat tricky since it would > not want to Decline the addresses before receiving the Reply). If the clients chooses to do DAD it should be done before Request. > > Also, while checking the draft regarding this issue, I noticed: - > Section 13.4.2 (Creation and sending of Advertise messages) does not > even say anything about the ORO option that a client might have > specified. Shouldn't we indicate that the Advertise message SHOULD > include options for all OROs that were included in the Solicit if the > server is willing/capable of offering a value for that option? Yes it should this can be added in easily. > > - Section 14.3.1 (Creation and sending of Request messages) the first > sentence says "If a client has no valid IPv6 addresses of sufficient > scope to communicate with a DHCP server, ..." Huh? Even if it *DOES* > have an address of sufficient scope, we don't want the client sending > messages directly to the server. This must be some old text that should > be dropped. We now permit the unicast option so we still need this health warning. but in context of the new option. > > 2. In Section 14.3.1, we should perhaps explicitly indicate that the > client should add an ORO option (it now says "The client adds any > appropriate options" ... but in many cases that just means an ORO option > with appropriate options specified in that option. The word "appropriate" is correct. It can be an ORO or IA. > > 3. During the WG / Design Team (I forget which, if not both) we did > discuss designing a "quick" handshake for allowing a client to assign an > address. I would assume we'd define a new option that the client could > use to communicate to the server that it is doing this. Would we use > Solicit/Advertise or Request/Reply for this (in many ways, Request/Reply > seems like a better mechanism - the Request could simply leave the > "server address" field as all 0's and that could even be the flag to the > server). Perhaps we decided to defer this for now and do it later? My recollection is that we the end result was the design team and then at the IETF the WG does not want to permit this behavior???? > 4. At another time we also discussed using the server to just advertise > prefixes and allowing the client to generate the addresses? What about > adding a "P" bit (next to the "T"-temporary bit) to indicate that this > is a prefix from which the client should generate an address (or simply > allowing it to do so if the link-identifier field is all 0's). We decided in San Diego and Minneapolis to not do this behavior at this time in the WG. So we verified it twice. We may want to reserve a prefix bit though if all feel it worthwhile. /jim From owner-dhcp-v6@bucknell.edu Mon Jul 16 22:57:48 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11434; Mon, 16 Jul 2001 22:57:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H2ulL00215; Mon, 16 Jul 2001 22:56:47 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H2udL00820 for ; Mon, 16 Jul 2001 22:56:39 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA19456; Mon, 16 Jul 2001 22:56:39 -0400 Date: Mon, 16 Jul 2001 22:56:39 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: <200107130503.f6D533b01842@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > One thing I just noticed about the latest draft is that there is no > equivalent of a DHCPNAK sent in response to a request to renew an > address when the client has moved to a different network link. This > behaviour is extremely important - without it, whenever the client > changes networks it has to wait for its lease to expire before it can > get a new IP address. It is my recollection we do not have consensus on this issue. When a client leaves the network it should release its addresses. As backup we should add prefix check from relay for the client bindings on confirm. Then a prefix no match can be sent back to the client. > Am I correct in thinking that this is missing, or is it I who am > missing something? Its not that it is missing it was not applied. The consensus is to get a minimum spec out. We imply to use the release at the client for this now. I agree thats not quite enough for the node that just gets shutdown and placed elsewhere on a wired net (I shut my laptop off and plug it on another network). Our current release will work for any mobile nodes with code to detect movement but we need to address the non mobile client moving too. Good catch. I think the prefix discussion will work and appease others on the mail list who don't want a specific dhcpv6nak. Others ????????????? thanks /jim From owner-dhcp-v6@bucknell.edu Tue Jul 17 02:10:57 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28608; Tue, 17 Jul 2001 02:10:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H6BAL14521; Tue, 17 Jul 2001 02:11:10 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6H6AtL10744 for ; Tue, 17 Jul 2001 02:10:55 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6H66kf11032 for ; Mon, 16 Jul 2001 23:06:46 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6H67v200421 for ; Mon, 16 Jul 2001 23:07:57 -0700 (MST) Message-Id: <200107170607.f6H67v200421@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: Message from Jim Bound of "Mon, 16 Jul 2001 22:10:38 -0400." Date: Mon, 16 Jul 2001 23:07:57 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > IAs are tied to Interfaces. This has been our assumption. So is it okay to update the spec to say so explicitly? _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 17 02:16:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29694; Tue, 17 Jul 2001 02:16:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6H6GYL32352; Tue, 17 Jul 2001 02:16:34 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6H6GJL06788 for ; Tue, 17 Jul 2001 02:16:20 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6H6CBf11044 for ; Mon, 16 Jul 2001 23:12:11 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6H6DL200444 for ; Mon, 16 Jul 2001 23:13:21 -0700 (MST) Message-Id: <200107170613.f6H6DL200444@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: Message from Jim Bound of "Mon, 16 Jul 2001 22:56:39 -0400." Date: Mon, 16 Jul 2001 23:13:21 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The consensus is to get a minimum spec out. The consensus in which I participated was to get a minimum workable spec out. That is all I am trying to make sure of. It has to work. We can't afford do do release a spec that doesn't work, because if this spec is worth anything at all, people are going to implement it, and then we won't be able to fix our mistakes. I am not arguing for excessive caution, but if we identify a real problem, we should definitely fix it, right? :'} _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 17 09:29:24 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04303; Tue, 17 Jul 2001 09:29:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HDS8L12417; Tue, 17 Jul 2001 09:28:08 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HDRwL09639 for ; Tue, 17 Jul 2001 09:27:58 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6HDRg513616 for ; Tue, 17 Jul 2001 08:27:42 -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 f6HDRgv15722 for ; Tue, 17 Jul 2001 08:27:42 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jul 17 08:27:41 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP27B3R>; Tue, 17 Jul 2001 08:27:41 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3291@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? Date: Tue, 17 Jul 2001 08:27:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10EC4.418BE2B0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10EC4.418BE2B0 Content-Type: text/plain; charset="iso-8859-1" Jim: I agree that the prefix handling should avoid the need for the NACK. There is still an issue of non-address configurations and perhaps a general "DHCP Error" option (in a Reply) that can be used to communicate problems might be useful. But, it is also something that perhaps can be added later (though existing clients would of course ignore that option). - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Monday, July 16, 2001 10:57 PM To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? > One thing I just noticed about the latest draft is that there is no > equivalent of a DHCPNAK sent in response to a request to renew an > address when the client has moved to a different network link. This > behaviour is extremely important - without it, whenever the client > changes networks it has to wait for its lease to expire before it can > get a new IP address. It is my recollection we do not have consensus on this issue. When a client leaves the network it should release its addresses. As backup we should add prefix check from relay for the client bindings on confirm. Then a prefix no match can be sent back to the client. > Am I correct in thinking that this is missing, or is it I who am > missing something? Its not that it is missing it was not applied. The consensus is to get a minimum spec out. We imply to use the release at the client for this now. I agree thats not quite enough for the node that just gets shutdown and placed elsewhere on a wired net (I shut my laptop off and plug it on another network). Our current release will work for any mobile nodes with code to detect movement but we need to address the non mobile client moving too. Good catch. I think the prefix discussion will work and appease others on the mail list who don't want a specific dhcpv6nak. Others ????????????? thanks /jim ------_=_NextPart_001_01C10EC4.418BE2B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

Jim:

I agree that the prefix handling should avoid the = need for the NACK. There is still an issue of non-address = configurations and perhaps a general "DHCP Error" option (in = a Reply) that can be used to communicate problems might be useful. But, = it is also something that perhaps can be added later (though existing = clients would of course ignore that option).

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]=
Sent: Monday, July 16, 2001 10:57 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6?



> One thing I just noticed about the latest draft = is that there is no
> equivalent of a DHCPNAK sent in response to a = request to renew an
> address when the client has moved to a = different network link.  This
> behaviour is extremely important - without it, = whenever the client
> changes networks it has to wait for its lease = to expire before it can
> get a new IP address.

It is my recollection we do not have consensus on = this issue.  When a
client leaves the network it should release its = addresses. As backup we
should add prefix check from relay for the client = bindings on confirm.
Then a prefix no match can be sent back to the = client.

> Am I correct in thinking that this is missing, = or is it I who am
> missing something?

Its not that it is missing it was not applied.  = The consensus is to get a
minimum spec out.  We imply to use the release = at the client for this now.
I agree thats not quite enough for the node that = just gets shutdown and
placed elsewhere on a wired net (I shut my laptop = off and plug it on
another network).  Our current release will = work for any mobile nodes with
code to detect movement but we need to address the = non mobile client
moving too.  Good catch.

I think the prefix discussion will work and appease = others on the mail
list who don't want a specific dhcpv6nak.

Others ?????????????

thanks
/jim

------_=_NextPart_001_01C10EC4.418BE2B0-- From owner-dhcp-v6@bucknell.edu Tue Jul 17 09:30:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04495; Tue, 17 Jul 2001 09:30:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HDV2L06109; Tue, 17 Jul 2001 09:31:02 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HDUuL30121 for ; Tue, 17 Jul 2001 09:30:56 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6HDUf515012 for ; Tue, 17 Jul 2001 08:30: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 f6HDUf802568 for ; Tue, 17 Jul 2001 08:30:41 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Tue Jul 17 08:30:22 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP27BS9>; Tue, 17 Jul 2001 08:30:22 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3292@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? Date: Tue, 17 Jul 2001 08:30:22 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10EC4.A189B520" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10EC4.A189B520 Content-Type: text/plain; charset="iso-8859-1" I agree. That *MUST* be the goal - we need a minimum workable spec. If we rush this and get a spec that doesn't work or causes many interoper problems we're doing ourselves and the IPv6 community a disservice and stateful configuration won't get used. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Tuesday, July 17, 2001 2:13 AM To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? > The consensus is to get a minimum spec out. The consensus in which I participated was to get a minimum workable spec out. That is all I am trying to make sure of. It has to work. We can't afford do do release a spec that doesn't work, because if this spec is worth anything at all, people are going to implement it, and then we won't be able to fix our mistakes. I am not arguing for excessive caution, but if we identify a real problem, we should definitely fix it, right? :'} _MelloN_ ------_=_NextPart_001_01C10EC4.A189B520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

I agree. That *MUST* be the goal - we need a minimum = workable spec. If we rush this and get a spec that doesn't work or = causes many interoper problems we're doing ourselves and the IPv6 = community a disservice and stateful configuration won't get = used.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Tuesday, July 17, 2001 2:13 AM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6?



> The consensus is to get a minimum spec = out.

The consensus in which I participated was to get a = minimum
workable spec out.   That is all I am = trying to make sure of.   It has
to work.   We can't afford do do release a = spec that doesn't work,
because if this spec is worth anything at all, = people are going to
implement it, and then we won't be able to fix our = mistakes.   I am
not arguing for excessive caution, but if we = identify a real problem,
we should definitely fix it, right?   = :'}

        =         =                _MelloN_

------_=_NextPart_001_01C10EC4.A189B520-- From owner-dhcp-v6@bucknell.edu Tue Jul 17 09:53:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07837; Tue, 17 Jul 2001 09:53:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HDrFL28144; Tue, 17 Jul 2001 09:53:15 -0400 (EDT) Received: from ausmtp01.au.ibm.com (ausmtp01.au.ibm.COM [202.135.136.97]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HDqxL11335 for ; Tue, 17 Jul 2001 09:53:00 -0400 (EDT) Received: from f02n16e.au.ibm.com by ausmtp01.au.ibm.com (IBM AP 1.0) with ESMTP id XAA80400 for ; Tue, 17 Jul 2001 23:49:15 +1000 From: skodati@in.ibm.com Received: from d73mta01.au.ibm.com (f06n01s [9.185.166.65]) by f02n16e.au.ibm.com (8.11.1m3/NCO v4.96) with SMTP id f6HDqF2111632 for ; Tue, 17 Jul 2001 23:52:15 +1000 Received: by d73mta01.au.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id CA256A8C.004C2EDE ; Tue, 17 Jul 2001 23:52:07 +1000 X-Lotus-FromDomain: IBMIN@IBMAU To: DHCPv6 discussion list Message-ID: Date: Tue, 17 Jul 2001 19:10:21 +0530 Subject: Server's reply for Decline message Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I need a clarification regarding the server's response to client's decline message. As per the spec, the client waits for the reply from the server. But The server behavior in response to the client "Decline" messages was not clearly mentioned in the draft. What are different "status"es the client can fill in the IA status field. -Suresh Kodati PS: I think 14.3.11 holds for Decline not Release From owner-dhcp-v6@bucknell.edu Tue Jul 17 09:59:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09511; Tue, 17 Jul 2001 09:59:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HDxDL01167; Tue, 17 Jul 2001 09:59:13 -0400 (EDT) Received: from quadntweb.quadritek.com ([198.200.138.211]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HDx8L17514 for ; Tue, 17 Jul 2001 09:59:08 -0400 (EDT) Received: from agrabilnt ([10.100.30.254]) by quadntweb.quadritek.com (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35) with SMTP id com for ; Tue, 17 Jul 2001 09:52:56 -0400 From: "A. Gregory Rabil" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Tue, 17 Jul 2001 09:58:36 -0400 Message-ID: <09a901c10ec8$93edae40$fe1e640a@quadritek.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <4.3.2.7.2.20010716202951.032de298@funnel.cisco.com> Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Ralph, Ted, This looks great! I have just one editorial comment... Section 11.1.3 - paragraph 1 has a cut-and-paste about the time calculation, but there is no time in the link-layer addresss DUID. Greg > -----Original Message----- > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > Behalf Of Ralph Droms > Sent: Monday, July 16, 2001 8:30 PM > To: DHCPv6 discussion list > Subject: Definition of DUID > > > Here's is text from Ted Lemon (thanks, Ted!) proposing a > definition for the > DUID. Please take a look at this text and post comments to > the mailing > list as soon as possible so I can finish the -20 rev of the > draft by this > Friday's deadline. > > - Ralph > > ===== > > 11. DHCP unique identifier (DUID) > > Each DHCP client has a DUID. DHCP servers use DUIDs to identify > clients for the selection of configuration parameters and in > the association of IAs with clients. See section 18.2 for the > representation of a DUID in a DHCP message. > > The DUID is carried in an option because it may be variable length > and because it is not required in all DHCP options (e.g., messages > sent by servers need not include a DUID). The DUID must be unique > across all DHCP clients, and it must also be consistent > across uses > of the same client - that is, a client's DUID SHOULD NOT change > over time, or as a result of network hardware reconfiguration. > > The motivation for having more than one type of DUID is that the > DUID must be globally unique, and must also be easy to generate. > The sort of globally-unique identifier that is easy to > generate for > any given application can differ quite widely. Also, > some devices > may not contain any persistent storage. Retaining a generated > DUID in such a device is not possible, so the DUID scheme must > accomodate such devices. > > 11.1 DUID contents > > A DUID consists of a sixteen-bit type code represented in network > byte order, followed by a variable number of bytes that > make up the > actual identifier. The following types are currently defined: > > 1 Link-layer address plus time > 2 Vendor-assigned unique ID > 3 Link-layer address > 4 IMSI > 5 IMEI > > Although cell phone IMSI (International Mobile Subscriber > Identifier) and IMEI (International Mobile Equipment Identity) can > be used as unique identifiers, the mobile phone telephone number > MUST NOT be used, because the mobile phone telephone number is not > guaranteed to remain stable across the lifetime of the phone - it > is possible to have two phones which have been programmed with the > same telephone number. > > Formats for the variable field of the DUID for each of the above > types are shown below. New types may be defined in future > standards, and must be allocated by the IANA. > > 11.1.1 DUID based on link-layer address plus time > > This type of DUID consists of four octets containing a time value, > followed by a two octet network hardware type code, followed by > link-layer address of any one network interface that is connected > to the DHCP client device at the time that the DUID is generated. > The time value is the time that the DUID is generated represented > in seconds since January 1, 2000, modulo 2^32. The hardware type > MUST be a valid hardware type assigned by the IANA as described in > the section on ARP in [23]. Both the time and the hardware type > are stored in network byte order. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Time (32 bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hardware type (16 bits) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > . . > . link-layer address (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The choice of network interface can be completely arbitrary, as > long as that interface provides a unique link-layer address, and > the same DUID should be used in configuring all network interfaces > connected to the device, regardless of which interface's > link-layer > address was used to generate the DUID. > > DHCP clients using this type of DUID MUST store the DUID in stable > storage, and MUST continue to use this DUID even if the network > interface used to generate the DUID is removed. DHCP > clients that > do not have any stable storage MUST NOT use this type of DUID. > > DHCP clients that use this DUID SHOULD attempt to configure the > time prior to generating the DUID, if that is possible, and MUST > use some sort of time source (e.g., a real-time clock) in > generating the DUID, even if that time source is not configured by > the user prior to generating the DUID. The use of a time source > makes it unlikely that if the network interface is > removed from the > client and another client then uses the same network interface to > generate a DUID, that two identical DUIDs will be generated. A > DUID collision is very unlikely even if the clocks haven't been > configured prior to generating the DUID. > > This method of DUID generation is recommended for all general > purpose computing devices such as desktop computers and laptop > computers, and also for devices such as printers, routers, and so > on, that contain some form of writable non-volatile storage. > > 11.1.2 Vendor-assigned unique ID. > > The vendor-assigned unique ID consists of an eight-octet > vendor-unique identifier, followed by the vendor's registered > domain name. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VUID (64 bits) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . domain name (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The structure of the VUID is left up to the vendor defining it, > but each device containing such a VUID MUST be unique to each > device that is using it, and MUST be assigned to the > device at the > time of manufacture and stored in some form of non-volatile > storage. The VUID SHOULD be recorded in non-erasable storage. > The domain name is simply any domain name that has been legally > registered by the vendor in the domain name system, stored in > canonical form. An example DUID of this type might look like > this: > > +--+---+---+---+-+-+--+---+---+--+---+---+---+---+--+--+---+---+ > |12|192|132|221|3|9|18|101|120|97|109|112|108|101|46|99|111|109| > +--+---+---+---+-+-+--+---+---+--+---+---+---+---+--+--+---+---+ > > This is eight octets of VUID data, followed by "example.com" > represented in ASCII. > > 11.1.3 Link-layer address > > This type of DUID consists of a two octet network hardware type > code, followed by the link-layer address of any one network > interface that is permanently connected to the DHCP client device. > The time value is the time that the DUID is generated represented > in seconds since January 1, 2000, modulo 2^32. The hardware type > MUST be a valid hardware type assigned by the IANA as described in > the section on ARP in [23]. The hardware type is stored > in network > byte order. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hardware type (16 bits) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > . . > . link-layer address (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The choice of network interface can be completely arbitrary, as > long as that interface provides a unique link-layer address and is > permanently attached to the device on which the DUID is being > generated. The same DUID should be used in configuring > all network > interfaces connected to the device, regardless of which > interface's > link-layer address was used to generate the DUID. > > This type of DUID is recommended for devices that have a > permanently-connected network interface with a link-layer address > and do not have nonvolatile, writable stable storage. This type > of DUID MUST NOT be used by DHCP clients that cannot tell whether > or not a network interface is permanently attached to the > device on > which the DHCP client is running. > > 11.1.4 DUID based on IMEI and IMSI > > Because IMEI and IMSI are both globally-unique numbers, a DUID > based on either one simply consists of the binary identifier, > represented in its canonical form. > > [Hayulp! I have no idea what the format of these numbers is - can > anybody (nokia guys?) help to adjust this language? Also, if we can > cleanly capture all the extant identifiers being used by the cell > phone industry here, that would be Really Nice [TM]. E.g., what > identifier is used in AMPS and CDMA? Also, can anybody provide > references to be cited?] > > From owner-dhcp-v6@bucknell.edu Tue Jul 17 10:10:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12213; Tue, 17 Jul 2001 10:10:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HEAYL10766; Tue, 17 Jul 2001 10:10:34 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HEALL10692 for ; Tue, 17 Jul 2001 10:10:21 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA30338; Tue, 17 Jul 2001 10:10:21 -0400 Date: Tue, 17 Jul 2001 10:10:21 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: <200107170607.f6H67v200421@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN i think we should yes.....as my input.. /jim On Mon, 16 Jul 2001, Ted Lemon wrote: > > > IAs are tied to Interfaces. This has been our assumption. > > So is it okay to update the spec to say so explicitly? > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Tue Jul 17 10:11:19 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12493; Tue, 17 Jul 2001 10:11:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HEBjL17580; Tue, 17 Jul 2001 10:11:45 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HEBbL03735 for ; Tue, 17 Jul 2001 10:11:37 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA30138; Tue, 17 Jul 2001 10:11:36 -0400 Date: Tue, 17 Jul 2001 10:11:36 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: <200107170613.f6H6DL200444@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN ack yes yes ...sorry if I came off any other way... just want to be sure ralph and I are heading towards last call too... /jim On Mon, 16 Jul 2001, Ted Lemon wrote: > > > The consensus is to get a minimum spec out. > > The consensus in which I participated was to get a minimum > workable spec out. That is all I am trying to make sure of. It has > to work. We can't afford do do release a spec that doesn't work, > because if this spec is worth anything at all, people are going to > implement it, and then we won't be able to fix our mistakes. I am > not arguing for excessive caution, but if we identify a real problem, > we should definitely fix it, right? :'} > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Tue Jul 17 10:16:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA13567; Tue, 17 Jul 2001 10:16:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HEG9L00756; Tue, 17 Jul 2001 10:16:09 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HEG7L09221 for ; Tue, 17 Jul 2001 10:16:07 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA32099; Tue, 17 Jul 2001 10:16:06 -0400 Date: Tue, 17 Jul 2001 10:16:06 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? In-Reply-To: <66F66129A77AD411B76200508B65AC697B3291@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN ack... /jim On Tue, 17 Jul 2001, Bernie Volz (EUD) wrote: > Jim: > > I agree that the prefix handling should avoid the need for the NACK. There is still an issue of non-address configurations and perhaps a general "DHCP Error" option (in a Reply) that can be used to communicate problems might be useful. But, it is also something that perhaps can be added later (though existing clients would of course ignore that option). > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Monday, July 16, 2001 10:57 PM > To: DHCPv6 discussion list > Subject: Re: DHCPNAK for DHCPv6? > > > > > One thing I just noticed about the latest draft is that there is no > > equivalent of a DHCPNAK sent in response to a request to renew an > > address when the client has moved to a different network link. This > > behaviour is extremely important - without it, whenever the client > > changes networks it has to wait for its lease to expire before it can > > get a new IP address. > > It is my recollection we do not have consensus on this issue. When a > client leaves the network it should release its addresses. As backup we > should add prefix check from relay for the client bindings on confirm. > Then a prefix no match can be sent back to the client. > > > Am I correct in thinking that this is missing, or is it I who am > > missing something? > > Its not that it is missing it was not applied. The consensus is to get a > minimum spec out. We imply to use the release at the client for this now. > I agree thats not quite enough for the node that just gets shutdown and > placed elsewhere on a wired net (I shut my laptop off and plug it on > another network). Our current release will work for any mobile nodes with > code to detect movement but we need to address the non mobile client > moving too. Good catch. > > I think the prefix discussion will work and appease others on the mail > list who don't want a specific dhcpv6nak. > > Others ????????????? > > thanks > /jim > From owner-dhcp-v6@bucknell.edu Tue Jul 17 11:29:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00123; Tue, 17 Jul 2001 11:29:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HFT2L20765; Tue, 17 Jul 2001 11:29:02 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HFSmL14003 for ; Tue, 17 Jul 2001 11:28:48 -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 f6HFSlp10294 for ; Tue, 17 Jul 2001 10:28:47 -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 f6HFSk817008 for ; Tue, 17 Jul 2001 10:28:46 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue Jul 17 10:28:46 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKD9GX>; Tue, 17 Jul 2001 10:28:45 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B329E@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: Server Unicast issue for DHCPv6 -19 Draft Date: Tue, 17 Jul 2001 10:28:46 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10ED5.2B845400" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10ED5.2B845400 Content-Type: text/plain; charset="iso-8859-1" Hi: One more issue for the -19 draft ... for the "Server Unicast Option" (Section 18.10), how is the server's Reply sent back to the client? The text in 14.4.6 won't work if the client is not on the local link: 14.4.6. Sending of Reply messages If the Request, Confirm, Renew, Rebind or Release message from the client was originally received by the server, the server unicasts the Reply message to the link-local address in the "client-link-local-address" field. If the message was originally received in a Forward-request or Forward-release message from a relay, the server places the Reply message in the options field of a Response-reply message and unicasts the message to the relay's address from the original message. I guess the text could be re-written to say: If the Request, Confirm, Renew, Rebind, Decline or Release message from the client was originally received by the server and the IPv6 source address was a link local address, the server unicasts the Reply message to the link-local address in the "client-link-local-address" field otherwise it unicasts it to the IPv6 source address. But, that's kind of nasty and complicated (why not simply always send back the Reply message to the source of the client's message except when relayed). Perhaps a better solution is for the client to include a "Reply-Address" option in the Request, Confirm, Renew, Rebind, Decline or Release message? If the server is configured to allow this, it would honor it (except when message was received via a Relay-Forward). - Bernie Volz ------_=_NextPart_001_01C10ED5.2B845400 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Server Unicast issue for DHCPv6 -19 Draft

Hi:

One more issue for the -19 draft ... = for the "Server Unicast Option" (Section 18.10),
how is the server's Reply sent back = to the client?

The text in 14.4.6 won't work if the = client is not on the local link:

14.4.6. Sending of Reply = messages

   If the Request, Confirm, = Renew, Rebind or Release message from
   the client was = originally received by the server, the server
   unicasts the Reply = message to the link-local address in the
   = "client-link-local-address" field.

   If the message was = originally received in a Forward-request or
   Forward-release message = from a relay, the server places the Reply
   message in the options = field of a Response-reply message and unicasts
   the message to the = relay's address from the original message.

I guess the text could be re-written = to say:

   If the Request, Confirm, = Renew, Rebind, Decline or Release message from
   the client was = originally received by the server and the IPv6 source address
   was a link local = address, the server unicasts the Reply message to the
   link-local address in = the "client-link-local-address" field otherwise it = unicasts
   it to the IPv6 source = address.

But, that's kind of nasty and = complicated (why not simply always send back the
Reply message to the source of the = client's message except when relayed).

Perhaps a better solution is for the = client to include a "Reply-Address" option in
the Request, Confirm, Renew, Rebind, = Decline or Release message? If the server
is configured to allow this, it would = honor it (except when message was received
via a Relay-Forward).

- Bernie Volz

------_=_NextPart_001_01C10ED5.2B845400-- From owner-dhcp-v6@bucknell.edu Tue Jul 17 12:59:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19867; Tue, 17 Jul 2001 12:59:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HGxQL06972; Tue, 17 Jul 2001 12:59:26 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HGxDL02023 for ; Tue, 17 Jul 2001 12:59:13 -0400 (EDT) Received: from BarrFS9RB01 (dhcp-238.rc.vix.com [204.152.187.238]) by shell.nominum.com (Postfix) with SMTP id 806423190D for ; Tue, 17 Jul 2001 09:58:57 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Tue, 17 Jul 2001 09:58:59 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.3.2.7.2.20010716202951.032de298@funnel.cisco.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit comments are inline --Barr > 11.1.1 DUID based on link-layer address plus time > > This type of DUID consists of four octets containing a time value, > followed by a two octet network hardware type code, followed by > link-layer address of any one network interface that is connected > to the DHCP client device at the time that the DUID is generated. > The time value is the time that the DUID is generated represented > in seconds since January 1, 2000, modulo 2^32. ... the beginning of the epoch should be specified as starting at a particular time of day, for example, midnight (00h00) UTC or midnight local time -- I tend to favor UTC as the intent is to make the identifier globally unique so it would (presumably) be of advantage to have the same start of epoch. Also, given that we can reasonably expect to be moving very soon to 64-bit time values, is a four-octet value an appropriate choice? > The hardware type > MUST be a valid hardware type assigned by the IANA as described in > the section on ARP in [23]. Both the time and the hardware type > are stored in network byte order. ... this assumes that the link-layer address lengths are well-known, which I'm not quite sure is universally correct. While most of us know that Ethernet addresses are 48-bits, how many of us know the length of every other hardware address? I would propose generalizing this by adding a length octet immediately following the hardware type. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Time (32 bits) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hardware type (16 bits) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > . . > . link-layer address (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The choice of network interface can be completely arbitrary, as > long as that interface provides a unique link-layer address, and > the same DUID should be used in configuring all network interfaces > connected to the device, regardless of which interface's link-layer > address was used to generate the DUID. > > DHCP clients using this type of DUID MUST store the DUID in stable > storage, and MUST continue to use this DUID even if the network > interface used to generate the DUID is removed. DHCP clients that > do not have any stable storage MUST NOT use this type of DUID. > > DHCP clients that use this DUID SHOULD attempt to configure the > time prior to generating the DUID, if that is possible, and MUST > use some sort of time source (e.g., a real-time clock) in > generating the DUID, even if that time source is not configured by > the user prior to generating the DUID. The use of a time source > makes it unlikely that if the network interface is removed from the > client and another client then uses the same network interface to > generate a DUID, that two identical DUIDs will be generated. A > DUID collision is very unlikely even if the clocks haven't been > configured prior to generating the DUID. > > This method of DUID generation is recommended for all general > purpose computing devices such as desktop computers and laptop > computers, and also for devices such as printers, routers, and so > on, that contain some form of writeable non-volatile storage. > > 11.1.2 Vendor-assigned unique ID. > > The vendor-assigned unique ID consists of an eight-octet > vendor-unique identifier, followed by the vendor's registered > domain name. ... given that domain names are changed as frequently as corporate identity makeovers or marketing department changes of direction I'd like some other sort of "registered" identify, but I'm not sure what to propose in place of domain name. Is an 8-octet identifier sufficient as the number of networked devices increases? > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | VUID (64 bits) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . domain name (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > The structure of the VUID is left up to the vendor defining it, > but each device containing such a VUID MUST be unique to each > device that is using it, and MUST be assigned to the device at the > time of manufacture and stored in some form of non-volatile > storage. The VUID SHOULD be recorded in non-erasable storage. ... would the vendor ID include some numeric encoding of the vendor's identity, or is it intended that the domain name portion do that, leaving VUID to be, essentially, an equipment serial number? If the vendor's identity is encoded in the VUID then registration/assignment of vendor IDs become a task for IANA, would we expand the IEEE codes as used in Ethernet addresses, or use some other identifier that is widely available such as SIC/NMIC? > The domain name is simply any domain name that has been legally > registered by the vendor in the domain name system, stored in > canonical form. An example DUID of this type might look like > this: > > +--+---+---+---+-+-+--+---+---+--+---+---+---+---+--+--+---+---+ > |12|192|132|221|3|9|18|101|120|97|109|112|108|101|46|99|111|109| > +--+---+---+---+-+-+--+---+---+--+---+---+---+---+--+--+---+---+ > > This is eight octets of VUID data, followed by "example.com" > represented in ASCII. > > 11.1.3 Link-layer address > > This type of DUID consists of a two octet network hardware type > code, followed by the link-layer address of any one network > interface that is permanently connected to the DHCP client device. ... I think the following sentence should be struck from this section: > The time value is the time that the DUID is generated represented > in seconds since January 1, 2000, modulo 2^32. > The hardware type > MUST be a valid hardware type assigned by the IANA as described in > the section on ARP in [23]. The hardware type is stored in network > byte order. ... Again, I think that an address length octet should be added to this form, following the hardware type. > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Hardware type (16 bits) | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | > . . > . link-layer address (variable length) . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > The choice of network interface can be completely arbitrary, as > long as that interface provides a unique link-layer address and is > permanently attached to the device on which the DUID is being > generated. The same DUID should be used in configuring all network > interfaces connected to the device, regardless of which interface's > link-layer address was used to generate the DUID. > > This type of DUID is recommended for devices that have a > permanently-connected network interface with a link-layer address > and do not have nonvolatile, write able stable storage. This type > of DUID MUST NOT be used by DHCP clients that cannot tell whether > or not a network interface is permanently attached to the device on > which the DHCP client is running. > From owner-dhcp-v6@bucknell.edu Tue Jul 17 16:21:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05659; Tue, 17 Jul 2001 16:21:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HKLLL19590; Tue, 17 Jul 2001 16:21:21 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HKLAL14793 for ; Tue, 17 Jul 2001 16:21:10 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6HKGxf12584 for ; Tue, 17 Jul 2001 13:16:59 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6HKHqP00373 for ; Tue, 17 Jul 2001 13:17:52 -0700 (MST) Message-Id: <200107172017.f6HKHqP00373@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: Message from "Bernie Volz (EUD)" of "Tue, 17 Jul 2001 08:27:41 EST." <66F66129A77AD411B76200508B65AC697B3291@eambunt705.ena-east.ericsson.se> Date: Tue, 17 Jul 2001 13:17:52 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I agree that the prefix handling should avoid the need for the > NACK. There is still an issue of non-address configurations and > perhaps a general "DHCP Error" option (in a Reply) that can be used > to communicate problems might be useful. But, it is also something > that perhaps can be added later (though existing clients would of > course ignore that option). I think this is fine (don't see the new for a new option, unless it's a text error message), but I think it would be good to have some verbiage that just says "if the client gets a Wrong Prefix message, it SHOULD by default give up its existing IAs and go back to the DHCP Solicit phase, but SHOULD be configurable not to, or something like that." I am not sure how this situation could come about, as long as the client is listening to router advertisements, but it worries me, and I'd like to see it covered. I guess this is something that could wait for some implementation experience after last call, though. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 17 17:08:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14887; Tue, 17 Jul 2001 17:08:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HKWCL05677; Tue, 17 Jul 2001 16:32:12 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HKW1L01960 for ; Tue, 17 Jul 2001 16:32:01 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6HKRpf12605; Tue, 17 Jul 2001 13:27:51 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6HKShP00386; Tue, 17 Jul 2001 13:28:43 -0700 (MST) Message-Id: <200107172028.f6HKShP00386@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: Definition of DUID In-Reply-To: Message from "Barr Hibbs" of "Tue, 17 Jul 2001 09:58:59 MST." Date: Tue, 17 Jul 2001 13:28:43 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > ... the beginning of the epoch should be specified as starting at a > particular time of day, for example, midnight (00h00) UTC or midnight local > time -- I tend to favor UTC as the intent is to make the identifier globally > unique so it would (presumably) be of advantage to have the same start of > epoch. Oops. Yes, we need both of these changes. > Also, given that we can reasonably expect to be moving very soon to 64-bit > time values, is a four-octet value an appropriate choice? Yes. I would say a two-octet value would be fine, frankly. There's no need to add an extra four bytes to the identifier, and keeping it small is a virtue. The time from the beginning to the end of the epoch is long enough that the likelihood of a collision caused by this particular problem seems remote. :') > ... this assumes that the link-layer address lengths are well-known, which > I'm not quite sure is universally correct. While most of us know that > Ethernet addresses are 48-bits, how many of us know the length of every > other hardware address? I would propose generalizing this by adding a > length octet immediately following the hardware type. That's not necessary. We already know how long the DUID is, because it's an option. > ... given that domain names are changed as frequently as corporate > identity makeovers or marketing department changes of direction I'd like > some other sort of "registered" identify, but I'm not sure what to propose > in place of domain name. That's just it. We can't make the IANA do it. Short of that, making the domain registrars do it seems like the easiest thing. I can definitely conceive of this becoming a problem once in a while, but it's a problem that the manufacturer will have some interest in avoiding, so I'm not *too* worried about it. > Is an 8-octet identifier sufficient as the number of networked devices > increases? There aren't that many atoms in the universe, so yes, I think this will do. :') > ... would the vendor ID include some numeric encoding of the vendor's > identity, or is it intended that the domain name portion do that, leaving > VUID to be, essentially, an equipment serial number? If the vendor's > identity is encoded in the VUID then registration/assignment of vendor IDs > become a task for IANA, would we expand the IEEE codes as used in Ethernet > addresses, or use some other identifier that is widely available such as > SIC/NMIC? This is precisely what I am trying to avoid by using the domain name. > ... I think the following sentence should be struck from this section: > > > The time value is the time that the DUID is generated represented > > in seconds since January 1, 2000, modulo 2^32. You are right. > ... Again, I think that an address length octet should be added to this > form, following the hardware type. See above. :'} _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 17 17:11:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15420; Tue, 17 Jul 2001 17:11:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HLBNL14584; Tue, 17 Jul 2001 17:11:23 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HLBJL22731 for ; Tue, 17 Jul 2001 17:11:19 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6HLB3509097 for ; Tue, 17 Jul 2001 16:11:03 -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 f6HLB3V02795 for ; Tue, 17 Jul 2001 16:11:03 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jul 17 16:11:02 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP28H1R>; Tue, 17 Jul 2001 16:11:02 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32AD@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Tue, 17 Jul 2001 16:11:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F04.FBF640B0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F04.FBF640B0 Content-Type: text/plain; charset="iso-8859-1" FYI - Forgot to add that the GSM document also defines the IMEI. It to is 15 digits: 6 digits for TAC (Type Approval Code, determined by a "central body"). 2 digits for FAC (Final Assmbly Code, identifies place of manufacture/final assembly) 6 digits for SNR (Serial Number, unique within a TAC + FAC) 1 digit for a spare -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Tuesday, July 17, 2001 4:38 PM To: DHCPv6 discussion list Subject: RE: Definition of DUID Ted, Ralph, et al: This does look great! Thanks Ted. Regarding Barr's comment regarding a length field for the link-layer address, I don't see why we need this. Sure, there may be many link-layer addresses that are not fixed length, but the option's length field will tell you what the length of the link-layer address is (after subtracting the other octets since they are fixed). So, why add an extra octet to all of the packets that isn't needed. Regarding Barr's comments on a 64-bit time, we could do this but again I think 32-bits is enough insurance. There are likely some privacy issues about knowing that exact time a DUID was created that someone would complain about? Having it be modulo 2^32 is fine since all we're trying to prevent is a collision in cases where a NIC card is moved between systems and both may use the MAC address to generate the DUID. Having a 64-bit time won't buy much, especially if maintained in seconds. The upper 32-bits will be stable over long periods and I suspect that most NICs won't last the 100 or so years covered by 32 bits. Regarding IMEI, see http://www.buyncell.com/gsminfo/imei.shtml and http://home.swipnet.se/OsbyMikro/imeie.htm for some details. I'm sure that this is also specified in some GSM documentation but haven't been able to locate it. Regarding IMSI, see GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification", European Telecommunications Standards Institute, April 1997". You can download documents from www.etsi.org (you need to register). Some of the basics are: IMSI consists of numerical characters (0 thru 9) only. The overall number of digits shall not exceed 15. There are 3 parts of the number: MCC (3 digits) - Mobile Country Code MNC (2 digits) - Mobile Network Code (GSM PLMN within country) MSIN (remaining digits) - Mobile Subscriber Identification Number We probably would want to store these in an more efficient encoding than 15 bytes (perhaps BCD encoded, 4-bits per digit though that does make it difficult to represent an odd number of digits). Hope that helps! - Bernie ------_=_NextPart_001_01C10F04.FBF640B0 Content-Type: text/html; charset="iso-8859-1" RE: Definition of DUID
FYI - Forgot to add that the GSM document also defines the IMEI. It to is 15 digits:
    6 digits for TAC (Type Approval Code, determined by a "central body").
    2 digits for FAC (Final Assmbly Code, identifies place of manufacture/final assembly)
    6 digits for SNR (Serial Number, unique within a TAC + FAC)
    1 digit for a spare
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Tuesday, July 17, 2001 4:38 PM
To: DHCPv6 discussion list
Subject: RE: Definition of DUID

Ted, Ralph, et al:

This does look great! Thanks Ted.

Regarding Barr's comment regarding a length field for the link-layer address, I don't see why we need this. Sure, there may be many link-layer addresses that are not fixed length, but the option's length field will tell you what the length of the link-layer address is (after subtracting the other octets since they are fixed). So, why add an extra octet to all of the packets that isn't needed.

Regarding Barr's comments on a 64-bit time, we could do this but again I think 32-bits is enough insurance. There are likely some privacy issues about knowing that exact time a DUID was created that someone would complain about? Having it be modulo 2^32 is fine since all we're trying to prevent is a collision in cases where a NIC card is moved between systems and both may use the MAC address to generate the DUID. Having a 64-bit time won't buy much, especially if maintained in seconds. The upper 32-bits will be stable over long periods and I suspect that most NICs won't last the 100 or so years covered by 32 bits.

Regarding IMEI, see http://www.buyncell.com/gsminfo/imei.shtml and http://home.swipnet.se/OsbyMikro/imeie.htm for some details. I'm sure that this is also specified in some GSM documentation but haven't been able to locate it.

Regarding IMSI, see GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification", European Telecommunications Standards Institute, April 1997". You can download documents from www.etsi.org (you need to register). Some of the basics are:

        IMSI consists of numerical characters (0 thru 9) only.
        The overall number of digits shall not exceed 15.
        There are 3 parts of the number:
                MCC (3 digits)          - Mobile Country Code
                MNC (2 digits)          - Mobile Network Code (GSM PLMN within country)
                MSIN (remaining digits) - Mobile Subscriber Identification Number

We probably would want to store these in an more efficient encoding than 15 bytes (perhaps BCD encoded, 4-bits per digit though that does make it difficult to represent an odd number of digits).

Hope that helps!

- Bernie

------_=_NextPart_001_01C10F04.FBF640B0-- From owner-dhcp-v6@bucknell.edu Tue Jul 17 17:18:18 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16554; Tue, 17 Jul 2001 17:18:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HLIZL18569; Tue, 17 Jul 2001 17:18:35 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HLINL18343 for ; Tue, 17 Jul 2001 17:18:23 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6HLEDf12709 for ; Tue, 17 Jul 2001 14:14:13 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6HLF2P00513 for ; Tue, 17 Jul 2001 14:15:02 -0700 (MST) Message-Id: <200107172115.f6HLF2P00513@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: Message from "Bernie Volz (EUD)" of "Tue, 17 Jul 2001 15:54:55 EST." <66F66129A77AD411B76200508B65AC697B32AC@eambunt705.ena-east.ericsson.se> Date: Tue, 17 Jul 2001 14:15:02 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > We need to be careful about what "give up its existing IAs" means. > > Consider a mobile node ... perhaps this signals to it that it must > contact is Home Agent? In which case, it would want to keep the > (IA) addresses but get new addresses for the local network such that > it could (hopefully) contact the Home Agent. > > Also, consider your laptop. You plug it in at the office and get some > addresses. You later take it home. You do this 5 days a week. No reason > your laptop could not hold onto the "old" IAs and try one set first and > if that isn't accepted, try another. I'm not proposing that it do this > (likely cheaper to drop old and get new ones), just that it could. A > smarter implementation could even look at what the Router Advertisement > contains and match up IAs that it thinks are valid based on the prefixes. > > Obviously, the IA isn't valid on that link and thus MUST NOT be used on > that link. If the client needs addresses, it should go to the Solicit > phase. This is precisely what I was trying to get across, but I phrased it poorly. Can you turn this into language that could go into the draft? Would the authors accept such language if it were provided? _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 17 17:22:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17514; Tue, 17 Jul 2001 17:22:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HLMxL19266; Tue, 17 Jul 2001 17:22:59 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HLMsL19659 for ; Tue, 17 Jul 2001 17:22:54 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6HLMd513739 for ; Tue, 17 Jul 2001 16:22: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 f6HLMdL15186 for ; Tue, 17 Jul 2001 16:22:39 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue Jul 17 16:22:35 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPK16WQ>; Tue, 17 Jul 2001 16:22:34 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32AF@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? Date: Tue, 17 Jul 2001 16:22:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F06.96E14290" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F06.96E14290 Content-Type: text/plain; charset="iso-8859-1" I'm willing to try to turn this into language for the draft if the authors are interested. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Tuesday, July 17, 2001 5:15 PM To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? > We need to be careful about what "give up its existing IAs" means. > > Consider a mobile node ... perhaps this signals to it that it must > contact is Home Agent? In which case, it would want to keep the > (IA) addresses but get new addresses for the local network such that > it could (hopefully) contact the Home Agent. > > Also, consider your laptop. You plug it in at the office and get some > addresses. You later take it home. You do this 5 days a week. No reason > your laptop could not hold onto the "old" IAs and try one set first and > if that isn't accepted, try another. I'm not proposing that it do this > (likely cheaper to drop old and get new ones), just that it could. A > smarter implementation could even look at what the Router Advertisement > contains and match up IAs that it thinks are valid based on the prefixes. > > Obviously, the IA isn't valid on that link and thus MUST NOT be used on > that link. If the client needs addresses, it should go to the Solicit > phase. This is precisely what I was trying to get across, but I phrased it poorly. Can you turn this into language that could go into the draft? Would the authors accept such language if it were provided? _MelloN_ ------_=_NextPart_001_01C10F06.96E14290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

I'm willing to try to turn this into language for the = draft if the authors
are interested.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Tuesday, July 17, 2001 5:15 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6?



> We need to be careful about what "give up = its existing IAs" means.
>
> Consider a mobile node ... perhaps this signals = to it that it must
> contact is Home Agent? In which case, it would = want to keep the
> (IA) addresses but get new addresses for the = local network such that
> it could (hopefully) contact the Home = Agent.
>
> Also, consider your laptop. You plug it in at = the office and get some
> addresses. You later take it home. You do this = 5 days a week. No reason
> your laptop could not hold onto the = "old" IAs and try one set first and
> if that isn't accepted, try another. I'm not = proposing that it do this
> (likely cheaper to drop old and get new ones), = just that it could. A
> smarter implementation could even look at what = the Router Advertisement
> contains and match up IAs that it thinks are = valid based on the prefixes.
>
> Obviously, the IA isn't valid on that link and = thus MUST NOT be used on
> that link. If the client needs addresses, it = should go to the Solicit
> phase.

This is precisely what I was trying to get across, = but I phrased it
poorly.   Can you turn this into language = that could go into the
draft?

Would the authors accept such language if it were = provided?

        =         =                _MelloN_

------_=_NextPart_001_01C10F06.96E14290-- From owner-dhcp-v6@BUCKNELL.EDU Tue Jul 17 17:32:18 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19406; Tue, 17 Jul 2001 17:32:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HKjwL05343; Tue, 17 Jul 2001 16:45:58 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HKjjL04658 for ; Tue, 17 Jul 2001 16:45:45 -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 f6HKjip11049 for ; Tue, 17 Jul 2001 15:45:44 -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 f6HKjiV22412 for ; Tue, 17 Jul 2001 15:45:44 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Tue Jul 17 15:37:35 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP281F7>; Tue, 17 Jul 2001 15:37:35 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32AA@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Tue, 17 Jul 2001 15:37:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F00.4E88CF50" Reply-To: dhcp-v6@BUCKNELL.EDU Sender: owner-dhcp-v6@BUCKNELL.EDU X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F00.4E88CF50 Content-Type: text/plain; charset="iso-8859-1" Ted, Ralph, et al: This does look great! Thanks Ted. Regarding Barr's comment regarding a length field for the link-layer address, I don't see why we need this. Sure, there may be many link-layer addresses that are not fixed length, but the option's length field will tell you what the length of the link-layer address is (after subtracting the other octets since they are fixed). So, why add an extra octet to all of the packets that isn't needed. Regarding Barr's comments on a 64-bit time, we could do this but again I think 32-bits is enough insurance. There are likely some privacy issues about knowing that exact time a DUID was created that someone would complain about? Having it be modulo 2^32 is fine since all we're trying to prevent is a collision in cases where a NIC card is moved between systems and both may use the MAC address to generate the DUID. Having a 64-bit time won't buy much, especially if maintained in seconds. The upper 32-bits will be stable over long periods and I suspect that most NICs won't last the 100 or so years covered by 32 bits. Regarding IMEI, see http://www.buyncell.com/gsminfo/imei.shtml and http://home.swipnet.se/OsbyMikro/imeie.htm for some details. I'm sure that this is also specified in some GSM documentation but haven't been able to locate it. Regarding IMSI, see GSM Technical Specification GSM 03.03 (ETS 300 523): "Digital cellular telecommunication system (Phase 2); Numbering, addressing and identification", European Telecommunications Standards Institute, April 1997". You can download documents from www.etsi.org (you need to register). Some of the basics are: IMSI consists of numerical characters (0 thru 9) only. The overall number of digits shall not exceed 15. There are 3 parts of the number: MCC (3 digits) - Mobile Country Code MNC (2 digits) - Mobile Network Code (GSM PLMN within country) MSIN (remaining digits) - Mobile Subscriber Identification Number We probably would want to store these in an more efficient encoding than 15 bytes (perhaps BCD encoded, 4-bits per digit though that does make it difficult to represent an odd number of digits). Hope that helps! - Bernie ------_=_NextPart_001_01C10F00.4E88CF50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Definition of DUID

Ted, Ralph, et al:

This does look great! Thanks Ted.

Regarding Barr's comment regarding a length field for = the link-layer address, I don't see why we need this. Sure, there may = be many link-layer addresses that are not fixed length, but the = option's length field will tell you what the length of the link-layer = address is (after subtracting the other octets since they are fixed). = So, why add an extra octet to all of the packets that isn't = needed.

Regarding Barr's comments on a 64-bit time, we could = do this but again I think 32-bits is enough insurance. There are likely = some privacy issues about knowing that exact time a DUID was created = that someone would complain about? Having it be modulo 2^32 is fine = since all we're trying to prevent is a collision in cases where a NIC = card is moved between systems and both may use the MAC address to = generate the DUID. Having a 64-bit time won't buy much, especially if = maintained in seconds. The upper 32-bits will be stable over long = periods and I suspect that most NICs won't last the 100 or so years = covered by 32 bits.

Regarding IMEI, see http://www.buyncell.com/gsminfo/imei.shtml and http://home.swipnet.se/OsbyMikro/imeie.htm for = some details. I'm sure that this is also specified in some GSM = documentation but haven't been able to locate it.

Regarding IMSI, see GSM Technical Specification GSM = 03.03 (ETS 300 523): "Digital cellular telecommunication system = (Phase 2); Numbering, addressing and identification", European = Telecommunications Standards Institute, April 1997". You can = download documents from www.etsi.org (you need to register). Some of = the basics are:

        IMSI = consists of numerical characters (0 thru 9) only.
        The = overall number of digits shall not exceed 15.
        There are = 3 parts of the number:
        =         MCC (3 = digits)          - Mobile = Country Code
        =         MNC (2 = digits)          - Mobile = Network Code (GSM PLMN within country)
        =         MSIN = (remaining digits) - Mobile Subscriber Identification Number

We probably would want to store these in an more = efficient encoding than 15 bytes (perhaps BCD encoded, 4-bits per digit = though that does make it difficult to represent an odd number of = digits).

Hope that helps!

- Bernie

------_=_NextPart_001_01C10F00.4E88CF50-- From owner-dhcp-v6@bucknell.edu Tue Jul 17 17:44:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22178; Tue, 17 Jul 2001 17:44:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HKswL26070; Tue, 17 Jul 2001 16:54:58 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HKsuL12303 for ; Tue, 17 Jul 2001 16:54:56 -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 f6HKsup16701 for ; Tue, 17 Jul 2001 15:54:56 -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 f6HKstL00582 for ; Tue, 17 Jul 2001 15:54:55 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Tue Jul 17 15:54:55 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP28FZA>; Tue, 17 Jul 2001 15:54:54 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32AC@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? Date: Tue, 17 Jul 2001 15:54:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F02.BB917D70" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F02.BB917D70 Content-Type: text/plain; charset="iso-8859-1" We need to be careful about what "give up its existing IAs" means. Consider a mobile node ... perhaps this signals to it that it must contact is Home Agent? In which case, it would want to keep the (IA) addresses but get new addresses for the local network such that it could (hopefully) contact the Home Agent. Also, consider your laptop. You plug it in at the office and get some addresses. You later take it home. You do this 5 days a week. No reason your laptop could not hold onto the "old" IAs and try one set first and if that isn't accepted, try another. I'm not proposing that it do this (likely cheaper to drop old and get new ones), just that it could. A smarter implementation could even look at what the Router Advertisement contains and match up IAs that it thinks are valid based on the prefixes. Obviously, the IA isn't valid on that link and thus MUST NOT be used on that link. If the client needs addresses, it should go to the Solicit phase. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Tuesday, July 17, 2001 4:18 PM To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? > I agree that the prefix handling should avoid the need for the > NACK. There is still an issue of non-address configurations and > perhaps a general "DHCP Error" option (in a Reply) that can be used > to communicate problems might be useful. But, it is also something > that perhaps can be added later (though existing clients would of > course ignore that option). I think this is fine (don't see the new for a new option, unless it's a text error message), but I think it would be good to have some verbiage that just says "if the client gets a Wrong Prefix message, it SHOULD by default give up its existing IAs and go back to the DHCP Solicit phase, but SHOULD be configurable not to, or something like that." I am not sure how this situation could come about, as long as the client is listening to router advertisements, but it worries me, and I'd like to see it covered. I guess this is something that could wait for some implementation experience after last call, though. _MelloN_ ------_=_NextPart_001_01C10F02.BB917D70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNAK for DHCPv6?

We need to be careful about what "give up its = existing IAs" means.

Consider a mobile node ... perhaps this signals to it = that it must
contact is Home Agent? In which case, it would want = to keep the
(IA) addresses but get new addresses for the local = network such that
it could (hopefully) contact the Home Agent.

Also, consider your laptop. You plug it in at the = office and get some
addresses. You later take it home. You do this 5 = days a week. No reason
your laptop could not hold onto the "old" = IAs and try one set first and
if that isn't accepted, try another. I'm not = proposing that it do this
(likely cheaper to drop old and get new ones), just = that it could. A
smarter implementation could even look at what the = Router Advertisement
contains and match up IAs that it thinks are valid = based on the prefixes.

Obviously, the IA isn't valid on that link and thus = MUST NOT be used on
that link. If the client needs addresses, it should = go to the Solicit
phase.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Tuesday, July 17, 2001 4:18 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNAK for DHCPv6?



> I agree that the prefix handling should avoid = the need for the
> NACK. There is still an issue of non-address = configurations and
> perhaps a general "DHCP Error" option = (in a Reply) that can be used
> to communicate problems might be useful. But, = it is also something
> that perhaps can be added later (though = existing clients would of
> course ignore that option).

I think this is fine (don't see the new for a new = option, unless it's
a text error message), but I think it would be good = to have some
verbiage that just says "if the client gets a = Wrong Prefix message, it
SHOULD by default give up its existing IAs and go = back to the DHCP
Solicit phase, but SHOULD be configurable not to, or = something like
that."  I am not sure how this situation = could come about, as long as
the client is listening to router advertisements, = but it worries me,
and I'd like to see it covered.   I guess = this is something that could
wait for some implementation experience after last = call, though.

        =         =                _MelloN_

------_=_NextPart_001_01C10F02.BB917D70-- From owner-dhcp-v6@bucknell.edu Tue Jul 17 18:36:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29800; Tue, 17 Jul 2001 18:36:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HMaGL04283; Tue, 17 Jul 2001 18:36:16 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HMa7L06232 for ; Tue, 17 Jul 2001 18:36:07 -0400 (EDT) Received: from BarrFS9RB01 (dhcp-238.rc.vix.com [204.152.187.238]) by shell.nominum.com (Postfix) with SMTP id 37B223190C for ; Tue, 17 Jul 2001 15:35:48 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Tue, 17 Jul 2001 15:35:49 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200107172028.f6HKShP00386@grosse.bisbee.fugue.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit my responses are inline... --Barr > > Also, given that we can reasonably expect to be moving very > soon to 64-bit > > time values, is a four-octet value an appropriate choice? > > Yes. I would say a two-octet value would be fine, frankly. There's > no need to add an extra four bytes to the identifier, and keeping it > small is a virtue. The time from the beginning to the end of the > epoch is long enough that the likelihood of a collision caused by this > particular problem seems remote. :') > ...agreed, 68 years does seem long enough... but I thought I should ask.... > > ... this assumes that the link-layer address lengths are > well-known, which > > I'm not quite sure is universally correct. While most of us know that > > Ethernet addresses are 48-bits, how many of us know the length of every > > other hardware address? I would propose generalizing this by adding a > > length octet immediately following the hardware type. > > That's not necessary. We already know how long the DUID is, because > it's an option. > ...oops! forgot that! > > ... given that domain names are changed as frequently as corporate > > identity makeovers or marketing department changes of direction I'd like > > some other sort of "registered" identify, but I'm not sure what > to propose > > in place of domain name. > > That's just it. We can't make the IANA do it. Short of that, making > the domain registrars do it seems like the easiest thing. I can > definitely conceive of this becoming a problem once in a while, but > it's a problem that the manufacturer will have some interest in > avoiding, so I'm not *too* worried about it. > ...there doesn't seem to be a good answer to this one -- on the one hand, we should encourage vendors to select as short an identifier string as possible to identify the vendor, but not so long as to be burdensome. Is there any value to specifying the "domain name" part as an opaque, vendor-selected octet string (permitting, for example, UTF-8) with the strong suggestion that it be a (registered) trade-mark, domain name, or legal business name, but without burdening either IANA or a domain registrar? > > Is an 8-octet identifier sufficient as the number of > networked devices > > increases? > > There aren't that many atoms in the universe, so yes, I think this > will do. :') > ...so much for my knowledge of cosmology! > > ... would the vendor ID include some numeric encoding of the vendor's > > identity, or is it intended that the domain name portion do > that, leaving > > VUID to be, essentially, an equipment serial number? If the vendor's > > identity is encoded in the VUID then registration/assignment of > vendor IDs > > become a task for IANA, would we expand the IEEE codes as used > in Ethernet > > addresses, or use some other identifier that is widely available such as > > SIC/NMIC? > > This is precisely what I am trying to avoid by using the domain name. > ...good point From owner-dhcp-v6@bucknell.edu Tue Jul 17 19:18:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08791; Tue, 17 Jul 2001 19:18:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HNISL01588; Tue, 17 Jul 2001 19:18:28 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HNIAL14301 for ; Tue, 17 Jul 2001 19:18:10 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6HNHs520059 for ; Tue, 17 Jul 2001 18:17:54 -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 f6HNHsL27294 for ; Tue, 17 Jul 2001 18:17:54 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue Jul 17 18:17:53 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKFCX9>; Tue, 17 Jul 2001 18:17:53 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32B2@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Tue, 17 Jul 2001 18:17:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F16.B3DB5EC0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F16.B3DB5EC0 Content-Type: text/plain; charset="iso-8859-1" >...there doesn't seem to be a good answer to this one -- on the one hand, we >should encourage vendors to select as short an identifier string as possible >to identify the vendor, but not so long as to be burdensome. Is there any >value to specifying the "domain name" part as an opaque, vendor-selected >octet string (permitting, for example, UTF-8) with the strong suggestion >that it be a (registered) trade-mark, domain name, or legal business name, >but without burdening either IANA or a domain registrar? While domain names could be long, I think they are a reasonable identifier. There could be issues if a domain name used as a vendor id is sold (since the new vendor might have no idea what vendor IDs were used previously). However, mergers and the like don't create problems since if a domain name is switched, the previously shipped devices will continue to use the old values (burned in prom). The combined corporation hopefully knows what values were assigned in the past. The only issue that concerns me with domain names is that its one thing is someone uses nominum.com, but what about subdomains or even internationalized domains. Given that some internationalized domain names might go 3 or 4 levels, each that could be up to 63 characters, the DUID could easily end up at 100s of bytes. I don't have a solution other than to discourage use of this DUID type or, if used, reasonable length domain names are used (dell.com, compaq.com, intel.com, toshiba.com, gateway.com, etc are luckily all fairly short names). Depending on what character set is used for the domain names, another option is to allow something like @ (since @ is an invalid domain name character) - the ID would be in ASCII. Other characters could be used for other identifiers (of course, we could simply define new DUID types as well). Anyway, I think the domain name is a decent solution. Do we want to indicate some maximum limit to the length of the DUID? I'd like there to be one. I had suggested 32 bytes a while ago, but that is too short considering the types. I would recommend we consider something like 128? Perhaps we make this servers MUST be able to support DUIDs up to 128 bytes (longer ones would be truncated under the assumption that the first 128 bytes is unique). I'm open for other suggested maximum lengths (64, 256). - Bernie Volz -----Original Message----- From: Barr Hibbs [mailto:Barr.Hibbs@Nominum.com] Sent: Tuesday, July 17, 2001 6:36 PM To: DHCPv6 discussion list Subject: RE: Definition of DUID my responses are inline... --Barr > > Also, given that we can reasonably expect to be moving very > soon to 64-bit > > time values, is a four-octet value an appropriate choice? > > Yes. I would say a two-octet value would be fine, frankly. There's > no need to add an extra four bytes to the identifier, and keeping it > small is a virtue. The time from the beginning to the end of the > epoch is long enough that the likelihood of a collision caused by this > particular problem seems remote. :') > ...agreed, 68 years does seem long enough... but I thought I should ask.... > > ... this assumes that the link-layer address lengths are > well-known, which > > I'm not quite sure is universally correct. While most of us know that > > Ethernet addresses are 48-bits, how many of us know the length of every > > other hardware address? I would propose generalizing this by adding a > > length octet immediately following the hardware type. > > That's not necessary. We already know how long the DUID is, because > it's an option. > ...oops! forgot that! > > ... given that domain names are changed as frequently as corporate > > identity makeovers or marketing department changes of direction I'd like > > some other sort of "registered" identify, but I'm not sure what > to propose > > in place of domain name. > > That's just it. We can't make the IANA do it. Short of that, making > the domain registrars do it seems like the easiest thing. I can > definitely conceive of this becoming a problem once in a while, but > it's a problem that the manufacturer will have some interest in > avoiding, so I'm not *too* worried about it. > ...there doesn't seem to be a good answer to this one -- on the one hand, we should encourage vendors to select as short an identifier string as possible to identify the vendor, but not so long as to be burdensome. Is there any value to specifying the "domain name" part as an opaque, vendor-selected octet string (permitting, for example, UTF-8) with the strong suggestion that it be a (registered) trade-mark, domain name, or legal business name, but without burdening either IANA or a domain registrar? > > Is an 8-octet identifier sufficient as the number of > networked devices > > increases? > > There aren't that many atoms in the universe, so yes, I think this > will do. :') > ...so much for my knowledge of cosmology! > > ... would the vendor ID include some numeric encoding of the vendor's > > identity, or is it intended that the domain name portion do > that, leaving > > VUID to be, essentially, an equipment serial number? If the vendor's > > identity is encoded in the VUID then registration/assignment of > vendor IDs > > become a task for IANA, would we expand the IEEE codes as used > in Ethernet > > addresses, or use some other identifier that is widely available such as > > SIC/NMIC? > > This is precisely what I am trying to avoid by using the domain name. > ...good point ------_=_NextPart_001_01C10F16.B3DB5EC0 Content-Type: text/html; charset="iso-8859-1" RE: Definition of DUID

>...there doesn't seem to be a good answer to this one -- on the one hand, we
>should encourage vendors to select as short an identifier string as possible
>to identify the vendor, but not so long as to be burdensome.  Is there any
>value to specifying the "domain name" part as an opaque, vendor-selected
>octet string (permitting, for example, UTF-8) with the strong suggestion
>that it be a (registered) trade-mark, domain name, or legal business name,
>but without burdening either IANA or a domain registrar?

While domain names could be long, I think they are a reasonable identifier.
There could be issues if a domain name used as a vendor id is sold (since the
new vendor might have no idea what vendor IDs were used previously). However,
mergers and the like don't create problems since if a domain name is switched,
the previously shipped devices will continue to use the old values (burned in
prom). The combined corporation hopefully knows what values were assigned in
the past.

The only issue that concerns me with domain names is that its one thing is
someone uses nominum.com, but what about subdomains or even internationalized
domains. Given that some internationalized domain names might go 3 or 4 levels,
each that could be up to 63 characters, the DUID could easily end up at 100s
of bytes.

I don't have a solution other than to discourage use of this DUID type or, if
used, reasonable length domain names are used (dell.com, compaq.com, intel.com,
toshiba.com, gateway.com, etc are luckily all fairly short names).

Depending on what character set is used for the domain names, another option
is to allow something like @<SNMP-Enterprise-ID> (since @ is an invalid domain
name character) - the ID would be in ASCII. Other characters could be used for
other identifiers (of course, we could simply define new DUID types as well).

Anyway, I think the domain name is a decent solution.


Do we want to indicate some maximum limit to the length of the DUID? I'd like
there to be one. I had suggested 32 bytes a while ago, but that is too short
considering the types. I would recommend we consider something like 128? Perhaps
we make this servers MUST be able to support DUIDs up to 128 bytes (longer
ones would be truncated under the assumption that the first 128 bytes is unique).

I'm open for other suggested maximum lengths (64, 256).

- Bernie Volz

-----Original Message-----
From: Barr Hibbs [mailto:Barr.Hibbs@Nominum.com]
Sent: Tuesday, July 17, 2001 6:36 PM
To: DHCPv6 discussion list
Subject: RE: Definition of DUID



my responses are inline...

--Barr


> > Also, given that we can reasonably expect to be moving very
> soon to 64-bit
> > time values, is a four-octet value an appropriate choice?
>
> Yes.   I would say a two-octet value would be fine, frankly.   There's
> no need to add an extra four bytes to the identifier, and keeping it
> small is a virtue.   The time from the beginning to the end of the
> epoch is long enough that the likelihood of a collision caused by this
> particular problem seems remote.   :')
>
...agreed, 68 years does seem long enough...  but I thought I should ask....


> > ...   this assumes that the link-layer address lengths are
> well-known, which
> > I'm not quite sure is universally correct.  While most of us know that
> > Ethernet addresses are 48-bits, how many of us know the length of every
> > other hardware address?  I would propose generalizing this by adding a
> > length  octet immediately following the hardware type.
>
> That's not necessary.   We already know how long the DUID is, because
> it's an option.
>
...oops!  forgot that!


> > ...   given that domain names are changed as frequently as corporate
> > identity makeovers or marketing department changes of direction I'd like
> > some other sort of "registered" identify, but I'm not sure what
> to propose
> > in place of domain name.
>
> That's just it.  We can't make the IANA do it.  Short of that, making
> the domain registrars do it seems like the easiest thing.  I can
> definitely conceive of this becoming a problem once in a while, but
> it's a problem that the manufacturer will have some interest in
> avoiding, so I'm not *too* worried about it.
>
...there doesn't seem to be a good answer to this one -- on the one hand, we
should encourage vendors to select as short an identifier string as possible
to identify the vendor, but not so long as to be burdensome.  Is there any
value to specifying the "domain name" part as an opaque, vendor-selected
octet string (permitting, for example, UTF-8) with the strong suggestion
that it be a (registered) trade-mark, domain name, or legal business name,
but without burdening either IANA or a domain registrar?


> >       Is an 8-octet identifier sufficient as the number of
> networked devices
> > increases?
>
> There aren't that many atoms in the universe, so yes, I think this
> will do.   :')
>
...so much for my knowledge of cosmology!


> > ...   would the vendor ID include some numeric encoding of the vendor's
> > identity, or is it intended that the domain name portion do
> that, leaving
> > VUID to be, essentially, an equipment serial number?  If the vendor's
> > identity is encoded in the VUID then registration/assignment of
> vendor IDs
> > become a task for IANA, would we expand the IEEE codes as used
> in Ethernet
> > addresses, or use some other identifier that is widely available such as
> > SIC/NMIC?
>
> This is precisely what I am trying to avoid by using the domain name.
>
...good point

------_=_NextPart_001_01C10F16.B3DB5EC0-- From owner-dhcp-v6@bucknell.edu Tue Jul 17 19:43:52 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13492; Tue, 17 Jul 2001 19:43:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6HNiEL13760; Tue, 17 Jul 2001 19:44:14 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6HNhxL21833 for ; Tue, 17 Jul 2001 19:43:59 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6HNdnf12885; Tue, 17 Jul 2001 16:39:49 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6HNeSP08569; Tue, 17 Jul 2001 16:40:28 -0700 (MST) Message-Id: <200107172340.f6HNeSP08569@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: Definition of DUID In-Reply-To: Message from "Barr Hibbs" of "Tue, 17 Jul 2001 15:35:49 MST." Date: Tue, 17 Jul 2001 16:40:28 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > ...agreed, 68 years does seem long enough... but I thought I should ask.... It's actually 136 years. :') _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 17 20:10:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18585; Tue, 17 Jul 2001 20:10:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I0AWL05811; Tue, 17 Jul 2001 20:10:32 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6I0AVL24859 for ; Tue, 17 Jul 2001 20:10:31 -0400 (EDT) Received: from BarrFS9RB01 (dhcp-238.rc.vix.com [204.152.187.238]) by shell.nominum.com (Postfix) with SMTP id 4D0053190C for ; Tue, 17 Jul 2001 17:10:15 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Tue, 17 Jul 2001 17:10:16 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C10EE3.5967BB60" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <66F66129A77AD411B76200508B65AC697B32B2@eambunt705.ena-east.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C10EE3.5967BB60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Definition of DUIDBernie-- we'll probably just have to live with old, out-of-date domain names, but other than vanity issues (suppose IBM changed it's name to Ascentia, for example) there is probably no harm at all in allowing existing equipment to continue using an obsolete [but still, presumably, unique!] registered name. Domain name length and encoding *are* an issue, however. While there is a decided tendency for businesses to choose compact names, as you indicated, there are a few with larger names (nortelnetworks.com, for instance), and some for whom the preferred name coding might *not* be NVT-ASCII (?? -- Toshiba, is an example) when IDNs are finally supported. As far as second and third-level names are concerned, perhaps the description of this item option ought to strongly discourage use of anything but the base domain name? Your idea about encoding the SNMP Enterprise ID as ASCII digits prefixed by the "@" character is quite a good suggestion. I would argue that a vendor who would be supplying a DHCPv6 client is highly likely to also supply an SNMP agent or sub-agent, and Enterprise IDs are nicely compact. --Barr There could be issues if a domain name used as a vendor id is sold (since the new vendor might have no idea what vendor IDs were used previously). However, mergers and the like don't create problems since if a domain name is switched, the previously shipped devices will continue to use the old values (burned in prom). The combined corporation hopefully knows what values were assigned in the past. The only issue that concerns me with domain names is that its one thing is someone uses nominum.com, but what about subdomains or even internationalized domains. Given that some internationalized domain names might go 3 or 4 levels, each that could be up to 63 characters, the DUID could easily end up at 100s of bytes. I don't have a solution other than to discourage use of this DUID type or, if used, reasonable length domain names are used (dell.com, compaq.com, intel.com, toshiba.com, gateway.com, etc are luckily all fairly short names). Depending on what character set is used for the domain names, another option is to allow something like @ (since @ is an invalid domain name character) - the ID would be in ASCII. Other characters could be used for other identifiers (of course, we could simply define new DUID types as well). Anyway, I think the domain name is a decent solution. Do we want to indicate some maximum limit to the length of the DUID? I'd like there to be one. I had suggested 32 bytes a while ago, but that is too short considering the types. I would recommend we consider something like 128? Perhaps we make this servers MUST be able to support DUIDs up to 128 bytes (longer ones would be truncated under the assumption that the first 128 bytes is unique). I'm open for other suggested maximum lengths (64, 256). ------=_NextPart_000_0011_01C10EE3.5967BB60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Definition of DUID
Bernie--
 
we'll=20 probably just have to live with old, out-of-date domain names, but other = than=20 vanity issues (suppose IBM changed it's name to Ascentia, for example) = there is=20 probably no harm at all in allowing existing equipment to continue using = an=20 obsolete [but still, presumably, unique!] registered = name.
 
Domain name=20 length and encoding *are* an issue, however.  While there is a = decided=20 tendency for businesses to choose compact names, as you indicated, there = are a=20 few with larger names (nortelnetworks.com, for instance), and some for=20 whom the preferred name coding might *not* be NVT-ASCII (東芝 -- Toshiba, is an example) = when IDNs are=20 finally supported.
 
As far=20 as second and third-level names are concerned, perhaps the description = of this=20 item option ought to strongly discourage use of anything but the base = domain=20 name?
 
Your idea=20 about encoding the SNMP Enterprise ID as ASCII digits prefixed by the = "@"=20 character is quite a good suggestion.  I would argue that a vendor = who=20 would be supplying a DHCPv6 client is highly likely to also supply an = SNMP agent=20 or sub-agent, and Enterprise IDs are nicely compact.
 
--Barr
 
 
There could be=20 issues if a domain name used as a vendor id is sold (since the=20
new vendor might have no idea what vendor IDs were = used=20 previously). However,
mergers and the like = don't=20 create problems since if a domain name is switched,
the previously shipped devices will continue to use the old = values=20 (burned in
prom). The combined corporation = hopefully=20 knows what values were assigned in
the = past.=20

The only issue that concerns me with domain names is = that its=20 one thing is
someone uses nominum.com, but = what about=20 subdomains or even internationalized
domains. Given=20 that some internationalized domain names might go 3 or 4 = levels,=20
each that could be up to 63 characters, the DUID = could easily=20 end up at 100s
of bytes.

I don't have a solution other than to discourage use = of this=20 DUID type or, if
used, reasonable length = domain names=20 are used (dell.com, compaq.com, intel.com,
toshiba.com, gateway.com, etc are luckily all fairly short=20 names).

Depending on what character set is used for the = domain names,=20 another option
is to allow something like=20 @<SNMP-Enterprise-ID> (since @ is an invalid domain =
name character) - the ID would be in ASCII. Other characters = could be=20 used for
other identifiers (of course, we = could simply=20 define new DUID types as well).

Anyway, I think the domain name is a decent = solution.=20


Do we want to indicate some maximum limit to the = length of the=20 DUID? I'd like
there to be one. I had = suggested 32=20 bytes a while ago, but that is too short
considering=20 the types. I would recommend we consider something like 128? = Perhaps=20
we make this servers MUST be able to support DUIDs = up to 128=20 bytes (longer
ones would be truncated under = the=20 assumption that the first 128 bytes is unique).

I'm open for other suggested maximum lengths (64,=20 256).  

 

------=_NextPart_000_0011_01C10EE3.5967BB60-- From owner-dhcp-v6@bucknell.edu Tue Jul 17 20:11:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18932; Tue, 17 Jul 2001 20:11:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I0C0L07196; Tue, 17 Jul 2001 20:12:00 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6I0BjL29715 for ; Tue, 17 Jul 2001 20:11:45 -0400 (EDT) Received: from BarrFS9RB01 (dhcp-238.rc.vix.com [204.152.187.238]) by shell.nominum.com (Postfix) with SMTP id 59D363190C for ; Tue, 17 Jul 2001 17:11:30 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv6 discussion list Subject: FW: Definition of DUID Date: Tue, 17 Jul 2001 17:11:31 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C10EE3.86326820" 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 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------=_NextPart_000_0015_01C10EE3.86326820 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: Definition of DUID I'm sending this to the mailing list twice, in the hopes that one of the = forms will be completely readable by all recipients.... --Barr -----Original Message----- From: Barr Hibbs [mailto:Barr.Hibbs@Nominum.com] Sent: Tuesday, July 17, 2001 17:10 To: dhcp-v6@bucknell.edu Subject: RE: Definition of DUID=20 Bernie-- we'll probably just have to live with old, out-of-date domain names, but = other than vanity issues (suppose IBM changed it's name to Ascentia, for = example) there is probably no harm at all in allowing existing equipment = to continue using an obsolete [but still, presumably, unique!] = registered name. Domain name length and encoding *are* an issue, however. While there is = a decided tendency for businesses to choose compact names, as you = indicated, there are a few with larger names (nortelnetworks.com, for = instance), and some for whom the preferred name coding might *not* be = NVT-ASCII (=E6=9D=B1=E8=8A=9D -- Toshiba, is an example) when IDNs are = finally supported. As far as second and third-level names are concerned, perhaps the = description of this item option ought to strongly discourage use of = anything but the base domain name? Your idea about encoding the SNMP Enterprise ID as ASCII digits prefixed = by the "@" character is quite a good suggestion. I would argue that a = vendor who would be supplying a DHCPv6 client is highly likely to also = supply an SNMP agent or sub-agent, and Enterprise IDs are nicely = compact. --Barr There could be issues if a domain name used as a vendor id is sold = (since the=20 new vendor might have no idea what vendor IDs were used previously). = However,=20 mergers and the like don't create problems since if a domain name is = switched,=20 the previously shipped devices will continue to use the old values = (burned in=20 prom). The combined corporation hopefully knows what values were = assigned in=20 the past.=20 The only issue that concerns me with domain names is that its one = thing is=20 someone uses nominum.com, but what about subdomains or even = internationalized=20 domains. Given that some internationalized domain names might go 3 or = 4 levels,=20 each that could be up to 63 characters, the DUID could easily end up = at 100s=20 of bytes.=20 I don't have a solution other than to discourage use of this DUID type = or, if=20 used, reasonable length domain names are used (dell.com, compaq.com, = intel.com,=20 toshiba.com, gateway.com, etc are luckily all fairly short names).=20 Depending on what character set is used for the domain names, another = option=20 is to allow something like @ (since @ is an = invalid domain=20 name character) - the ID would be in ASCII. Other characters could be = used for=20 other identifiers (of course, we could simply define new DUID types as = well).=20 Anyway, I think the domain name is a decent solution.=20 Do we want to indicate some maximum limit to the length of the DUID? = I'd like=20 there to be one. I had suggested 32 bytes a while ago, but that is too = short=20 considering the types. I would recommend we consider something like = 128? Perhaps=20 we make this servers MUST be able to support DUIDs up to 128 bytes = (longer=20 ones would be truncated under the assumption that the first 128 bytes = is unique).=20 I'm open for other suggested maximum lengths (64, 256). =20 ------=_NextPart_000_0015_01C10EE3.86326820 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable RE: Definition of DUID
 
I'm=20 sending this to the mailing list twice, in the hopes that one of the = forms will=20 be completely readable by all recipients....
 
--Barr
 
 
-----Original Message-----
From: Barr Hibbs=20 [mailto:Barr.Hibbs@Nominum.com]
Sent: Tuesday, July 17, 2001=20 17:10
To: dhcp-v6@bucknell.edu
Subject: RE: = Definition of=20 DUID

Bernie--
 
we'll=20 probably just have to live with old, out-of-date domain names, but other = than=20 vanity issues (suppose IBM changed it's name to Ascentia, for example) = there is=20 probably no harm at all in allowing existing equipment to continue using = an=20 obsolete [but still, presumably, unique!] registered = name.
 
Domain name=20 length and encoding *are* an issue, however.  While there is a = decided=20 tendency for businesses to choose compact names, as you indicated, there = are a=20 few with larger names (nortelnetworks.com, for instance), and some for=20 whom the preferred name coding might *not* be NVT-ASCII (=E6=9D=B1=E8=8A=9D -- Toshiba, is an example) = when IDNs are=20 finally supported.
 
As far=20 as second and third-level names are concerned, perhaps the description = of this=20 item option ought to strongly discourage use of anything but the base = domain=20 name?
 
Your idea=20 about encoding the SNMP Enterprise ID as ASCII digits prefixed by the = "@"=20 character is quite a good suggestion.  I would argue that a vendor = who=20 would be supplying a DHCPv6 client is highly likely to also supply an = SNMP agent=20 or sub-agent, and Enterprise IDs are nicely compact.
 
--Barr
 
 
There could be=20 issues if a domain name used as a vendor id is sold (since the=20
new vendor might have no idea what vendor IDs were = used=20 previously). However,
mergers and the like = don't=20 create problems since if a domain name is switched,
the previously shipped devices will continue to use the old = values=20 (burned in
prom). The combined corporation = hopefully=20 knows what values were assigned in
the = past.=20

The only issue that concerns me with domain names is = that its=20 one thing is
someone uses nominum.com, but = what about=20 subdomains or even internationalized
domains. Given=20 that some internationalized domain names might go 3 or 4 = levels,=20
each that could be up to 63 characters, the DUID = could easily=20 end up at 100s
of bytes.

I don't have a solution other than to discourage use = of this=20 DUID type or, if
used, reasonable length = domain names=20 are used (dell.com, compaq.com, intel.com,
toshiba.com, gateway.com, etc are luckily all fairly short=20 names).

Depending on what character set is used for the = domain names,=20 another option
is to allow something like=20 @<SNMP-Enterprise-ID> (since @ is an invalid domain =
name character) - the ID would be in ASCII. Other characters = could be=20 used for
other identifiers (of course, we = could simply=20 define new DUID types as well).

Anyway, I think the domain name is a decent = solution.=20


Do we want to indicate some maximum limit to the = length of the=20 DUID? I'd like
there to be one. I had = suggested 32=20 bytes a while ago, but that is too short
considering=20 the types. I would recommend we consider something like 128? = Perhaps=20
we make this servers MUST be able to support DUIDs = up to 128=20 bytes (longer
ones would be truncated under = the=20 assumption that the first 128 bytes is unique).

I'm open for other suggested maximum lengths (64,=20 256).  

 

------=_NextPart_000_0015_01C10EE3.86326820-- From owner-dhcp-v6@bucknell.edu Tue Jul 17 21:08:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02308; Tue, 17 Jul 2001 21:08:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I18SL22998; Tue, 17 Jul 2001 21:08:28 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6I18DL07112 for ; Tue, 17 Jul 2001 21:08:14 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6I142f12976; Tue, 17 Jul 2001 18:04:03 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6I14bA00454; Tue, 17 Jul 2001 18:04:37 -0700 (MST) Message-Id: <200107180104.f6I14bA00454@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: Definition of DUID In-Reply-To: Message from "Barr Hibbs" of "Tue, 17 Jul 2001 17:10:16 MST." Date: Tue, 17 Jul 2001 18:04:36 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Domain name length and encoding *are* an issue, however. While there is a > decided tendency for businesses to choose compact names, as you indicated, > there are a few with larger names (nortelnetworks.com, for instance), and > some for whom the preferred name coding might *not* be NVT-ASCII (?? -- > Toshiba, is an example) when IDNs are finally supported. I really don't think this is a big issue. In the cases where we really care about size, an option that uses an identifier registry is the way to go. For example, a cell phone can just send its own ID, and there's a registry for those already. Likewise, a device with an embedded 802.11 controller that's permanently attached can use that identifier. I put this in here because it's a good, easy way to come up with a private identifier registry in cases where you need a quick solution and where it doesn't make sense to go through a special standards process. One drawback of this is that in theory we need to be able to handle an arbitrarily long identifier, but actually there's a limit to the length of a domain name, and I really don't think this is going to produce a very long identifier in most cases. If IBM changes its name to ascentia, they will probably keep the ibm.com domain anyway. I think www.dec.com still works, and DEC has been part of Compaq for a longish time now. Toshiba's domain name is toshiba.com. Until the IDN folks comes up with a way for toshiba.com to be represented in kanji, I would propose that we table this issue. When IDN comes out with a solution, we can come out with a standard describing how that applies to the generation of identifiers. > As far as second and third-level names are concerned, perhaps the > description of this item option ought to strongly discourage use of anything > but the base domain name? I think we should assume that the reader will be intelligent about this. Third-level names are quite common outside of the U.S., so specifying this carefully would be a lot of unnecessary work. I am all in favor of being careful in standards documents, but I think that the level of carefulness I used here was the right one, and getting more careful would actually be counterproductive. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 17 21:08:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02369; Tue, 17 Jul 2001 21:08:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I191L26283; Tue, 17 Jul 2001 21:09:01 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I18cL09974 for ; Tue, 17 Jul 2001 21:08:38 -0400 (EDT) Received: from 157.54.9.100 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 17 Jul 2001 18:08:19 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 17 Jul 2001 18:07:19 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 17 Jul 2001 18:07:19 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 17 Jul 2001 18:06:17 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F25.D90B1A69" Subject: RE: Definition of DUID Date: Tue, 17 Jul 2001 18:06:17 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC162B6CF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Definition of DUID Thread-Index: AcEPFwd5adGOun0oQbOyqi1EpOaMrgAC1YwA From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 18 Jul 2001 01:06:17.0595 (UTC) FILETIME=[D93D14B0:01C10F25] Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------_=_NextPart_001_01C10F25.D90B1A69 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As far as using domain names in a DUID goes - it can be used in a small subset of apps. I would expect a lot of the clients implementing DHCPv6 to obtain their domain name from a DHCP Server as opposed to using a hard coded domain name built it. Since we expect this way of figuring out the DUID is not very advisable as noted below - is this useful for any set of apps? If it is not useful for a specific set of clients - why not just scrub it from the spec? =20 I also second the idea of an upper limit for the DUID length. An option is two octets long and the DUID option length can potentially be 64K long. This is going to impact the server implementation. Either this will lead to implementations that will put self imposed restrictions on the length of the DUID or they should be ready to take care of 64K long DUIDs. I think 256 octets is a reasonable upper bound. =20 thx =20 -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]=20 Sent: Tuesday, July 17, 2001 4:18 PM To: DHCPv6 discussion list Subject: RE: Definition of DUID=20 =20 >...there doesn't seem to be a good answer to this one -- on the one hand, we=20 >should encourage vendors to select as short an identifier string as possible=20 >to identify the vendor, but not so long as to be burdensome. Is there any=20 >value to specifying the "domain name" part as an opaque, vendor-selected=20 >octet string (permitting, for example, UTF-8) with the strong suggestion=20 >that it be a (registered) trade-mark, domain name, or legal business name,=20 >but without burdening either IANA or a domain registrar?=20 While domain names could be long, I think they are a reasonable identifier.=20 There could be issues if a domain name used as a vendor id is sold (since the=20 new vendor might have no idea what vendor IDs were used previously). However,=20 mergers and the like don't create problems since if a domain name is switched,=20 the previously shipped devices will continue to use the old values (burned in=20 prom). The combined corporation hopefully knows what values were assigned in=20 the past.=20 The only issue that concerns me with domain names is that its one thing is=20 someone uses nominum.com, but what about subdomains or even internationalized=20 domains. Given that some internationalized domain names might go 3 or 4 levels,=20 each that could be up to 63 characters, the DUID could easily end up at 100s=20 of bytes.=20 I don't have a solution other than to discourage use of this DUID type or, if=20 used, reasonable length domain names are used (dell.com, compaq.com, intel.com,=20 toshiba.com, gateway.com, etc are luckily all fairly short names).=20 Depending on what character set is used for the domain names, another option=20 is to allow something like @ (since @ is an invalid domain=20 name character) - the ID would be in ASCII. Other characters could be used for=20 other identifiers (of course, we could simply define new DUID types as well).=20 Anyway, I think the domain name is a decent solution.=20 =20 Do we want to indicate some maximum limit to the length of the DUID? I'd like=20 there to be one. I had suggested 32 bytes a while ago, but that is too short=20 considering the types. I would recommend we consider something like 128? Perhaps=20 we make this servers MUST be able to support DUIDs up to 128 bytes (longer=20 ones would be truncated under the assumption that the first 128 bytes is unique).=20 I'm open for other suggested maximum lengths (64, 256).=20 - Bernie Volz=20 -----Original Message-----=20 From: Barr Hibbs [mailto:Barr.Hibbs@Nominum.com]=20 Sent: Tuesday, July 17, 2001 6:36 PM=20 To: DHCPv6 discussion list=20 Subject: RE: Definition of DUID=20 =20 my responses are inline...=20 --Barr=20 =20 > > Also, given that we can reasonably expect to be moving very=20 > soon to 64-bit=20 > > time values, is a four-octet value an appropriate choice?=20 >=20 > Yes. I would say a two-octet value would be fine, frankly. There's > no need to add an extra four bytes to the identifier, and keeping it=20 > small is a virtue. The time from the beginning to the end of the=20 > epoch is long enough that the likelihood of a collision caused by this > particular problem seems remote. :')=20 >=20 ...agreed, 68 years does seem long enough... but I thought I should ask....=20 =20 > > ... this assumes that the link-layer address lengths are=20 > well-known, which=20 > > I'm not quite sure is universally correct. While most of us know that=20 > > Ethernet addresses are 48-bits, how many of us know the length of every=20 > > other hardware address? I would propose generalizing this by adding a=20 > > length octet immediately following the hardware type.=20 >=20 > That's not necessary. We already know how long the DUID is, because=20 > it's an option.=20 >=20 ...oops! forgot that!=20 =20 > > ... given that domain names are changed as frequently as corporate > > identity makeovers or marketing department changes of direction I'd like=20 > > some other sort of "registered" identify, but I'm not sure what=20 > to propose=20 > > in place of domain name.=20 >=20 > That's just it. We can't make the IANA do it. Short of that, making=20 > the domain registrars do it seems like the easiest thing. I can=20 > definitely conceive of this becoming a problem once in a while, but=20 > it's a problem that the manufacturer will have some interest in=20 > avoiding, so I'm not *too* worried about it.=20 >=20 ...there doesn't seem to be a good answer to this one -- on the one hand, we=20 should encourage vendors to select as short an identifier string as possible=20 to identify the vendor, but not so long as to be burdensome. Is there any=20 value to specifying the "domain name" part as an opaque, vendor-selected octet string (permitting, for example, UTF-8) with the strong suggestion that it be a (registered) trade-mark, domain name, or legal business name,=20 but without burdening either IANA or a domain registrar?=20 =20 > > Is an 8-octet identifier sufficient as the number of=20 > networked devices=20 > > increases?=20 >=20 > There aren't that many atoms in the universe, so yes, I think this=20 > will do. :')=20 >=20 ...so much for my knowledge of cosmology!=20 =20 > > ... would the vendor ID include some numeric encoding of the vendor's=20 > > identity, or is it intended that the domain name portion do=20 > that, leaving=20 > > VUID to be, essentially, an equipment serial number? If the vendor's=20 > > identity is encoded in the VUID then registration/assignment of=20 > vendor IDs=20 > > become a task for IANA, would we expand the IEEE codes as used=20 > in Ethernet=20 > > addresses, or use some other identifier that is widely available such as=20 > > SIC/NMIC?=20 >=20 > This is precisely what I am trying to avoid by using the domain name.=20 >=20 ...good point=20 ------_=_NextPart_001_01C10F25.D90B1A69 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Definition of DUID

As far as using domain names in a = DUID goes – it can be used in a small subset of apps. I would expect a = lot of the clients implementing DHCPv6 to obtain their domain name from a DHCP = Server as opposed to using a hard coded domain name built it. Since we expect = this way of figuring out the DUID is not very advisable as noted below – is = this useful for any set of apps? If it is not useful for a specific set of = clients – why not just scrub it from the spec?

 

I also second the idea of an upper = limit for the DUID length. An option is two octets long and the DUID option = length can potentially be 64K long. This is going to impact the server = implementation. Either this will lead to implementations that will put self imposed restrictions on the length of the DUID or they should be ready to take = care of 64K long DUIDs. I think 256 octets is a reasonable upper = bound.

 

thx

 

-----Original = Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Tuesday, July 17, = 2001 4:18 PM
To: DHCPv6 discussion = list
Subject: RE: Definition = of DUID

 

>...there doesn't seem to be a good answer = to this one -- on the one hand, we
>should encourage = vendors to select as short an identifier string as possible
>to identify the = vendor, but not so long as to be burdensome.  Is there any
>value to specifying = the "domain name" part as an opaque, vendor-selected =
>octet string = (permitting, for example, UTF-8) with the strong suggestion
>that it be a = (registered) trade-mark, domain name, or legal business name,
>but without = burdening either IANA or a domain registrar?

While domain names could be long, I think = they are a reasonable identifier.
There could be issues if = a domain name used as a vendor id is sold (since the
new vendor might have no = idea what vendor IDs were used previously). However,
mergers and the like = don't create problems since if a domain name is switched,
the previously shipped = devices will continue to use the old values (burned in
prom). The combined = corporation hopefully knows what values were assigned in
the past. =

The only issue that concerns me with domain = names is that its one thing is
someone uses = nominum.com, but what about subdomains or even internationalized
domains. Given that some internationalized domain names might go 3 or 4 levels, =
each that could be up to = 63 characters, the DUID could easily end up at 100s
of bytes. =

I don't have a solution other than to = discourage use of this DUID type or, if
used, reasonable length = domain names are used (dell.com, compaq.com, intel.com,
toshiba.com, = gateway.com, etc are luckily all fairly short names).

Depending on what character set is used for = the domain names, another option
is to allow something = like @<SNMP-Enterprise-ID> (since @ is an invalid domain
name character) - the ID = would be in ASCII. Other characters could be used for
other identifiers (of = course, we could simply define new DUID types as well).

Anyway, I think the domain name is a decent = solution.

 

Do we want to indicate some maximum limit to = the length of the DUID? I'd like
there to be one. I had = suggested 32 bytes a while ago, but that is too short
considering the types. I = would recommend we consider something like 128? Perhaps
we make this servers = MUST be able to support DUIDs up to 128 bytes (longer
ones would be truncated = under the assumption that the first 128 bytes is unique).

I'm open for other suggested maximum lengths = (64, 256).

- Bernie Volz

-----Original Message-----
From: Barr Hibbs [mailto:Barr.Hibbs@Nominum.com]=
Sent: Tuesday, July 17, = 2001 6:36 PM
To: DHCPv6 discussion = list
Subject: RE: Definition = of DUID

 

my responses are inline...

--Barr

 

> > Also, given that we can reasonably = expect to be moving very
> soon to = 64-bit
> > time values, = is a four-octet value an appropriate choice?
>
> Yes.   I = would say a two-octet value would be fine, frankly.   = There's
> no need to add an = extra four bytes to the identifier, and keeping it
> small is a = virtue.   The time from the beginning to the end of the
> epoch is long = enough that the likelihood of a collision caused by this
> particular problem = seems remote.   :')
>
...agreed, 68 years does = seem long enough...  but I thought I should ask....

 

> > ...   this assumes that = the link-layer address lengths are
> well-known, = which
> > I'm not quite = sure is universally correct.  While most of us know that
> > Ethernet = addresses are 48-bits, how many of us know the length of every
> > other hardware address?  I would propose generalizing this by adding = a
> > length  = octet immediately following the hardware type.
>
> That's not necessary.   We already know how long the DUID is, = because
> it's an = option.
>
...oops!  forgot = that!

 

> > ...   given that domain = names are changed as frequently as corporate
> > identity = makeovers or marketing department changes of direction I'd like
> > some other = sort of "registered" identify, but I'm not sure what =
> to = propose
> > in place of = domain name.
>
> That's just = it.  We can't make the IANA do it.  Short of that, making
> the domain = registrars do it seems like the easiest thing.  I can
> definitely conceive = of this becoming a problem once in a while, but
> it's a problem that = the manufacturer will have some interest in
> avoiding, so I'm = not *too* worried about it.
>
...there doesn't seem to = be a good answer to this one -- on the one hand, we
should encourage vendors = to select as short an identifier string as possible
to identify the vendor, = but not so long as to be burdensome.  Is there any
value to specifying the "domain name" part as an opaque, vendor-selected =
octet string = (permitting, for example, UTF-8) with the strong suggestion
that it be a = (registered) trade-mark, domain name, or legal business name,
but without burdening = either IANA or a domain registrar?

 

> >       = Is an 8-octet identifier sufficient as the number of
> networked = devices
> > = increases?
>
> There aren't that = many atoms in the universe, so yes, I think this
> will = do.   :')
>
...so much for my = knowledge of cosmology!

 

> > ...   would the vendor ID = include some numeric encoding of the vendor's
> > identity, or = is it intended that the domain name portion do
> that, = leaving
> > VUID to be, = essentially, an equipment serial number?  If the vendor's
> > identity is = encoded in the VUID then registration/assignment of
> vendor = IDs
> > become a task = for IANA, would we expand the IEEE codes as used
> in = Ethernet
> > addresses, or = use some other identifier that is widely available such as
> > = SIC/NMIC?
>
> This is precisely = what I am trying to avoid by using the domain name.
>
...good = point

=00 ------_=_NextPart_001_01C10F25.D90B1A69-- From owner-dhcp-v6@bucknell.edu Tue Jul 17 21:51:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11597; Tue, 17 Jul 2001 21:51:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I1pcL03560; Tue, 17 Jul 2001 21:51:38 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6I1pRL32636 for ; Tue, 17 Jul 2001 21:51:27 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6I1lHf13023 for ; Tue, 17 Jul 2001 18:47:17 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6I1lmA00712 for ; Tue, 17 Jul 2001 18:47:48 -0700 (MST) Message-Id: <200107180147.f6I1lmA00712@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Definition of DUID In-Reply-To: Message from "Thirumalesh Bhat" of "Tue, 17 Jul 2001 18:06:17 MST." <2E33960095B58E40A4D3345AB9F65EC162B6CF@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Tue, 17 Jul 2001 18:47:48 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > As far as using domain names in a DUID goes - it can be used in a small > subset of apps. I would expect a lot of the clients implementing DHCPv6 > to obtain their domain name from a DHCP Server as opposed to using a > hard coded domain name built it. This is a seperate issue. The domain name in the VUID DUID type is not expected to be the domain name of the user, but of the vendor. So it doesn't say anything about the identity of the user or the DHCP client other than perhaps who implemented it. > I also second the idea of an upper limit for the DUID length. An option > is two octets long and the DUID option length can potentially be 64K > long. This is going to impact the server implementation. Either this > will lead to implementations that will put self imposed restrictions on > the length of the DUID or they should be ready to take care of 64K long > DUIDs. I think 256 octets is a reasonable upper bound. That's fine by me. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 17 22:06:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14379; Tue, 17 Jul 2001 22:06:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I273L10596; Tue, 17 Jul 2001 22:07:03 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I26sL01800 for ; Tue, 17 Jul 2001 22:06:54 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA21969; Tue, 17 Jul 2001 22:06:54 -0400 Date: Tue, 17 Jul 2001 22:06:53 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: Server Unicast issue for DHCPv6 -19 Draft In-Reply-To: <66F66129A77AD411B76200508B65AC697B329E@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN geeezzz the text is pretty clear. If the server "ORIGINALLY" got the packet then that means it was on link. Come on .......we need to focus on stuff we missed not argue semantics. my 2cents trying to get this done...... /jim On Tue, 17 Jul 2001, Bernie Volz (EUD) wrote: > Hi: > > One more issue for the -19 draft ... for the "Server Unicast Option" (Section 18.10), > how is the server's Reply sent back to the client? > > The text in 14.4.6 won't work if the client is not on the local link: > > 14.4.6. Sending of Reply messages > > If the Request, Confirm, Renew, Rebind or Release message from > the client was originally received by the server, the server > unicasts the Reply message to the link-local address in the > "client-link-local-address" field. > > If the message was originally received in a Forward-request or > Forward-release message from a relay, the server places the Reply > message in the options field of a Response-reply message and unicasts > the message to the relay's address from the original message. > > I guess the text could be re-written to say: > > If the Request, Confirm, Renew, Rebind, Decline or Release message from > the client was originally received by the server and the IPv6 source address > was a link local address, the server unicasts the Reply message to the > link-local address in the "client-link-local-address" field otherwise it unicasts > it to the IPv6 source address. > > But, that's kind of nasty and complicated (why not simply always send back the > Reply message to the source of the client's message except when relayed). > > Perhaps a better solution is for the client to include a "Reply-Address" option in > the Request, Confirm, Renew, Rebind, Decline or Release message? If the server > is configured to allow this, it would honor it (except when message was received > via a Relay-Forward). > > - Bernie Volz > > From owner-dhcp-v6@bucknell.edu Tue Jul 17 22:18:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15769; Tue, 17 Jul 2001 22:17:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I2IJL01754; Tue, 17 Jul 2001 22:18:19 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6I2I4L28082 for ; Tue, 17 Jul 2001 22:18:04 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6I2Dqf13061 for ; Tue, 17 Jul 2001 19:13:53 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6I2EMA04732 for ; Tue, 17 Jul 2001 19:14:22 -0700 (MST) Message-Id: <200107180214.f6I2EMA04732@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Server Unicast issue for DHCPv6 -19 Draft In-Reply-To: Message from Jim Bound of "Tue, 17 Jul 2001 22:06:53 -0400." Date: Tue, 17 Jul 2001 19:14:22 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > geeezzz the text is pretty clear. If the server "ORIGINALLY" got the > packet then that means it was on link. Come on .......we need to focus on > stuff we missed not argue semantics. In the case of a DHCP Renew, the client could have unicast the message from a different subnet. In the case of the other messages, you are correct. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 17 22:33:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18461; Tue, 17 Jul 2001 22:33:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I2Y3L15304; Tue, 17 Jul 2001 22:34:03 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I2XqL22505 for ; Tue, 17 Jul 2001 22:33:52 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA21290; Tue, 17 Jul 2001 22:33:51 -0400 Date: Tue, 17 Jul 2001 22:33:51 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: <200107172017.f6HKHqP00373@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I thing this is a good idea .... /jim On Tue, 17 Jul 2001, Ted Lemon wrote: > > > I agree that the prefix handling should avoid the need for the > > NACK. There is still an issue of non-address configurations and > > perhaps a general "DHCP Error" option (in a Reply) that can be used > > to communicate problems might be useful. But, it is also something > > that perhaps can be added later (though existing clients would of > > course ignore that option). > > I think this is fine (don't see the new for a new option, unless it's > a text error message), but I think it would be good to have some > verbiage that just says "if the client gets a Wrong Prefix message, it > SHOULD by default give up its existing IAs and go back to the DHCP > Solicit phase, but SHOULD be configurable not to, or something like > that." I am not sure how this situation could come about, as long as > the client is listening to router advertisements, but it worries me, > and I'd like to see it covered. I guess this is something that could > wait for some implementation experience after last call, though. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Tue Jul 17 22:46:08 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20084; Tue, 17 Jul 2001 22:46:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I2kdL05181; Tue, 17 Jul 2001 22:46:39 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I2kWL25052 for ; Tue, 17 Jul 2001 22:46:32 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA23114; Tue, 17 Jul 2001 22:46:31 -0400 Date: Tue, 17 Jul 2001 22:46:30 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNAK for DHCPv6? In-Reply-To: <66F66129A77AD411B76200508B65AC697B32AF@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN sure...any text for a position that has consensus is always welcome. ralph is updating all text and has final say on word smithing though. Do we have consensus on this? /jim On Tue, 17 Jul 2001, Bernie Volz (EUD) wrote: > I'm willing to try to turn this into language for the draft if the authors > are interested. > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Tuesday, July 17, 2001 5:15 PM > To: DHCPv6 discussion list > Subject: Re: DHCPNAK for DHCPv6? > > > > > We need to be careful about what "give up its existing IAs" means. > > > > Consider a mobile node ... perhaps this signals to it that it must > > contact is Home Agent? In which case, it would want to keep the > > (IA) addresses but get new addresses for the local network such that > > it could (hopefully) contact the Home Agent. > > > > Also, consider your laptop. You plug it in at the office and get some > > addresses. You later take it home. You do this 5 days a week. No reason > > your laptop could not hold onto the "old" IAs and try one set first and > > if that isn't accepted, try another. I'm not proposing that it do this > > (likely cheaper to drop old and get new ones), just that it could. A > > smarter implementation could even look at what the Router Advertisement > > contains and match up IAs that it thinks are valid based on the prefixes. > > > > Obviously, the IA isn't valid on that link and thus MUST NOT be used on > > that link. If the client needs addresses, it should go to the Solicit > > phase. > > This is precisely what I was trying to get across, but I phrased it > poorly. Can you turn this into language that could go into the > draft? > > Would the authors accept such language if it were provided? > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Wed Jul 18 00:35:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05552; Wed, 18 Jul 2001 00:35:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I4ZkL06095; Wed, 18 Jul 2001 00:35:46 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6I4ZVL26035 for ; Wed, 18 Jul 2001 00:35:31 -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 f6I4ZVp07257 for ; Tue, 17 Jul 2001 23:35:31 -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 f6I4ZV216864 for ; Tue, 17 Jul 2001 23:35:31 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue Jul 17 23:35:30 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKFLXC>; Tue, 17 Jul 2001 23:35:30 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32B4@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Tue, 17 Jul 2001 23:35:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F43.124DD240" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F43.124DD240 Content-Type: text/plain; charset="iso-8859-1" Yeh, let's go with 256. It definitely is longer than we'll likely ever want, but it's also long enough that it should handle just about anything that comes along. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Tuesday, July 17, 2001 9:48 PM To: DHCPv6 discussion list Subject: Re: Definition of DUID > As far as using domain names in a DUID goes - it can be used in a small > subset of apps. I would expect a lot of the clients implementing DHCPv6 > to obtain their domain name from a DHCP Server as opposed to using a > hard coded domain name built it. This is a seperate issue. The domain name in the VUID DUID type is not expected to be the domain name of the user, but of the vendor. So it doesn't say anything about the identity of the user or the DHCP client other than perhaps who implemented it. > I also second the idea of an upper limit for the DUID length. An option > is two octets long and the DUID option length can potentially be 64K > long. This is going to impact the server implementation. Either this > will lead to implementations that will put self imposed restrictions on > the length of the DUID or they should be ready to take care of 64K long > DUIDs. I think 256 octets is a reasonable upper bound. That's fine by me. _MelloN_ ------_=_NextPart_001_01C10F43.124DD240 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Definition of DUID

Yeh, let's go with 256. It definitely is longer than = we'll likely ever want, but it's also long enough that it should handle = just about anything that comes along.

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Tuesday, July 17, 2001 9:48 PM
To: DHCPv6 discussion list
Subject: Re: Definition of DUID



> As far as using domain names in a DUID goes - it = can be used in a small
> subset of apps. I would expect a lot of the = clients implementing DHCPv6
> to obtain their domain name from a DHCP Server = as opposed to using a
> hard coded domain name built it.

This is a seperate issue.   The domain name = in the VUID DUID type is
not expected to be the domain name of the user, but = of the vendor.
So it doesn't say anything about the identity of the = user or the DHCP
client other than perhaps who implemented it.

> I also second the idea of an upper limit for the = DUID length. An option
> is two octets long and the DUID option length = can potentially be 64K
> long. This is going to impact the server = implementation. Either this
> will lead to implementations that will put self = imposed restrictions on
> the length of the DUID or they should be ready = to take care of 64K long
> DUIDs. I think 256 octets is a reasonable upper = bound.

That's fine by me.

        =         =                _MelloN_

------_=_NextPart_001_01C10F43.124DD240-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 00:35:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05627; Wed, 18 Jul 2001 00:35:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I4YfL07247; Wed, 18 Jul 2001 00:34:41 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6I4YXL12922 for ; Wed, 18 Jul 2001 00:34:33 -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 f6I4YXp07128 for ; Tue, 17 Jul 2001 23:34:33 -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 f6I4YX216744 for ; Tue, 17 Jul 2001 23:34:33 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Tue Jul 17 23:34:32 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKFLWV>; Tue, 17 Jul 2001 23:34:32 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32B3@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Tue, 17 Jul 2001 23:34:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F42.EFBBB940" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F42.EFBBB940 Content-Type: text/plain; charset="iso-8859-1" I think the domain name was supposed to be something burned into the system by the manufacturer (when they burned in the vendor ID). Or, the board (or software) knows the vendor of the NIC or whatever and can simply add the domain name. But, that is an assumption that might not always hold. I suspect that the vendor ID type, while good in concept, won't be used much. - Bernie PS: For US vendors, we could even have them use their EIN (Employer Identification Number)? [Just kidding.] -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@windows.microsoft.com] Sent: Tuesday, July 17, 2001 9:06 PM To: DHCPv6 discussion list Subject: RE: Definition of DUID As far as using domain names in a DUID goes - it can be used in a small subset of apps. I would expect a lot of the clients implementing DHCPv6 to obtain their domain name from a DHCP Server as opposed to using a hard coded domain name built it. Since we expect this way of figuring out the DUID is not very advisable as noted below - is this useful for any set of apps? If it is not useful for a specific set of clients - why not just scrub it from the spec? I also second the idea of an upper limit for the DUID length. An option is two octets long and the DUID option length can potentially be 64K long. This is going to impact the server implementation. Either this will lead to implementations that will put self imposed restrictions on the length of the DUID or they should be ready to take care of 64K long DUIDs. I think 256 octets is a reasonable upper bound. thx -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Tuesday, July 17, 2001 4:18 PM To: DHCPv6 discussion list Subject: RE: Definition of DUID >...there doesn't seem to be a good answer to this one -- on the one hand, we >should encourage vendors to select as short an identifier string as possible >to identify the vendor, but not so long as to be burdensome. Is there any >value to specifying the "domain name" part as an opaque, vendor-selected >octet string (permitting, for example, UTF-8) with the strong suggestion >that it be a (registered) trade-mark, domain name, or legal business name, >but without burdening either IANA or a domain registrar? While domain names could be long, I think they are a reasonable identifier. There could be issues if a domain name used as a vendor id is sold (since the new vendor might have no idea what vendor IDs were used previously). However, mergers and the like don't create problems since if a domain name is switched, the previously shipped devices will continue to use the old values (burned in prom). The combined corporation hopefully knows what values were assigned in the past. The only issue that concerns me with domain names is that its one thing is someone uses nominum.com, but what about subdomains or even internationalized domains. Given that some internationalized domain names might go 3 or 4 levels, each that could be up to 63 characters, the DUID could easily end up at 100s of bytes. I don't have a solution other than to discourage use of this DUID type or, if used, reasonable length domain names are used (dell.com, compaq.com, intel.com, toshiba.com, gateway.com, etc are luckily all fairly short names). Depending on what character set is used for the domain names, another option is to allow something like @ (since @ is an invalid domain name character) - the ID would be in ASCII. Other characters could be used for other identifiers (of course, we could simply define new DUID types as well). Anyway, I think the domain name is a decent solution. Do we want to indicate some maximum limit to the length of the DUID? I'd like there to be one. I had suggested 32 bytes a while ago, but that is too short considering the types. I would recommend we consider something like 128? Perhaps we make this servers MUST be able to support DUIDs up to 128 bytes (longer ones would be truncated under the assumption that the first 128 bytes is unique). I'm open for other suggested maximum lengths (64, 256). - Bernie Volz -----Original Message----- From: Barr Hibbs [ mailto:Barr.Hibbs@Nominum.com ] Sent: Tuesday, July 17, 2001 6:36 PM To: DHCPv6 discussion list Subject: RE: Definition of DUID my responses are inline... --Barr > > Also, given that we can reasonably expect to be moving very > soon to 64-bit > > time values, is a four-octet value an appropriate choice? > > Yes. I would say a two-octet value would be fine, frankly. There's > no need to add an extra four bytes to the identifier, and keeping it > small is a virtue. The time from the beginning to the end of the > epoch is long enough that the likelihood of a collision caused by this > particular problem seems remote. :') > ...agreed, 68 years does seem long enough... but I thought I should ask.... > > ... this assumes that the link-layer address lengths are > well-known, which > > I'm not quite sure is universally correct. While most of us know that > > Ethernet addresses are 48-bits, how many of us know the length of every > > other hardware address? I would propose generalizing this by adding a > > length octet immediately following the hardware type. > > That's not necessary. We already know how long the DUID is, because > it's an option. > ...oops! forgot that! > > ... given that domain names are changed as frequently as corporate > > identity makeovers or marketing department changes of direction I'd like > > some other sort of "registered" identify, but I'm not sure what > to propose > > in place of domain name. > > That's just it. We can't make the IANA do it. Short of that, making > the domain registrars do it seems like the easiest thing. I can > definitely conceive of this becoming a problem once in a while, but > it's a problem that the manufacturer will have some interest in > avoiding, so I'm not *too* worried about it. > ...there doesn't seem to be a good answer to this one -- on the one hand, we should encourage vendors to select as short an identifier string as possible to identify the vendor, but not so long as to be burdensome. Is there any value to specifying the "domain name" part as an opaque, vendor-selected octet string (permitting, for example, UTF-8) with the strong suggestion that it be a (registered) trade-mark, domain name, or legal business name, but without burdening either IANA or a domain registrar? > > Is an 8-octet identifier sufficient as the number of > networked devices > > increases? > > There aren't that many atoms in the universe, so yes, I think this > will do. :') > ...so much for my knowledge of cosmology! > > ... would the vendor ID include some numeric encoding of the vendor's > > identity, or is it intended that the domain name portion do > that, leaving > > VUID to be, essentially, an equipment serial number? If the vendor's > > identity is encoded in the VUID then registration/assignment of > vendor IDs > > become a task for IANA, would we expand the IEEE codes as used > in Ethernet > > addresses, or use some other identifier that is widely available such as > > SIC/NMIC? > > This is precisely what I am trying to avoid by using the domain name. > ...good point ------_=_NextPart_001_01C10F42.EFBBB940 Content-Type: text/html; charset="iso-8859-1" RE: Definition of DUID
I think the domain name was supposed to be something burned into the system by the manufacturer (when they burned in the vendor ID). Or, the board (or software) knows the vendor of the NIC or whatever and can simply add the domain name. But, that is an assumption that might not always hold.
 
I suspect that the vendor ID type, while good in concept, won't be used much.
 
- Bernie
 
PS: For US vendors, we could even have them use their EIN (Employer Identification Number)? [Just kidding.]
-----Original Message-----
From: Thirumalesh Bhat [mailto:thirub@windows.microsoft.com]
Sent: Tuesday, July 17, 2001 9:06 PM
To: DHCPv6 discussion list
Subject: RE: Definition of DUID

As far as using domain names in a DUID goes – it can be used in a small subset of apps. I would expect a lot of the clients implementing DHCPv6 to obtain their domain name from a DHCP Server as opposed to using a hard coded domain name built it. Since we expect this way of figuring out the DUID is not very advisable as noted below – is this useful for any set of apps? If it is not useful for a specific set of clients – why not just scrub it from the spec?

 

I also second the idea of an upper limit for the DUID length. An option is two octets long and the DUID option length can potentially be 64K long. This is going to impact the server implementation. Either this will lead to implementations that will put self imposed restrictions on the length of the DUID or they should be ready to take care of 64K long DUIDs. I think 256 octets is a reasonable upper bound.

 

thx

 

-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Tuesday, July 17, 2001 4:18 PM
To: DHCPv6 discussion list
Subject: RE: Definition of DUID

 

>...there doesn't seem to be a good answer to this one -- on the one hand, we
>should encourage vendors to select as short an identifier string as possible
>to identify the vendor, but not so long as to be burdensome.  Is there any
>value to specifying the "domain name" part as an opaque, vendor-selected
>octet string (permitting, for example, UTF-8) with the strong suggestion
>that it be a (registered) trade-mark, domain name, or legal business name,
>but without burdening either IANA or a domain registrar?

While domain names could be long, I think they are a reasonable identifier.
There could be issues if a domain name used as a vendor id is sold (since the
new vendor might have no idea what vendor IDs were used previously). However,
mergers and the like don't create problems since if a domain name is switched,
the previously shipped devices will continue to use the old values (burned in
prom). The combined corporation hopefully knows what values were assigned in
the past.

The only issue that concerns me with domain names is that its one thing is
someone uses nominum.com, but what about subdomains or even internationalized
domains. Given that some internationalized domain names might go 3 or 4 levels,
each that could be up to 63 characters, the DUID could easily end up at 100s
of bytes.

I don't have a solution other than to discourage use of this DUID type or, if
used, reasonable length domain names are used (dell.com, compaq.com, intel.com,
toshiba.com, gateway.com, etc are luckily all fairly short names).

Depending on what character set is used for the domain names, another option
is to allow something like @<SNMP-Enterprise-ID> (since @ is an invalid domain
name character) - the ID would be in ASCII. Other characters could be used for
other identifiers (of course, we could simply define new DUID types as well).

Anyway, I think the domain name is a decent solution.

 

Do we want to indicate some maximum limit to the length of the DUID? I'd like
there to be one. I had suggested 32 bytes a while ago, but that is too short
considering the types. I would recommend we consider something like 128? Perhaps
we make this servers MUST be able to support DUIDs up to 128 bytes (longer
ones would be truncated under the assumption that the first 128 bytes is unique).

I'm open for other suggested maximum lengths (64, 256).

- Bernie Volz

-----Original Message-----
From: Barr Hibbs [mailto:Barr.Hibbs@Nominum.com]
Sent: Tuesday, July 17, 2001 6:36 PM
To: DHCPv6 discussion list
Subject: RE: Definition of DUID

 

my responses are inline...

--Barr

 

> > Also, given that we can reasonably expect to be moving very
> soon to 64-bit
> > time values, is a four-octet value an appropriate choice?
>
> Yes.   I would say a two-octet value would be fine, frankly.   There's
> no need to add an extra four bytes to the identifier, and keeping it
> small is a virtue.   The time from the beginning to the end of the
> epoch is long enough that the likelihood of a collision caused by this
> particular problem seems remote.   :')
>
...agreed, 68 years does seem long enough...  but I thought I should ask....

 

> > ...   this assumes that the link-layer address lengths are
> well-known, which
> > I'm not quite sure is universally correct.  While most of us know that
> > Ethernet addresses are 48-bits, how many of us know the length of every
> > other hardware address?  I would propose generalizing this by adding a
> > length  octet immediately following the hardware type.
>
> That's not necessary.   We already know how long the DUID is, because
> it's an option.
>
...oops!  forgot that!

 

> > ...   given that domain names are changed as frequently as corporate
> > identity makeovers or marketing department changes of direction I'd like
> > some other sort of "registered" identify, but I'm not sure what
> to propose
> > in place of domain name.
>
> That's just it.  We can't make the IANA do it.  Short of that, making
> the domain registrars do it seems like the easiest thing.  I can
> definitely conceive of this becoming a problem once in a while, but
> it's a problem that the manufacturer will have some interest in
> avoiding, so I'm not *too* worried about it.
>
...there doesn't seem to be a good answer to this one -- on the one hand, we
should encourage vendors to select as short an identifier string as possible
to identify the vendor, but not so long as to be burdensome.  Is there any
value to specifying the "domain name" part as an opaque, vendor-selected
octet string (permitting, for example, UTF-8) with the strong suggestion
that it be a (registered) trade-mark, domain name, or legal business name,
but without burdening either IANA or a domain registrar?

 

> >       Is an 8-octet identifier sufficient as the number of
> networked devices
> > increases?
>
> There aren't that many atoms in the universe, so yes, I think this
> will do.   :')
>
...so much for my knowledge of cosmology!

 

> > ...   would the vendor ID include some numeric encoding of the vendor's
> > identity, or is it intended that the domain name portion do
> that, leaving
> > VUID to be, essentially, an equipment serial number?  If the vendor's
> > identity is encoded in the VUID then registration/assignment of
> vendor IDs
> > become a task for IANA, would we expand the IEEE codes as used
> in Ethernet
> > addresses, or use some other identifier that is widely available such as
> > SIC/NMIC?
>
> This is precisely what I am trying to avoid by using the domain name.
>
...good point

------_=_NextPart_001_01C10F42.EFBBB940-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 01:17:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15554; Wed, 18 Jul 2001 01:17:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I5HdL01008; Wed, 18 Jul 2001 01:17:39 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6I5HQL05490 for ; Wed, 18 Jul 2001 01:17:26 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6I5DFf13251 for ; Tue, 17 Jul 2001 22:13:15 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6I5DWA04866 for ; Tue, 17 Jul 2001 22:13:32 -0700 (MST) Message-Id: <200107180513.f6I5DWA04866@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNAK for DHCPv6? In-Reply-To: Message from Jim Bound of "Tue, 17 Jul 2001 22:46:30 -0400." Date: Tue, 17 Jul 2001 22:13:32 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Do we have consensus on this? I don't think we have a precise definition of 'this' yet, but we're closing in on one, and I don't hear any dissent on the idea that we should come up with one and include it. :'} _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 02:42:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16167; Wed, 18 Jul 2001 02:42:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I6gEL21879; Wed, 18 Jul 2001 02:42:14 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6I6gAL06530 for ; Wed, 18 Jul 2001 02:42:10 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6I6buf13347 for ; Tue, 17 Jul 2001 23:37:56 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6I6c7A04916 for ; Tue, 17 Jul 2001 23:38:07 -0700 (MST) Message-Id: <200107180638.f6I6c7A04916@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Definition of DUID In-Reply-To: Message from "Bernie Volz (EUD)" of "Tue, 17 Jul 2001 23:34:30 EST." <66F66129A77AD411B76200508B65AC697B32B3@eambunt705.ena-east.ericsson.se> Date: Tue, 17 Jul 2001 23:38:07 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Or, the board (or software) knows the vendor of the NIC or whatever > and can simply add the domain name. But, that is an assumption that > might not always hold. This is not at all what is intended! That's why there are special DUID types for both possible uses of the link-layer address, with very explicit MUSTs and MUST NOTs. Based on what you've said, perhaps we should add this: The structure of the VUID is left up to the vendor defining it, but each device containing such a VUID MUST be unique to each device that is using it, and MUST be assigned to the device at the time of manufacture and stored in some form of non-volatile - storage. The VUID SHOULD be recorded in non-erasable storage. + storage. The VUID MUST NOT be the link-layer of a network + interface. The VUID SHOULD be recorded in non-erasable storage. The domain name is simply any domain name that has been legally _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 05:01:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02325; Wed, 18 Jul 2001 05:01:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6I91gL23358; Wed, 18 Jul 2001 05:01:42 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6I91dL20265 for ; Wed, 18 Jul 2001 05:01:39 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id CAA13695 for ; Wed, 18 Jul 2001 02:01:39 -0700 (MST)] Received: [from m-il06-r2.mot.com (m-il06-r2.mot.com [129.188.137.24]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id CAA06077 for ; Wed, 18 Jul 2001 02:01:38 -0700 (MST)] Received: from [140.101.173.9] by m-il06-r2.mot.com with ESMTP for dhcp-v6@bucknell.edu; Wed, 18 Jul 2001 04:00:58 -0500 Received: (from root@localhost) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id LAA14661 for dhcp-v6@bucknell.edu.DELIVER; Wed, 18 Jul 2001 11:01:04 +0200 (METDST) Received: from ZFR030101 (zfr03-0102.crm.mot.com [140.101.173.168]) by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with SMTP id LAA14592 for ; Wed, 18 Jul 2001 11:01:03 +0200 (METDST) Message-Id: <001f01c10f68$2918ef80$a8ad658c@ZFR030101> From: "Jerome Labussiere" To: DHCPv6 discussion list References: <200107180638.f6I6c7A04916@grosse.bisbee.fugue.com> Subject: Re: Definition of DUID Date: Wed, 18 Jul 2001 11:00:58 +0200 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.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello What do you think of the solution defined in COPS (http://www.ietf.org/rfc/rfc2748.txt section 2.2.11) ? > Variable-length field. It is a NULL terminated ASCII string that is > also zero padded to a 32-bit word boundary (so the object length is a > multiple of 4 octets). The PEPID MUST contain an ASCII string that > uniquely identifies the PEP within the policy domain in a manner that > is persistent across PEP reboots. For example, it may be the PEP's > statically assigned IP address or DNS name. This identifier may > safely be used by a PDP as a handle for identifying the PEP in its > policy rules. Maybe the DUID should not be globally-unique but simply unique within the administrative domain (and configurable on the client) As the format of the DUID was not defined, I tried this in a modest implementation of rev-18 and it was very flexible and easy to implement. I used NAI (ftp://ftp.isi.edu/in-notes/rfc2486.txt) to identify clients. If the NAI "realm" is local, I used a LDAP repository, if not, it is possible to send a request to an AAA infrastructure (using the realm to route the request). Actually, I think it is also possible to map authentification of DHCP messages on identification/authentification of clients in a generic way. From owner-dhcp-v4@bucknell.edu Wed Jul 18 07:00:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26337 for ; Wed, 18 Jul 2001 07:00:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IAvrL08449; Wed, 18 Jul 2001 06:57:54 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IAvkL00886 for ; Wed, 18 Jul 2001 06:57:48 -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 GAA24655; Wed, 18 Jul 2001 06:56:52 -0400 (EDT) Message-Id: <200107181056.GAA24655@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-vpn-option-00.txt Date: Wed, 18 Jul 2001 06:56:51 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP VPN Information option Author(s) : K. Kinnear et al. Filename : draft-ietf-dhc-vpn-option-00.txt Pages : 6 Date : 17-Jul-01 This memo defines a new DHCP option for passing VPN information between the DHCP client and the DHCP server. It is intended for use primarily by DHCP proxy clients in situations where VPN information needs to be passed to the DHCP server for proper address allocation to take place. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-00.txt 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-vpn-option-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-vpn-option-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010717132753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-vpn-option-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-vpn-option-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132753.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 07:01:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26753; Wed, 18 Jul 2001 07:01:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IB1uL27976; Wed, 18 Jul 2001 07:01:56 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IB1eL32259 for ; Wed, 18 Jul 2001 07:01:40 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-4.cisco.com [10.21.96.4]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA25335 for ; Wed, 18 Jul 2001 07:01:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20010718064217.00b597e8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jul 2001 07:00:06 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Rules for message transmission and retransmission Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted suggests that the spec define a single set of rules for message transmission and retransmission, and then alter the definition of client behavior for each message to refer to that definition. I've included the new text for transmission and retransmission below, along with an example of how the text for the Solicit message would refer to that new text. Note that the Solicit message also includes new text describing the client behvaior in the case that it receives no responses to its Solicit message. Please reply to the mailing list with your comments about this new text. I'm going to cut off discussion of this issue Thursday (7/19) afternoon at 2PM EDT. Jim and I plan to publish the -20 rev of the draft before the London IETF deadline, and we'll need time to make the final edits to the draft. - Ralph 12-1/2. Retransmission of Messages. (To be inserted between existing sections 12 and 13) The UDP protocol does not provide a reliable mechanism for datagram delivery. In some cases it is therefore necessary to retransmit packets. An initiator of a protocol exchange must therefore wait for some period of time after transmitting a message and, if no reply is received, retransmit that message. Rather than specify retransmission behaviour for each individual case where retransmission may be called for, we specify it here. Please note that this retransmission algorithm MUST NOT be applied except in cases where it is specifically called for. It is not the case that all packets are retransmitted. Retransmission behaviour is controlled by between two and four variables. All retransmission algorithms have an initial retransmission time (IRT). In some cases a maximum retry count (MRC), maximum retry time (MRT), and/or maximum retry duration (MRD), may also be specified. These three letter acronyms will be used later in this document when we refer to this section. When an initial transmission occurs, the transmitting agent sets the retransmission timout (RT) value to IRT plus the product of a random quantity between -1/10 and 1/10 multiplied by IRT: RT = IRT + (rnd (-0.1, 0.1) * IRT). On each subsequent transmission, the retransmission timeout is set to the previous retransmission timeout multiplied by two plus the a randomly chosen number between -1/10 and 1/10 multiplied by of the previous retransmission timeout: RT' = (RT * 2) + (rnd (-0.1, 0.1) * RT) If MRT is defined and the new retransmission timeout is greater than MRT, it is set to MRT multiplied by a randomly chosen number between 9/10 and 1 1/10: if (RT' > MRT) RT' = MRT * rnd (0.9, 1.1) Unless otherwise specified, when a response is received to a transmission, the retransmission process MUST be immediately terminated. If MRC is defined and the packet has been transmitted MRC times, the retransmission process MUST be terminated, except that if MRC is -1, the retransmission process MUST continue until a response is received. If MRD is defined and that many seconds have elapsed since the first message was transmitted, the retransmission process MUST also terminate. The algorithm used to choose a random number does not need to be cryptographically sound, but it SHOULD produce a different sequence of numbers on each invocation of the DHCP client. The element of randomness prevents similar client implementations from getting into lock-step. When computing timeouts, the computation MUST be done in such a way that it is accurate to at least the nearest millisecond, and when processing timeouts, at least the same degree of accuracy SHOULD be used. In any case, timeout processing MUST be accurate to at least 500 milliseconds. ===== (Replacement text for existing section 13.3.2) 13.3.2. Time out and retransmission of Solicit Messages The client's first Solicit message on the interface MUST be delayed by a random amount of time between the interval of MIN_SOL_DELAY and MAX_SOL_DELAY. This random delay desynchronizes clients which start at the same time (e.g., after a power outage). The client then uses the retransmission algorithm described in 12a, using ADV_MSG_TIMEOUT for IRT, ADV_MSG_MAX for MRT, and SOL_MAX_ATTEMPTS for MRC. Receipt of an Advertise message prior to ADV_MSG_TIMEOUT does not terminate the retransmission process - the client will continue to listen for advertise messages until ADV_SEL_TIMEOUT has expired. A retransmission MUST NOT be scheduled for the same time that ADV_SEL_TIMEOUT will expire. After SOL_MAX_ATTEMPTS attempts have been made, the client MUST stop trying to configure the interface using DHCP. When the client has stopped trying to configure the interface, it SHOULD NOT try again to configure the interface unless some external event occurs. Examples of external events include but are not limited to user-initiated events, system reboots, and the client being connected to a new network link. Unless there is some reason to do otherwise, DHCP clients SHOULD be configured with SOL_MAX_ATTEMPTS at -1 by default, so that the client never stops attempting to configure the interface. [Note: I can see why it must be necessary for the client to give up in some extreme cases, but from an operational perspective on a normal network, this would be a disaster, so I've tried to wordsmith the above language to make it glaringly obvious that it is the exception rather than the rule that clients should stop trying to configure the interface. Also, the language that allowed the client to continue retransmitting after SOL_MAX_ATTEMPTS expired doesn't make sense - if you want that behaviour, why not just set SOL_MAX_ATTEMPTS to -1?] If the client detects that it has moved to a new link (see section 14.3.2 for examples of when this can occur) the client MUST restart the server solicitation process. Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5. From owner-dhcp-v4@bucknell.edu Wed Jul 18 07:01:43 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26866 for ; Wed, 18 Jul 2001 07:01:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IB1XL30727; Wed, 18 Jul 2001 07:01:33 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IAvpL21519 for ; Wed, 18 Jul 2001 06:57:51 -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 GAA24685; Wed, 18 Jul 2001 06:56:57 -0400 (EDT) Message-Id: <200107181056.GAA24685@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-agent-subnet-selection-00.txt Date: Wed, 18 Jul 2001 06:56:57 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 : Subnet Selection sub-option for the Relay Agent Information Option Author(s) : K. Kinnear et al. Filename : draft-ietf-dhc-agent-subnet-selection-00.txt Pages : 7 Date : 17-Jul-01 In RFC2131, the giaddr specifies both the subnet on which a DHCP client resides as well as an IP address which can be used to communicate with the relay agent. The subnet selection option [RFC 3011] allows these functions of the giaddr to be split so that when one entity is performing as a DHCP proxy, it can specify the subnet from which to allocate an IP address which is different from the IP address with which it desires to communicate with the DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-subnet-selection-00.txt 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-agent-subnet-selection-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-subnet-selection-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010717132813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-subnet-selection-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-subnet-selection-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132813.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Wed Jul 18 07:03:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA27575 for ; Wed, 18 Jul 2001 07:03:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IB3AL14760; Wed, 18 Jul 2001 07:03:10 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IAvvL06916 for ; Wed, 18 Jul 2001 06:57: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 GAA24701; Wed, 18 Jul 2001 06:57:02 -0400 (EDT) Message-Id: <200107181057.GAA24701@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-agent-vpn-id-00.txt Date: Wed, 18 Jul 2001 06:57:02 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 : VPN Identifier sub-option for the Relay Agent Information Option Author(s) : K. Kinnear et al. Filename : draft-ietf-dhc-agent-vpn-id-00.txt Pages : 7 Date : 17-Jul-01 In some environments, a relay agent resides in a network element which also has access to one or more VPNs. If one DHCP server wishes to offer service to DHCP clients on those different VPNs the DHCP server needs to know the VPN on which each client resides. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-00.txt 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-agent-vpn-id-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010717132824.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-vpn-id-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010717132824.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 09:45:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24646; Wed, 18 Jul 2001 09:44:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IDipL16369; Wed, 18 Jul 2001 09:44:51 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IDiiL16624 for ; Wed, 18 Jul 2001 09:44:44 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA06992 for ; Wed, 18 Jul 2001 09:44:28 -0400 (EDT) Message-Id: <4.3.2.7.2.20010718070602.00b291c8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jul 2001 09:43:13 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Simplify release and decline of addresses Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted suggests a simplification: requiring that all the addresses in an IA be released or declined, rather than just some of those addresses. Ted also wrote text describing the server behavior in response to a Decline message (which is missing from the -19 rev). - Ralph 14.4.5. Receipt of Release messages Upon the receipt of a valid Release message, the server examines the IAs and the addresses in the IAs for validity. If the IAs in the message are in a binding for the client and the addresses in the IAs have been assigned by the server to those IA, the server deletes the addresses from the IAs and makes the addresses available for assignment to other clients. [IMHO, this is too complicated. I think the client should always release all addresses in an IA - that is, it should just send an empty IA as described below. Otherwise you get into complexities about how to back out of an erroneous transaction that I think can't be solved.] 14.4.5-1/2. Receipt of Decline messages (To be inserted after existing section 14.4.5 in -19 rev) Upon the receipt of a valid Decline message, the server examines the IAs and the addresses in the IAs for validity. If any IA in the message is not an IA that has been assigned by the server to that client, or if any addresses are mentioned in an IA that were not assigned by the server to the client, the server MUST NOT further process the message, but should send a Reply message indicating a NoBinding status. For each IA in the message, if there are any addresses mentioned in that IA, the server SHOULD mark each of these addresses as in conflict and SHOULD NOT make these addresses available for allocation to other clients. Any addresses that the server has allocated to that IA but that are not mentioned in the message SHOULD be made available for assignment to other clients. [As above, I would argue that the client should simply send empty IAs, and let all the addresses be declined. This has the disadvantage that you can lose addresses that were not in conflict, but it makes the whole transaction a lot simpler, and I think simplicity is a real virtue in this case.] If an IA is mentioned in the Decline message without any accompanying addresses, the server SHOULD mark all the addresses in the IA as being in conflict, and SHOULD NOT make these addresses available for immediate assignment to other clients. Server implementors SHOULD implement a strategy for reclaiming these IP addresses if there are no addresses available for allocation. Server implementors MAY also implement a strategy to detect a client that is repeatedly allocating and then declining addresses. When such a client is detected, the server SHOULD refuse to allocate further addresses to that client for DECLINE_COOLOFF (see section 7.5) seconds. The server then generates a Reply message. If all of the IAs were valid, the server sets the "status" field to "Success". If any of the IAs were invalid, the server sets the "status" field to "NoBinding" (section 7.4). From owner-dhcp-v6@bucknell.edu Wed Jul 18 09:55:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27279; Wed, 18 Jul 2001 09:55:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IDtBL28335; Wed, 18 Jul 2001 09:55:11 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IDt0L03447 for ; Wed, 18 Jul 2001 09:55:00 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA08242 for ; Wed, 18 Jul 2001 09:54:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20010718065906.039d8498@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 18 Jul 2001 09:53:30 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Circuit ID and Remote ID options Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted has drafted text for the Circuit ID and Remote ID options, which are to be used between relay agents and servers. Two questions: is the text OK and do we want to include the text in the base protocol spec? I'm inclined not to include these two options in the base spec. Instead, I suggest that they, along with other options we know we'll need real soon but are not referenced elsewhere in the base spec, be moved to separate drafts for consideration in parallel with the base spec I-D. - Ralph 18.13 Circuit ID Option This option MAY be placed in Relay-forward messages by DHCP relay agents which terminate switched or permanent circuits. It encodes an agent-local identifier of the circuit on which a DHCP client-to-server packet was received. It is intended for use by relay agents in relaying DHCP responses back to the proper circuit. Possible values encoded in this field include: - Router interface number - Switching Hub port number - Remote Access Server port number - Frame Relay DLCI - ATM virtual circuit number - Cable Data virtual circuit number Servers MAY use the Circuit ID when making address allocation decisions and in applying other parameter assignment policies. The Circuit ID SHOULD be considered an opaque value, with policies based on exact string match only; that is, the Circuit ID SHOULD NOT be internally parsed by the server. Servers MUST return the Circuit ID option in the Relay-reply message that is generated in response to a Relay-forward message if this option appears in the Relay-forward message. Since the Circuit ID is local only to a particular relay agent, a circuit ID should be qualified with the giaddr value that identifies the relay agent. 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_CIRCUIT_ID | option_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . circuit ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This corresponds to the DHCPv4 Circuit ID subpoption as described in [24]. 18.14 Remote ID Option This option MAY be sent in Relay-forward messages by DHCP relay agents which terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. The Remote ID field may be used to encode, for instance: -- a "caller ID" telephone number for dial-up connection -- a "user name" prompted for by a Remote Access Server -- a remote caller ATM address -- a "modem ID" of a cable data modem -- the remote IP address of a point-to-point link -- a remote X.25 address for X.25 connections The remote ID MUST be globally unique. DHCP servers MAY use this option to select parameters specific to particular users, hosts, or subscriber modems. The option SHOULD be considered an opaque value, with policies based on exact string match only; that is, the option SHOULD NOT be internally parsed by the server. Servers MUST return the Circuit ID option in the Relay-reply message that is generated in response to a Relay-forward message if this option appears in the Relay-forward message. The relay agent MAY use this field to select the circuit on which to forward a DHCP reply 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_REMOTE_ID | option_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . remote ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This corresponds to the DHCPv4 Remote ID subpoption as described in [24]. From owner-dhcp-v6@bucknell.edu Wed Jul 18 10:08:56 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00018; Wed, 18 Jul 2001 10:08:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IE8sL12366; Wed, 18 Jul 2001 10:08:54 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IE8hL21688 for ; Wed, 18 Jul 2001 10:08:44 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6IE8S528377 for ; Wed, 18 Jul 2001 09:08:28 -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 f6IE8SY24418 for ; Wed, 18 Jul 2001 09:08:28 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Jul 18 09:08:21 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP29GYT>; Wed, 18 Jul 2001 09:08:21 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32B6@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Rules for message transmission and retransmission Date: Wed, 18 Jul 2001 09:08:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F93.170CD290" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F93.170CD290 Content-Type: text/plain; charset="iso-8859-1" Ralph: This looks pretty good. One statement that we might want to modify slightly is "In any case, timeout processing MUST be accurate to at least 500 milliseconds." As few operating systems are truely real-time (this is probably more of a semantics issue), it may not be possible to honor this requirement. I know what you want, but am not sure how to say it better so perhaps it is a non-issue. It would be nice if we had a similar sections on sending (transmission) of messages, for example: x.x Client Message Transmission The client MAY transmit messages to a server directly if it has an address of sufficient scope to communicate with the server and the server has previously communicated to the client that it is allowed to do so via the Server unicast option (Section 18.10). Otherwise, the client MUST transmit all of its messages to the All DHCP Agents multicast address. The client MUST transmit all messages to destination port 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. x.x Server Message Transmission If a response (Advertise or Reply) message to a client is being sent: 1. If the client's message was received in a Relay-forward message, the server MUST transmit a Relay-reply message with the response message in the payload of a "server-message" option and unicast the Relay-reply to the address in the "relay-address" field from the Relay-forward message. 2. Otherwise, the server MUST unicast the response message directly to the client through the interface on which the client's message was received using the "client-link-local-address" field value as the destination address. If the server is sending an unsolicited message to a client (such as Reconfigure-Init), it MUST unicast the message directly to the client using an address of sufficient scope to reach the client. The server MUST transmit all messages to destination port 546. The source port selection can be arbitrary, although it SHOULD be possible using a server configuration facility to set a specific source port value. [A section on Relay Message Transmission is not needed as Section 16 already covers this behavoir well (and there are only two cases and they are vastly different).] - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, July 18, 2001 7:00 AM To: DHCPv6 discussion list Subject: Rules for message transmission and retransmission Ted suggests that the spec define a single set of rules for message transmission and retransmission, and then alter the definition of client behavior for each message to refer to that definition. I've included the new text for transmission and retransmission below, along with an example of how the text for the Solicit message would refer to that new text. Note that the Solicit message also includes new text describing the client behvaior in the case that it receives no responses to its Solicit message. Please reply to the mailing list with your comments about this new text. I'm going to cut off discussion of this issue Thursday (7/19) afternoon at 2PM EDT. Jim and I plan to publish the -20 rev of the draft before the London IETF deadline, and we'll need time to make the final edits to the draft. - Ralph 12-1/2. Retransmission of Messages. (To be inserted between existing sections 12 and 13) The UDP protocol does not provide a reliable mechanism for datagram delivery. In some cases it is therefore necessary to retransmit packets. An initiator of a protocol exchange must therefore wait for some period of time after transmitting a message and, if no reply is received, retransmit that message. Rather than specify retransmission behaviour for each individual case where retransmission may be called for, we specify it here. Please note that this retransmission algorithm MUST NOT be applied except in cases where it is specifically called for. It is not the case that all packets are retransmitted. Retransmission behaviour is controlled by between two and four variables. All retransmission algorithms have an initial retransmission time (IRT). In some cases a maximum retry count (MRC), maximum retry time (MRT), and/or maximum retry duration (MRD), may also be specified. These three letter acronyms will be used later in this document when we refer to this section. When an initial transmission occurs, the transmitting agent sets the retransmission timout (RT) value to IRT plus the product of a random quantity between -1/10 and 1/10 multiplied by IRT: RT = IRT + (rnd (-0.1, 0.1) * IRT). On each subsequent transmission, the retransmission timeout is set to the previous retransmission timeout multiplied by two plus the a randomly chosen number between -1/10 and 1/10 multiplied by of the previous retransmission timeout: RT' = (RT * 2) + (rnd (-0.1, 0.1) * RT) If MRT is defined and the new retransmission timeout is greater than MRT, it is set to MRT multiplied by a randomly chosen number between 9/10 and 1 1/10: if (RT' > MRT) RT' = MRT * rnd (0.9, 1.1) Unless otherwise specified, when a response is received to a transmission, the retransmission process MUST be immediately terminated. If MRC is defined and the packet has been transmitted MRC times, the retransmission process MUST be terminated, except that if MRC is -1, the retransmission process MUST continue until a response is received. If MRD is defined and that many seconds have elapsed since the first message was transmitted, the retransmission process MUST also terminate. The algorithm used to choose a random number does not need to be cryptographically sound, but it SHOULD produce a different sequence of numbers on each invocation of the DHCP client. The element of randomness prevents similar client implementations from getting into lock-step. When computing timeouts, the computation MUST be done in such a way that it is accurate to at least the nearest millisecond, and when processing timeouts, at least the same degree of accuracy SHOULD be used. In any case, timeout processing MUST be accurate to at least 500 milliseconds. ===== (Replacement text for existing section 13.3.2) 13.3.2. Time out and retransmission of Solicit Messages The client's first Solicit message on the interface MUST be delayed by a random amount of time between the interval of MIN_SOL_DELAY and MAX_SOL_DELAY. This random delay desynchronizes clients which start at the same time (e.g., after a power outage). The client then uses the retransmission algorithm described in 12a, using ADV_MSG_TIMEOUT for IRT, ADV_MSG_MAX for MRT, and SOL_MAX_ATTEMPTS for MRC. Receipt of an Advertise message prior to ADV_MSG_TIMEOUT does not terminate the retransmission process - the client will continue to listen for advertise messages until ADV_SEL_TIMEOUT has expired. A retransmission MUST NOT be scheduled for the same time that ADV_SEL_TIMEOUT will expire. After SOL_MAX_ATTEMPTS attempts have been made, the client MUST stop trying to configure the interface using DHCP. When the client has stopped trying to configure the interface, it SHOULD NOT try again to configure the interface unless some external event occurs. Examples of external events include but are not limited to user-initiated events, system reboots, and the client being connected to a new network link. Unless there is some reason to do otherwise, DHCP clients SHOULD be configured with SOL_MAX_ATTEMPTS at -1 by default, so that the client never stops attempting to configure the interface. [Note: I can see why it must be necessary for the client to give up in some extreme cases, but from an operational perspective on a normal network, this would be a disaster, so I've tried to wordsmith the above language to make it glaringly obvious that it is the exception rather than the rule that clients should stop trying to configure the interface. Also, the language that allowed the client to continue retransmitting after SOL_MAX_ATTEMPTS expired doesn't make sense - if you want that behaviour, why not just set SOL_MAX_ATTEMPTS to -1?] If the client detects that it has moved to a new link (see section 14.3.2 for examples of when this can occur) the client MUST restart the server solicitation process. Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5. ------_=_NextPart_001_01C10F93.170CD290 Content-Type: text/html; charset="iso-8859-1" RE: Rules for message transmission and retransmission

Ralph:

This looks pretty good.

One statement that we might want to modify slightly is "In any case, timeout
processing MUST be accurate to at least 500 milliseconds." As few operating
systems are truely real-time (this is probably more of a semantics issue),
it may not be possible to honor this requirement. I know what you want, but
am not sure how to say it better so perhaps it is a non-issue.


It would be nice if we had a similar sections on sending (transmission) of
messages, for example:

x.x Client Message Transmission

The client MAY transmit messages to a server directly if it has an address
of sufficient scope to communicate with the server and the server has
previously communicated to the client that it is allowed to do so via
the Server unicast option (Section 18.10). Otherwise, the client MUST
transmit all of its messages to the All DHCP Agents multicast address.

The client MUST transmit all messages to destination port 547.

The source port selection can be arbitrary, although it SHOULD be possible
using a client configuration facility to set a specific source port value.

x.x Server Message Transmission

If a response (Advertise or Reply) message to a client is being sent:
1. If the client's message was received in a Relay-forward message, the
server MUST transmit a Relay-reply message with the response message in
the payload of a "server-message" option and unicast the Relay-reply to
the address in the "relay-address" field from the Relay-forward message.
2. Otherwise, the server MUST unicast the response message directly to the
client through the interface on which the client's message was received
using the "client-link-local-address" field value as the destination
address.

If the server is sending an unsolicited message to a client (such as
Reconfigure-Init), it MUST unicast the message directly to the client
using an address of sufficient scope to reach the client.

The server MUST transmit all messages to destination port 546.

The source port selection can be arbitrary, although it SHOULD be possible
using a server configuration facility to set a specific source port value.


[A section on Relay Message Transmission is not needed as Section 16 already
covers this behavoir well (and there are only two cases and they are vastly
different).]

- Bernie


-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, July 18, 2001 7:00 AM
To: DHCPv6 discussion list
Subject: Rules for message transmission and retransmission



Ted suggests that the spec define a single set of rules for message
transmission and retransmission, and then alter the definition of client
behavior for each message to refer to that definition.  I've included the
new text for transmission and retransmission below, along with an example
of how the text for the Solicit message would refer to that new text.  Note
that the Solicit message also includes new text describing the client
behvaior in the case that it receives no responses to its Solicit message.

Please reply to the mailing list with your comments about this new
text.  I'm going to cut off discussion of this issue Thursday (7/19)
afternoon at 2PM EDT.  Jim and I plan to publish the -20 rev of the draft
before the London IETF deadline, and we'll need time to make the final
edits to the draft.

- Ralph


12-1/2. Retransmission of Messages. (To be inserted between existing
                                      sections 12 and 13)

    The UDP protocol does not provide a reliable mechanism for datagram
    delivery.  In some cases it is therefore necessary to retransmit
    packets.  An initiator of a protocol exchange must therefore wait
    for some period of time after transmitting a message and, if no
    reply is received, retransmit that message.

    Rather than specify retransmission behaviour for each individual
    case where retransmission may be called for, we specify it here.
    Please note that this retransmission algorithm MUST NOT be applied
    except in cases where it is specifically called for.   It is not
    the case that all packets are retransmitted.

    Retransmission behaviour is controlled by between two and four
    variables.  All retransmission algorithms have an initial
    retransmission time (IRT).  In some cases a maximum retry count
    (MRC), maximum retry time (MRT), and/or maximum retry duration
    (MRD), may also be specified.  These three letter acronyms will be
    used later in this document when we refer to this section.

    When an initial transmission occurs, the transmitting agent sets
    the retransmission timout (RT) value to IRT plus the product of a
    random quantity between -1/10 and 1/10 multiplied by IRT:

        RT = IRT + (rnd (-0.1, 0.1) * IRT).

    On each subsequent transmission, the retransmission timeout is set
    to the previous retransmission timeout multiplied by two plus the
    a randomly chosen number between -1/10 and 1/10 multiplied by
    of the previous retransmission timeout:

        RT' = (RT * 2) + (rnd (-0.1, 0.1) * RT)

    If MRT is defined and the new retransmission timeout is greater
    than MRT, it is set to MRT multiplied by a randomly chosen number
    between 9/10 and 1 1/10:

        if (RT' > MRT)
                RT' = MRT * rnd (0.9, 1.1)

    Unless otherwise specified, when a response is received to a
    transmission, the retransmission process MUST be immediately
    terminated.  If MRC is defined and the packet has been transmitted
    MRC times, the retransmission process MUST be terminated, except
    that if MRC is -1, the retransmission process MUST continue until a
    response is received.  If MRD is defined and that many seconds have
    elapsed since the first message was transmitted, the retransmission
    process MUST also terminate.

    The algorithm used to choose a random number does not need to be
    cryptographically sound, but it SHOULD produce a different sequence
    of numbers on each invocation of the DHCP client.   The element of
    randomness prevents similar client implementations from getting
    into lock-step.

    When computing timeouts, the computation MUST be done in such a way
    that it is accurate to at least the nearest millisecond, and when
    processing timeouts, at least the same degree of accuracy SHOULD be
    used.  In any case, timeout processing MUST be accurate to at least
    500 milliseconds.

=====
(Replacement text for existing section 13.3.2)

13.3.2. Time out and retransmission of Solicit Messages

    The client's first Solicit message on the interface MUST be delayed
    by a random amount of time between the interval of MIN_SOL_DELAY and
    MAX_SOL_DELAY. This random delay desynchronizes clients which start
    at the same time (e.g., after a power outage).


    The client then uses the retransmission algorithm described in 12a,
    using ADV_MSG_TIMEOUT for IRT, ADV_MSG_MAX for MRT, and
    SOL_MAX_ATTEMPTS for MRC.  Receipt of an Advertise message prior to
    ADV_MSG_TIMEOUT does not terminate the retransmission process - the
    client will continue to listen for advertise messages until
    ADV_SEL_TIMEOUT has expired.   A retransmission MUST NOT be
    scheduled for the same time that ADV_SEL_TIMEOUT will expire.

    After SOL_MAX_ATTEMPTS attempts have been made, the client MUST
    stop trying to configure the interface using DHCP.  When the client
    has stopped trying to configure the interface, it SHOULD NOT try
    again to configure the interface unless some external event occurs.
    Examples of external events include but are not limited to
    user-initiated events, system reboots, and the client being
    connected to a new network link.  Unless there is some reason to do
    otherwise, DHCP clients SHOULD be configured with SOL_MAX_ATTEMPTS
    at -1 by default, so that the client never stops attempting to
    configure the interface.

[Note: I can see why it must be necessary for the client to give up in
some extreme cases, but from an operational perspective on a normal
network, this would be a disaster, so I've tried to wordsmith the
above language to make it glaringly obvious that it is the exception
rather than the rule that clients should stop trying to configure the
interface.   Also, the language that allowed the client to continue
retransmitting after SOL_MAX_ATTEMPTS expired doesn't make sense - if
you want that behaviour, why not just set SOL_MAX_ATTEMPTS to -1?]

    If the client detects that it has moved to a new link (see section
    14.3.2 for examples of when this can occur) the client MUST restart
    the server solicitation process.

    Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
    ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5.

------_=_NextPart_001_01C10F93.170CD290-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 10:17:08 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01588; Wed, 18 Jul 2001 10:17:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IEHSL09065; Wed, 18 Jul 2001 10:17:28 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IEHDL15029 for ; Wed, 18 Jul 2001 10:17:13 -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 f6IEHCp24750 for ; Wed, 18 Jul 2001 09:17:12 -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 f6IEHCR00827 for ; Wed, 18 Jul 2001 09:17:12 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jul 18 09:17:01 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP29HRN>; Wed, 18 Jul 2001 09:17:01 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32B7@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses Date: Wed, 18 Jul 2001 09:16:59 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F94.4EF59BA0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F94.4EF59BA0 Content-Type: text/plain; charset="iso-8859-1" I'd rather keep the existing behavoir. I don't think it is that much more complicated. It basically requires a validation of the request (to make sure all addresses are truely in the IA) and then only removing a subset of the addresses instead of all. If Ted's concerned that a client and server may not agree on the addresses it has, I see three solutions: - If the address a client specified is not part of the server's IA but the address is not otherwise in use (by another client or IA), then ignore the 'error' and consider the address released. After all it is! (In the case of a Decline, ignore the address as that client has no right to decline it.) - The client always has the ability to Release/Decline all address if it gets an error back. Then the client/server should be in agreement regarding that IA (no addresses). In this case, the client MUST send an IA with no addresses. - The client can simply 'drop' the IA and let the addresses' lifetime clean them up. Or, am I missing some set of events that cause more severe problems? I like the text below - though it might need a slight revision if we feel the above is appropriate. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, July 18, 2001 9:43 AM To: DHCPv6 discussion list Subject: Simplify release and decline of addresses Ted suggests a simplification: requiring that all the addresses in an IA be released or declined, rather than just some of those addresses. Ted also wrote text describing the server behavior in response to a Decline message (which is missing from the -19 rev). - Ralph 14.4.5. Receipt of Release messages Upon the receipt of a valid Release message, the server examines the IAs and the addresses in the IAs for validity. If the IAs in the message are in a binding for the client and the addresses in the IAs have been assigned by the server to those IA, the server deletes the addresses from the IAs and makes the addresses available for assignment to other clients. [IMHO, this is too complicated. I think the client should always release all addresses in an IA - that is, it should just send an empty IA as described below. Otherwise you get into complexities about how to back out of an erroneous transaction that I think can't be solved.] 14.4.5-1/2. Receipt of Decline messages (To be inserted after existing section 14.4.5 in -19 rev) Upon the receipt of a valid Decline message, the server examines the IAs and the addresses in the IAs for validity. If any IA in the message is not an IA that has been assigned by the server to that client, or if any addresses are mentioned in an IA that were not assigned by the server to the client, the server MUST NOT further process the message, but should send a Reply message indicating a NoBinding status. For each IA in the message, if there are any addresses mentioned in that IA, the server SHOULD mark each of these addresses as in conflict and SHOULD NOT make these addresses available for allocation to other clients. Any addresses that the server has allocated to that IA but that are not mentioned in the message SHOULD be made available for assignment to other clients. [As above, I would argue that the client should simply send empty IAs, and let all the addresses be declined. This has the disadvantage that you can lose addresses that were not in conflict, but it makes the whole transaction a lot simpler, and I think simplicity is a real virtue in this case.] If an IA is mentioned in the Decline message without any accompanying addresses, the server SHOULD mark all the addresses in the IA as being in conflict, and SHOULD NOT make these addresses available for immediate assignment to other clients. Server implementors SHOULD implement a strategy for reclaiming these IP addresses if there are no addresses available for allocation. Server implementors MAY also implement a strategy to detect a client that is repeatedly allocating and then declining addresses. When such a client is detected, the server SHOULD refuse to allocate further addresses to that client for DECLINE_COOLOFF (see section 7.5) seconds. The server then generates a Reply message. If all of the IAs were valid, the server sets the "status" field to "Success". If any of the IAs were invalid, the server sets the "status" field to "NoBinding" (section 7.4). ------_=_NextPart_001_01C10F94.4EF59BA0 Content-Type: text/html; charset="iso-8859-1" RE: Simplify release and decline of addresses

I'd rather keep the existing behavoir. I don't think it is that much
more complicated. It basically requires a validation of the request
(to make sure all addresses are truely in the IA) and then only
removing a subset of the addresses instead of all.

If Ted's concerned that a client and server may not agree on the
addresses it has, I see three solutions:
- If the address a client specified is not part of the server's IA
but the address is not otherwise in use (by another client or IA),
then ignore the 'error' and consider the address released. After all
it is! (In the case of a Decline, ignore the address as that client
has no right to decline it.)
- The client always has the ability to Release/Decline all address
if it gets an error back. Then the client/server should be in
agreement regarding that IA (no addresses). In this case, the client
MUST send an IA with no addresses.
- The client can simply 'drop' the IA and let the addresses' lifetime
clean them up.

Or, am I missing some set of events that cause more severe problems?

I like the text below - though it might need a slight revision if we
feel the above is appropriate.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, July 18, 2001 9:43 AM
To: DHCPv6 discussion list
Subject: Simplify release and decline of addresses


Ted suggests a simplification: requiring that all the addresses in an IA be
released or declined, rather than just some of those addresses.  Ted also
wrote text describing the server behavior in response to a Decline message
(which is missing from the -19 rev).

- Ralph

14.4.5. Receipt of Release messages

    Upon the receipt of a valid Release message, the server examines the
    IAs and the addresses in the IAs for validity.  If the IAs in the
    message are in a binding for the client and the addresses in the IAs
    have been assigned by the server to those IA, the server deletes
    the addresses from the IAs and makes the addresses available for
    assignment to other clients.

[IMHO, this is too complicated.  I think the client should always
release all addresses in an IA - that is, it should just send an empty
IA as described below.   Otherwise you get into complexities about how
to back out of an erroneous transaction that I think can't be solved.]


14.4.5-1/2. Receipt of Decline messages (To be inserted after existing
                                          section 14.4.5 in -19 rev)

    Upon the receipt of a valid Decline message, the server examines the
    IAs and the addresses in the IAs for validity.  If any IA in the
    message is not an IA that has been assigned by the server to that
    client, or if any addresses are mentioned in an IA that were not
    assigned by the server to the client, the server MUST NOT further
    process the message, but should send a Reply message indicating a
    NoBinding status.

    For each IA in the message, if there are any addresses mentioned in
    that IA, the server SHOULD mark each of these addresses as in
    conflict and SHOULD NOT make these addresses available for
    allocation to other clients.  Any addresses that the server has
    allocated to that IA but that are not mentioned in the message
    SHOULD be made available for assignment to other clients.

[As above, I would argue that the client should simply send empty IAs,
and let all the addresses be declined.   This has the disadvantage
that you can lose addresses that were not in conflict, but it makes
the whole transaction a lot simpler, and I think simplicity is a real
virtue in this case.]

    If an IA is mentioned in the Decline message without any
    accompanying addresses, the server SHOULD mark all the addresses in
    the IA as being in conflict, and SHOULD NOT make these addresses
    available for immediate assignment to other clients.

    Server implementors SHOULD implement a strategy for reclaiming
    these IP addresses if there are no addresses available for
    allocation.   Server implementors MAY also implement a strategy to
    detect a client that is repeatedly allocating and then declining
    addresses.   When such a client is detected, the server SHOULD
    refuse to allocate further addresses to that client for
    DECLINE_COOLOFF (see section 7.5) seconds.

    The server then generates a Reply message.  If all of the IAs were
    valid, the server sets the "status" field to "Success".  If any of
    the IAs were invalid, the server sets the "status" field to
    "NoBinding" (section 7.4).

------_=_NextPart_001_01C10F94.4EF59BA0-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 10:38:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06254; Wed, 18 Jul 2001 10:38:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IEaXL11723; Wed, 18 Jul 2001 10:36:33 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IEaML07949 for ; Wed, 18 Jul 2001 10:36:22 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA01441; Wed, 18 Jul 2001 10:36:21 -0400 Date: Wed, 18 Jul 2001 10:36:21 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses In-Reply-To: <66F66129A77AD411B76200508B65AC697B32B7@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I thought teds text was fine. simple and will reduce errors for programmers which reduces engineering cost. if we agree with ted and I am pretty sure I do. lets just adopt the text it will work. other comments please /jim On Wed, 18 Jul 2001, Bernie Volz (EUD) wrote: > I'd rather keep the existing behavoir. I don't think it is that much > more complicated. It basically requires a validation of the request > (to make sure all addresses are truely in the IA) and then only > removing a subset of the addresses instead of all. > > If Ted's concerned that a client and server may not agree on the > addresses it has, I see three solutions: > - If the address a client specified is not part of the server's IA > but the address is not otherwise in use (by another client or IA), > then ignore the 'error' and consider the address released. After all > it is! (In the case of a Decline, ignore the address as that client > has no right to decline it.) > - The client always has the ability to Release/Decline all address > if it gets an error back. Then the client/server should be in > agreement regarding that IA (no addresses). In this case, the client > MUST send an IA with no addresses. > - The client can simply 'drop' the IA and let the addresses' lifetime > clean them up. > > Or, am I missing some set of events that cause more severe problems? > > I like the text below - though it might need a slight revision if we > feel the above is appropriate. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, July 18, 2001 9:43 AM > To: DHCPv6 discussion list > Subject: Simplify release and decline of addresses > > > Ted suggests a simplification: requiring that all the addresses in an IA be > released or declined, rather than just some of those addresses. Ted also > wrote text describing the server behavior in response to a Decline message > (which is missing from the -19 rev). > > - Ralph > > 14.4.5. Receipt of Release messages > > Upon the receipt of a valid Release message, the server examines the > IAs and the addresses in the IAs for validity. If the IAs in the > message are in a binding for the client and the addresses in the IAs > have been assigned by the server to those IA, the server deletes > the addresses from the IAs and makes the addresses available for > assignment to other clients. > > [IMHO, this is too complicated. I think the client should always > release all addresses in an IA - that is, it should just send an empty > IA as described below. Otherwise you get into complexities about how > to back out of an erroneous transaction that I think can't be solved.] > > > 14.4.5-1/2. Receipt of Decline messages (To be inserted after existing > section 14.4.5 in -19 rev) > > Upon the receipt of a valid Decline message, the server examines the > IAs and the addresses in the IAs for validity. If any IA in the > message is not an IA that has been assigned by the server to that > client, or if any addresses are mentioned in an IA that were not > assigned by the server to the client, the server MUST NOT further > process the message, but should send a Reply message indicating a > NoBinding status. > > For each IA in the message, if there are any addresses mentioned in > that IA, the server SHOULD mark each of these addresses as in > conflict and SHOULD NOT make these addresses available for > allocation to other clients. Any addresses that the server has > allocated to that IA but that are not mentioned in the message > SHOULD be made available for assignment to other clients. > > [As above, I would argue that the client should simply send empty IAs, > and let all the addresses be declined. This has the disadvantage > that you can lose addresses that were not in conflict, but it makes > the whole transaction a lot simpler, and I think simplicity is a real > virtue in this case.] > > If an IA is mentioned in the Decline message without any > accompanying addresses, the server SHOULD mark all the addresses in > the IA as being in conflict, and SHOULD NOT make these addresses > available for immediate assignment to other clients. > > Server implementors SHOULD implement a strategy for reclaiming > these IP addresses if there are no addresses available for > allocation. Server implementors MAY also implement a strategy to > detect a client that is repeatedly allocating and then declining > addresses. When such a client is detected, the server SHOULD > refuse to allocate further addresses to that client for > DECLINE_COOLOFF (see section 7.5) seconds. > > The server then generates a Reply message. If all of the IAs were > valid, the server sets the "status" field to "Success". If any of > the IAs were invalid, the server sets the "status" field to > "NoBinding" (section 7.4). > From owner-dhcp-v4@bucknell.edu Wed Jul 18 10:48:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09080 for ; Wed, 18 Jul 2001 10:48:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IEjYL26188; Wed, 18 Jul 2001 10:45:34 -0400 (EDT) Received: from web20110.mail.yahoo.com (web20110.mail.yahoo.com [216.136.226.47]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IEjPL26583 for ; Wed, 18 Jul 2001 10:45:25 -0400 (EDT) Message-ID: <20010718144524.39756.qmail@web20110.mail.yahoo.com> Received: from [192.146.101.12] by web20110.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 07:45:24 PDT Date: Wed, 18 Jul 2001 07:45:24 -0700 (PDT) From: Jimmy Bush Subject: Vicarious DHCP To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: my_gyro@yahoo.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Is there any mechanism or has anyone ever successfully completed a vicarious DHCP interaction? By this I mean that I would like to use a PC to perform all interaction with a server and then send all revelant information to a unit incapable of DHC. I can do it if I am on the same subnet as the device and stick my NIC into promiscous mode, but is there a cleaner way, a way that could be extended to larger networks or different topologies? Thanks in advance for any help. Regards, Jimmy Bush __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-dhcp-v6@bucknell.edu Wed Jul 18 10:48:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09296; Wed, 18 Jul 2001 10:48:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IEn5L28500; Wed, 18 Jul 2001 10:49:05 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IEmqL05963 for ; Wed, 18 Jul 2001 10:48: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 f6IEmpp15422 for ; Wed, 18 Jul 2001 09:48: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 f6IEmpR21870 for ; Wed, 18 Jul 2001 09:48:51 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Jul 18 09:48:50 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKF9X6>; Wed, 18 Jul 2001 09:48:50 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32BA@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Circuit ID and Remote ID options Date: Wed, 18 Jul 2001 09:48:39 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F98.BB1F2270" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F98.BB1F2270 Content-Type: text/plain; charset="iso-8859-1" I think this should be a separate specification. Easier to review/edit and makes the DHCPv6 specification look less daunting. It also isn't a REQUIRED part of the protocol. Please note that giaddr is used in the text and should be changed to DHCPv6 terminology. I'm also wondering whether it would be easier to just assign a DHCP Relay Agent Information Option number (16-bit) and use the suboptions per RFC 3046. Though, as the giaddr reference points out, it may require some minor text to explain how to adapt this RFC to IPv6. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, July 18, 2001 9:54 AM To: DHCPv6 discussion list Subject: Circuit ID and Remote ID options Ted has drafted text for the Circuit ID and Remote ID options, which are to be used between relay agents and servers. Two questions: is the text OK and do we want to include the text in the base protocol spec? I'm inclined not to include these two options in the base spec. Instead, I suggest that they, along with other options we know we'll need real soon but are not referenced elsewhere in the base spec, be moved to separate drafts for consideration in parallel with the base spec I-D. - Ralph 18.13 Circuit ID Option This option MAY be placed in Relay-forward messages by DHCP relay agents which terminate switched or permanent circuits. It encodes an agent-local identifier of the circuit on which a DHCP client-to-server packet was received. It is intended for use by relay agents in relaying DHCP responses back to the proper circuit. Possible values encoded in this field include: - Router interface number - Switching Hub port number - Remote Access Server port number - Frame Relay DLCI - ATM virtual circuit number - Cable Data virtual circuit number Servers MAY use the Circuit ID when making address allocation decisions and in applying other parameter assignment policies. The Circuit ID SHOULD be considered an opaque value, with policies based on exact string match only; that is, the Circuit ID SHOULD NOT be internally parsed by the server. Servers MUST return the Circuit ID option in the Relay-reply message that is generated in response to a Relay-forward message if this option appears in the Relay-forward message. Since the Circuit ID is local only to a particular relay agent, a circuit ID should be qualified with the giaddr value that identifies the relay agent. 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_CIRCUIT_ID | option_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . circuit ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This corresponds to the DHCPv4 Circuit ID subpoption as described in [24]. 18.14 Remote ID Option This option MAY be sent in Relay-forward messages by DHCP relay agents which terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. The Remote ID field may be used to encode, for instance: -- a "caller ID" telephone number for dial-up connection -- a "user name" prompted for by a Remote Access Server -- a remote caller ATM address -- a "modem ID" of a cable data modem -- the remote IP address of a point-to-point link -- a remote X.25 address for X.25 connections The remote ID MUST be globally unique. DHCP servers MAY use this option to select parameters specific to particular users, hosts, or subscriber modems. The option SHOULD be considered an opaque value, with policies based on exact string match only; that is, the option SHOULD NOT be internally parsed by the server. Servers MUST return the Circuit ID option in the Relay-reply message that is generated in response to a Relay-forward message if this option appears in the Relay-forward message. The relay agent MAY use this field to select the circuit on which to forward a DHCP reply 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_REMOTE_ID | option_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . remote ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This corresponds to the DHCPv4 Remote ID subpoption as described in [24]. ------_=_NextPart_001_01C10F98.BB1F2270 Content-Type: text/html; charset="iso-8859-1" RE: Circuit ID and Remote ID options

I think this should be a separate specification. Easier to review/edit and
makes the DHCPv6 specification look less daunting. It also isn't a REQUIRED
part of the protocol.

Please note that giaddr is used in the text and should be changed to DHCPv6
terminology.

I'm also wondering whether it would be easier to just assign a DHCP Relay
Agent Information Option number (16-bit) and use the suboptions per RFC
3046. Though, as the giaddr reference points out, it may require some minor
text to explain how to adapt this RFC to IPv6.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, July 18, 2001 9:54 AM
To: DHCPv6 discussion list
Subject: Circuit ID and Remote ID options


Ted has drafted text for the Circuit ID and Remote ID options, which are to
be used between relay agents and servers.  Two questions: is the text OK
and do we want to include the text in the base protocol spec?

I'm inclined not to include these two options in the base spec.  Instead, I
suggest that they, along with other options we know we'll need real soon
but are not referenced elsewhere in the base spec, be moved to separate
drafts for consideration in parallel with the base spec I-D.

- Ralph

18.13 Circuit ID Option

    This option MAY be placed in Relay-forward messages by DHCP relay
    agents which terminate switched or permanent circuits.  It encodes
    an agent-local identifier of the circuit on which a DHCP
    client-to-server packet was received.  It is intended for use by
    relay agents in relaying DHCP responses back to the proper circuit.
    Possible values encoded in this field include:

        - Router interface number
        - Switching Hub port number
        - Remote Access Server port number
        - Frame Relay DLCI
        - ATM virtual circuit number
        - Cable Data virtual circuit number

    Servers MAY use the Circuit ID when making address allocation
    decisions and in applying other parameter assignment policies.  The
    Circuit ID SHOULD be considered an opaque value, with policies
    based on exact string match only; that is, the Circuit ID SHOULD
    NOT be internally parsed by the server.   Servers MUST return the
    Circuit ID option in the Relay-reply message that is generated in
    response to a Relay-forward message if this option appears in the
    Relay-forward message.

    Since the Circuit ID is local only to a particular relay agent, a
    circuit ID should be qualified with the giaddr value that
    identifies the relay agent.

     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_CIRCUIT_ID        |         option_length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                          circuit ID                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


    This corresponds to the DHCPv4 Circuit ID subpoption as described
    in [24].

18.14 Remote ID Option

    This option MAY be sent in Relay-forward messages by DHCP relay
    agents which terminate switched or permanent circuits and have
    mechanisms to identify the remote host end of the circuit.  The
    Remote ID field may be used to encode, for instance:

        -- a "caller ID" telephone number for dial-up connection
        -- a "user name" prompted for by a Remote Access Server
        -- a remote caller ATM address
        -- a "modem ID" of a cable data modem
        -- the remote IP address of a point-to-point link
        -- a remote X.25 address for X.25 connections

    The remote ID MUST be globally unique.

    DHCP servers MAY use this option to select parameters specific to
    particular users, hosts, or subscriber modems.  The option SHOULD
    be considered an opaque value, with policies based on exact string
    match only; that is, the option SHOULD NOT be internally parsed by
    the server.  Servers MUST return the Circuit ID option in the
    Relay-reply message that is generated in response to a
    Relay-forward message if this option appears in the Relay-forward
    message.

    The relay agent MAY use this field to select the circuit on which
    to forward a DHCP reply 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_REMOTE_ID        |         option_length         |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    .                                                               .
    .                           remote ID                           .
    .                                                               .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

    This corresponds to the DHCPv4 Remote ID subpoption as described in
    [24].

------_=_NextPart_001_01C10F98.BB1F2270-- From owner-dhcp-v4@bucknell.edu Wed Jul 18 11:01:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11900 for ; Wed, 18 Jul 2001 11:01:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IF02L14495; Wed, 18 Jul 2001 11:00:02 -0400 (EDT) Received: from landsraad.cv.net (landsraad.cv.net [167.206.113.25]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IExnL29981 for ; Wed, 18 Jul 2001 10:59:49 -0400 (EDT) Received: (from czydel@localhost) by landsraad.cv.net (8.11.0/8.11.0) id f6IEweA41791; Wed, 18 Jul 2001 10:58:40 -0400 (EDT) (envelope-from czydel) Date: Wed, 18 Jul 2001 10:58:40 -0400 From: "Christopher B. Zydel" To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: Vicarious DHCP Message-ID: <20010718105840.S22532@landsraad.cv.net> Reply-To: czydel@cv.net References: <20010718144524.39756.qmail@web20110.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20010718144524.39756.qmail@web20110.mail.yahoo.com>; from my_gyro@yahoo.com on Wed, Jul 18, 2001 at 07:45:24AM -0700 Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Are you using some sort of test program to act as a DHCP client for testing purposes? If this is the case, you may want to have it handle the packets as if it were a relay agent by filling in giaddr with an address on the subnet that you will be populating with leases. In this case, you would have your program unicast its transactions directly to the DHCP server, and the subnet that you will be populating with leases should be routed to the host running the test program. This mechanism has worked well for us for the purpose of performance and client processing testing. /cbz On Wed, Jul 18, 2001 at 07:45:24AM -0700, Jimmy Bush wrote: > Is there any mechanism or has anyone ever successfully > completed a vicarious DHCP interaction? By this I > mean that I would like to use a PC to perform all > interaction with a server and then send all revelant > information to a unit incapable of DHC. I can do it > if I am on the same subnet as the device and stick my > NIC into promiscous mode, but is there a cleaner way, > a way that could be extended to larger networks or > different topologies? > Thanks in advance for any help. > > Regards, > > Jimmy Bush > > __________________________________________________ > Do You Yahoo!? > Get personalized email addresses from Yahoo! Mail > http://personal.mail.yahoo.com/ From owner-dhcp-v6@bucknell.edu Wed Jul 18 11:01:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11944; Wed, 18 Jul 2001 11:01:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IF1aL20724; Wed, 18 Jul 2001 11:01:36 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IF1VL21635 for ; Wed, 18 Jul 2001 11:01:31 -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 f6IF1Up22509 for ; Wed, 18 Jul 2001 10:01:30 -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 f6IF1UY16734 for ; Wed, 18 Jul 2001 10:01:30 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jul 18 10:01:29 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKF06F>; Wed, 18 Jul 2001 10:01:29 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32BE@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Wed, 18 Jul 2001 10:01:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10F9A.860CA380" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10F9A.860CA380 Content-Type: text/plain; charset="iso-8859-1" Ralph, et al: Here's proposed text for dealing with the DHCPNACK issue. Ted and I exchanged messages on this text and I've used most of Ted's feedback here - though Ted has not seen this latest round. 1) Add to section 7.4.2: |NoPrefixMatch_|26______|_An addr in IA not valid for prefix_|_ 2) Add to 14.4.1, 14.4.2, 14.4.4: If the server finds that the prefix on one or more IP addresses in any IA in the {Request,Confirm,Rebind} message is not a valid prefix for the link to which the client is connected, the server MUST send an NoPrefixMatch status in the IA status field for that IA in the DHCP Reply message. [Should we include Renew in the message list and add to 14.4.3?] 3) Add to Section 14.3.5. (Receipt of Reply message in response to a Request, Confirm, Renew or Rebind message): When the client receives a NoPrefixMatch error status in the IA status field of a Reply to a Confirm message, the client MUST make a determination as to whether it has moved to a different link. If the client is unable to make such a determination it MUST assume that it has moved to a new link. In this case the client MAY discard the IA that received the NoPrefixMatch status, or may retain it as long as the addresses in the IA continue to be valid. 4) Add somewhere (perhaps in 18.3, Identity Associatin Option): The client MUST NOT send any address in an IA once that address' valid lifetime has expired. - Bernie (and Ted) ------_=_NextPart_001_01C10F9A.860CA380 Content-Type: text/html; charset="iso-8859-1" Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]

Ralph, et al:

Here's proposed text for dealing with the DHCPNACK issue. Ted and I
exchanged messages on this text and I've used most of Ted's feedback
here - though Ted has not seen this latest round.

1) Add to section 7.4.2:

   |NoPrefixMatch_|26______|_An addr in IA not valid for prefix_|_

2) Add to 14.4.1, 14.4.2, 14.4.4:

   If the server finds that the prefix on one or more IP addresses in
   any IA in the {Request,Confirm,Rebind} message is not a valid
   prefix for the link to which the client is connected, the server
   MUST send an NoPrefixMatch status in the IA status field for that
   IA in the DHCP Reply message.

   [Should we include Renew in the message list and add to 14.4.3?]

3) Add to Section 14.3.5. (Receipt of Reply message in response
   to a Request, Confirm, Renew or Rebind message):

   When the client receives a NoPrefixMatch error status in the IA status
   field of a Reply to a Confirm message, the client MUST make a
   determination as to whether it has moved to a different link.  If the
   client is unable to make such a determination it MUST assume that it
   has moved to a new link.  In this case the client MAY discard the IA
   that received the NoPrefixMatch status, or may retain it as long as
   the addresses in the IA continue to be valid.

4) Add somewhere (perhaps in 18.3, Identity Associatin Option):

   The client MUST NOT send any address in an IA once that address'
   valid lifetime has expired.

- Bernie (and Ted)

------_=_NextPart_001_01C10F9A.860CA380-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 12:15:46 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03692; Wed, 18 Jul 2001 12:15:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IGFmL11948; Wed, 18 Jul 2001 12:15:48 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IGFdL03730 for ; Wed, 18 Jul 2001 12:15:39 -0400 (EDT) Received: from BarrFS9RB01 (dhcp-238.rc.vix.com [204.152.187.238]) by shell.nominum.com (Postfix) with SMTP id B1BC931919 for ; Wed, 18 Jul 2001 09:15:23 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Wed, 18 Jul 2001 09:15:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C10F6A.2B3554F0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <66F66129A77AD411B76200508B65AC697B32B3@eambunt705.ena-east.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C10F6A.2B3554F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Definition of DUIDBernie, you may have been kidding, but what's important is that a unique number be used to identify the vendor in this case, so the EIN isn't all that weird. I'll have some suggested text to unify this later today. --Barr PS: For US vendors, we could even have them use their EIN (Employer Identification Number)? [Just kidding.] ------=_NextPart_000_0000_01C10F6A.2B3554F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Definition of DUID
Bernie,
 
you may have=20 been kidding, but what's important is that a unique number be used to = identify=20 the vendor in this case, so the EIN isn't all that weird.  I'll = have some=20 suggested text to unify this later today.
 
--Barr
 
PS:=20 For US vendors, we could even have them use their EIN (Employer = Identification=20 Number)? [Just kidding.]
 
------=_NextPart_000_0000_01C10F6A.2B3554F0-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 12:35:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07532; Wed, 18 Jul 2001 12:35:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IGZcL01003; Wed, 18 Jul 2001 12:35:38 -0400 (EDT) Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IGZNL04457 for ; Wed, 18 Jul 2001 12:35:25 -0400 (EDT) Received: from 157.54.9.104 by mail3.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 18 Jul 2001 09:32:19 -0700 (Pacific Daylight Time) Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jul 2001 09:34:41 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jul 2001 09:34:41 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jul 2001 09:33:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FA7.65C84034" Subject: RE: Simplify release and decline of addresses Date: Wed, 18 Jul 2001 09:33:38 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC162B6D4@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Simplify release and decline of addresses Thread-Index: AcEPlHQBB9QImuWbRIKgutnLVKuougAEgKRw From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 18 Jul 2001 16:33:38.0691 (UTC) FILETIME=[65EA8D30:01C10FA7] Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------_=_NextPart_001_01C10FA7.65C84034 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Are we still considering the addition of NAK to v6? If the client is waiting for an ACK from the server for release/decline, it could be a problem when the client has switched networks. Either we need to have "Release/decline - go to the next state" or "release/wait for a NAK/ACK" to speed up the process. =20 I think there is a typo in the current draft: =20 Section 14.3.11 needs to be changed as: =20 From 14.3.11. Receipt of Reply message in response to a Release message =20 To 14.3.11. Receipt of Reply message in response to a Decline message =20 =20 =20 =20 thx =20 -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]=20 Sent: Wednesday, July 18, 2001 7:17 AM To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses =20 I'd rather keep the existing behavoir. I don't think it is that much=20 more complicated. It basically requires a validation of the request=20 (to make sure all addresses are truely in the IA) and then only=20 removing a subset of the addresses instead of all.=20 If Ted's concerned that a client and server may not agree on the=20 addresses it has, I see three solutions:=20 - If the address a client specified is not part of the server's IA=20 but the address is not otherwise in use (by another client or IA),=20 then ignore the 'error' and consider the address released. After all=20 it is! (In the case of a Decline, ignore the address as that client=20 has no right to decline it.)=20 - The client always has the ability to Release/Decline all address=20 if it gets an error back. Then the client/server should be in=20 agreement regarding that IA (no addresses). In this case, the client=20 MUST send an IA with no addresses.=20 - The client can simply 'drop' the IA and let the addresses' lifetime=20 clean them up.=20 Or, am I missing some set of events that cause more severe problems?=20 I like the text below - though it might need a slight revision if we=20 feel the above is appropriate.=20 - Bernie=20 -----Original Message-----=20 From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Wednesday, July 18, 2001 9:43 AM=20 To: DHCPv6 discussion list=20 Subject: Simplify release and decline of addresses=20 =20 Ted suggests a simplification: requiring that all the addresses in an IA be=20 released or declined, rather than just some of those addresses. Ted also=20 wrote text describing the server behavior in response to a Decline message=20 (which is missing from the -19 rev).=20 - Ralph=20 14.4.5. Receipt of Release messages=20 Upon the receipt of a valid Release message, the server examines the IAs and the addresses in the IAs for validity. If the IAs in the=20 message are in a binding for the client and the addresses in the IAs have been assigned by the server to those IA, the server deletes=20 the addresses from the IAs and makes the addresses available for=20 assignment to other clients.=20 [IMHO, this is too complicated. I think the client should always=20 release all addresses in an IA - that is, it should just send an empty=20 IA as described below. Otherwise you get into complexities about how=20 to back out of an erroneous transaction that I think can't be solved.]=20 =20 14.4.5-1/2. Receipt of Decline messages (To be inserted after existing=20 section 14.4.5 in -19 rev)=20 Upon the receipt of a valid Decline message, the server examines the IAs and the addresses in the IAs for validity. If any IA in the=20 message is not an IA that has been assigned by the server to that=20 client, or if any addresses are mentioned in an IA that were not=20 assigned by the server to the client, the server MUST NOT further=20 process the message, but should send a Reply message indicating a=20 NoBinding status.=20 For each IA in the message, if there are any addresses mentioned in=20 that IA, the server SHOULD mark each of these addresses as in=20 conflict and SHOULD NOT make these addresses available for=20 allocation to other clients. Any addresses that the server has=20 allocated to that IA but that are not mentioned in the message=20 SHOULD be made available for assignment to other clients.=20 [As above, I would argue that the client should simply send empty IAs,=20 and let all the addresses be declined. This has the disadvantage=20 that you can lose addresses that were not in conflict, but it makes=20 the whole transaction a lot simpler, and I think simplicity is a real=20 virtue in this case.]=20 If an IA is mentioned in the Decline message without any=20 accompanying addresses, the server SHOULD mark all the addresses in=20 the IA as being in conflict, and SHOULD NOT make these addresses=20 available for immediate assignment to other clients.=20 Server implementors SHOULD implement a strategy for reclaiming=20 these IP addresses if there are no addresses available for=20 allocation. Server implementors MAY also implement a strategy to=20 detect a client that is repeatedly allocating and then declining=20 addresses. When such a client is detected, the server SHOULD=20 refuse to allocate further addresses to that client for=20 DECLINE_COOLOFF (see section 7.5) seconds.=20 The server then generates a Reply message. If all of the IAs were=20 valid, the server sets the "status" field to "Success". If any of=20 the IAs were invalid, the server sets the "status" field to=20 "NoBinding" (section 7.4).=20 ------_=_NextPart_001_01C10FA7.65C84034 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Simplify release and decline of addresses

Are we still considering the = addition of NAK to v6? If the client is waiting for an ACK from the server for release/decline, it could be a problem when the client has switched = networks. Either we need to have “Release/decline – go to the next = state” or “release/wait for a NAK/ACK” to speed up the = process.

 

I think there is a typo in the current =
draft:
 
Section =
14.3.11 needs to be changed as:
 
From
14.3.11. =
Receipt of Reply message in response to a Release =
message
 
To
14.3.11. =
Receipt of Reply message in response to a Decline =
message
 
 
 

 

thx

 

-----Original = Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday, July 18, 2001 7:17 = AM
To: DHCPv6 discussion = list
Subject: RE: Simplify = release and decline of addresses

 

I'd rather keep the existing behavoir. I = don't think it is that much
more complicated. It = basically requires a validation of the request
(to make sure all = addresses are truely in the IA) and then only
removing a subset of the = addresses instead of all.

If Ted's concerned that a client and server = may not agree on the
addresses it has, I see = three solutions:
- If the address a = client specified is not part of the server's IA
but the address is not = otherwise in use (by another client or IA),
then ignore the 'error' = and consider the address released. After all
it is! (In the case of a = Decline, ignore the address as that client
has no right to decline = it.)
- The client always has = the ability to Release/Decline all address
if it gets an error = back. Then the client/server should be in
agreement regarding that = IA (no addresses). In this case, the client
MUST send an IA with no = addresses.
- The client can simply = 'drop' the IA and let the addresses' lifetime
clean them = up.

Or, am I missing some set of events that = cause more severe problems?

I like the text below - though it might need = a slight revision if we
feel the above is = appropriate.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, July = 18, 2001 9:43 AM
To: DHCPv6 discussion = list
Subject: Simplify = release and decline of addresses

 

Ted suggests a simplification: requiring that = all the addresses in an IA be
released or declined, = rather than just some of those addresses.  Ted also
wrote text describing = the server behavior in response to a Decline message
(which is missing from = the -19 rev).

- Ralph

14.4.5. Receipt of Release = messages

    Upon the receipt of a = valid Release message, the server examines the
    IAs = and the addresses in the IAs for validity.  If the IAs in the =
    = message are in a binding for the client and the addresses in the IAs
    have = been assigned by the server to those IA, the server deletes =
    the = addresses from the IAs and makes the addresses available for
    = assignment to other clients.

[IMHO, this is too complicated.  I think = the client should always
release all addresses in = an IA - that is, it should just send an empty
IA as described = below.   Otherwise you get into complexities about how
to back out of an = erroneous transaction that I think can't be solved.]

 

14.4.5-1/2. Receipt of Decline messages (To = be inserted after existing
       &nbs= p;            = ;            =           section 14.4.5 in -19 rev)

    Upon the receipt of a = valid Decline message, the server examines the
    IAs = and the addresses in the IAs for validity.  If any IA in the =
    = message is not an IA that has been assigned by the server to that
    = client, or if any addresses are mentioned in an IA that were not
    = assigned by the server to the client, the server MUST NOT further
    = process the message, but should send a Reply message indicating a
    = NoBinding status.

    For each IA in the = message, if there are any addresses mentioned in
    that = IA, the server SHOULD mark each of these addresses as in
    = conflict and SHOULD NOT make these addresses available for
    = allocation to other clients.  Any addresses that the server has =
    = allocated to that IA but that are not mentioned in the message
    = SHOULD be made available for assignment to other clients.

[As above, I would argue that the client = should simply send empty IAs,
and let all the = addresses be declined.   This has the disadvantage
that you can lose = addresses that were not in conflict, but it makes
the whole transaction a = lot simpler, and I think simplicity is a real
virtue in this = case.]

    If an IA is mentioned in = the Decline message without any
    = accompanying addresses, the server SHOULD mark all the addresses in =
    the = IA as being in conflict, and SHOULD NOT make these addresses
    = available for immediate assignment to other clients.

    Server implementors SHOULD implement a strategy for reclaiming
    these = IP addresses if there are no addresses available for
    allocation.   Server implementors MAY also implement a = strategy to
    = detect a client that is repeatedly allocating and then declining
    addresses.   When such a client is detected, the server = SHOULD
    = refuse to allocate further addresses to that client for
    = DECLINE_COOLOFF (see section 7.5) seconds.

    The server then generates = a Reply message.  If all of the IAs were
    = valid, the server sets the "status" field to "Success".  = If any of
    the = IAs were invalid, the server sets the "status" field to =
    "NoBinding" (section 7.4).

=00 ------_=_NextPart_001_01C10FA7.65C84034-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 12:40:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09161; Wed, 18 Jul 2001 12:40:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IGfBL32323; Wed, 18 Jul 2001 12:41:11 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [204.152.187.59]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IGf1L26193 for ; Wed, 18 Jul 2001 12:41:01 -0400 (EDT) Received: from BarrFS9RB01 (dhcp-238.rc.vix.com [204.152.187.238]) by shell.nominum.com (Postfix) with SMTP id 0251031914 for ; Wed, 18 Jul 2001 09:40:46 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Definition of DUID Date: Wed, 18 Jul 2001 09:40:43 -0700 Message-ID: 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 IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <001f01c10f68$2918ef80$a8ad658c@ZFR030101> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit comments inline.... --Barr > -----Original Message----- > From: Jerome Labussiere > > What do you think of the solution defined in COPS > (http://www.ietf.org/rfc/rfc2748.txt section 2.2.11) ? > > > Variable-length field. It is a NULL terminated ASCII string that is > > also zero padded to a 32-bit word boundary (so the object length is a > > multiple of 4 octets). The PEPID MUST contain an ASCII string that > > uniquely identifies the PEP within the policy domain in a manner that > > is persistent across PEP reboots. For example, it may be the PEP's > > statically assigned IP address or DNS name. This identifier may > > safely be used by a PDP as a handle for identifying the PEP in its > > policy rules. > ... nits first: (1) we should not introduce new protocol elements that continue to use (NVT-)ASCII -- either ISO10646 or UTF-8 will be required in the [near] future, so let's not make more work for ourselves by intentionally building in obsolescence; (2) options carry a length code precisely so that we never need to include a null terminator for a string, so let's not even consider this sort of a change as I'm afraid it sets a dangerous precedent; (3) again, because the length of an option is known in advance, padding any octet string to be a multiple of some unit is not a good idea -- it arbitrarily increases the size of the protocol messages without any clear benefit ...having said all of that, I definitely like the idea of reusing concepts that have been previously developed, and will have more to say in a later message > Maybe the DUID should not be globally-unique but simply unique within the > administrative domain (and configurable on the client) > ... one of the shortcomings of DHCPv4 is the lack of a globally unique identifier: without revisiting all of the discussion, I'll just state as an article of faith that a globally-unique identifier *is* required for DUID. I can imagine, however, that some sort of a "scope" indicator might be included in the DUID *if and only if* the working group reaches a consensus that the DUID does not *always* require global uniqueness: "scope" would then be either "local" or "global" according to the indicator carried with(in) the DUID. Again, I'll try to put this into a contribution in a later message. > As the format of the DUID was not defined, I tried this in a modest > implementation of rev-18 and it was very flexible and easy to implement. I > used NAI (ftp://ftp.isi.edu/in-notes/rfc2486.txt) to identify clients. If > the NAI "realm" is local, I used a LDAP repository, if not, it is possible > to send a request to an AAA infrastructure (using the realm to route the > request). > ... HOORAY!!! There is nothing like implementation experience to draw upon when trying to decide how to design a protocol element.... > Actually, I think it is also possible to map authentification of DHCP > messages on identification/authentification of clients in a generic way. > ... this may open up an entirely different discussion, however.... From owner-dhcp-v6@bucknell.edu Wed Jul 18 14:20:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27763; Wed, 18 Jul 2001 14:20:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IIJqL14073; Wed, 18 Jul 2001 14:19:52 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IIJaL13551 for ; Wed, 18 Jul 2001 14:19:36 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA09523; Wed, 18 Jul 2001 14:19:35 -0400 Date: Wed, 18 Jul 2001 14:19:35 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC162B6D4@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I don't think so... See mail on prefrix notification and text bernie just sent... /jim On Wed, 18 Jul 2001, Thirumalesh Bhat wrote: > Are we still considering the addition of NAK to v6? If the client is > waiting for an ACK from the server for release/decline, it could be a > problem when the client has switched networks. Either we need to have > "Release/decline - go to the next state" or "release/wait for a NAK/ACK" > to speed up the process. > > > > I think there is a typo in the current draft: > > Section 14.3.11 needs to be changed as: > > From > 14.3.11. Receipt of Reply message in response to a Release message > > To > 14.3.11. Receipt of Reply message in response to a Decline message > > > > > > > thx > > > > -----Original Message----- > From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > Sent: Wednesday, July 18, 2001 7:17 AM > To: DHCPv6 discussion list > Subject: RE: Simplify release and decline of addresses > > > > I'd rather keep the existing behavoir. I don't think it is that much > more complicated. It basically requires a validation of the request > (to make sure all addresses are truely in the IA) and then only > removing a subset of the addresses instead of all. > > If Ted's concerned that a client and server may not agree on the > addresses it has, I see three solutions: > - If the address a client specified is not part of the server's IA > but the address is not otherwise in use (by another client or IA), > then ignore the 'error' and consider the address released. After all > it is! (In the case of a Decline, ignore the address as that client > has no right to decline it.) > - The client always has the ability to Release/Decline all address > if it gets an error back. Then the client/server should be in > agreement regarding that IA (no addresses). In this case, the client > MUST send an IA with no addresses. > - The client can simply 'drop' the IA and let the addresses' lifetime > clean them up. > > Or, am I missing some set of events that cause more severe problems? > > I like the text below - though it might need a slight revision if we > feel the above is appropriate. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, July 18, 2001 9:43 AM > To: DHCPv6 discussion list > Subject: Simplify release and decline of addresses > > > > Ted suggests a simplification: requiring that all the addresses in an IA > be > released or declined, rather than just some of those addresses. Ted > also > wrote text describing the server behavior in response to a Decline > message > (which is missing from the -19 rev). > > - Ralph > > 14.4.5. Receipt of Release messages > > Upon the receipt of a valid Release message, the server examines the > > IAs and the addresses in the IAs for validity. If the IAs in the > message are in a binding for the client and the addresses in the IAs > > have been assigned by the server to those IA, the server deletes > the addresses from the IAs and makes the addresses available for > assignment to other clients. > > [IMHO, this is too complicated. I think the client should always > release all addresses in an IA - that is, it should just send an empty > IA as described below. Otherwise you get into complexities about how > to back out of an erroneous transaction that I think can't be solved.] > > > > 14.4.5-1/2. Receipt of Decline messages (To be inserted after existing > section 14.4.5 in -19 rev) > > Upon the receipt of a valid Decline message, the server examines the > > IAs and the addresses in the IAs for validity. If any IA in the > message is not an IA that has been assigned by the server to that > client, or if any addresses are mentioned in an IA that were not > assigned by the server to the client, the server MUST NOT further > process the message, but should send a Reply message indicating a > NoBinding status. > > For each IA in the message, if there are any addresses mentioned in > that IA, the server SHOULD mark each of these addresses as in > conflict and SHOULD NOT make these addresses available for > allocation to other clients. Any addresses that the server has > allocated to that IA but that are not mentioned in the message > SHOULD be made available for assignment to other clients. > > [As above, I would argue that the client should simply send empty IAs, > and let all the addresses be declined. This has the disadvantage > that you can lose addresses that were not in conflict, but it makes > the whole transaction a lot simpler, and I think simplicity is a real > virtue in this case.] > > If an IA is mentioned in the Decline message without any > accompanying addresses, the server SHOULD mark all the addresses in > the IA as being in conflict, and SHOULD NOT make these addresses > available for immediate assignment to other clients. > > Server implementors SHOULD implement a strategy for reclaiming > these IP addresses if there are no addresses available for > allocation. Server implementors MAY also implement a strategy to > detect a client that is repeatedly allocating and then declining > addresses. When such a client is detected, the server SHOULD > refuse to allocate further addresses to that client for > DECLINE_COOLOFF (see section 7.5) seconds. > > The server then generates a Reply message. If all of the IAs were > valid, the server sets the "status" field to "Success". If any of > the IAs were invalid, the server sets the "status" field to > "NoBinding" (section 7.4). > > From owner-dhcp-v6@bucknell.edu Wed Jul 18 15:31:45 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11328; Wed, 18 Jul 2001 15:31:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IJVmL29632; Wed, 18 Jul 2001 15:31:48 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IJVbL20517 for ; Wed, 18 Jul 2001 15:31:41 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6IJRLf14793 for ; Wed, 18 Jul 2001 12:27:21 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6IJRVw00449 for ; Wed, 18 Jul 2001 12:27:31 -0700 (MST) Message-Id: <200107181927.f6IJRVw00449@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Definition of DUID In-Reply-To: Message from "Jerome Labussiere" of "Wed, 18 Jul 2001 11:00:58 +0200." <001f01c10f68$2918ef80$a8ad658c@ZFR030101> Date: Wed, 18 Jul 2001 12:27:31 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > As the format of the DUID was not defined, I tried this in a modest > implementation of rev-18 and it was very flexible and easy to implement. I > used NAI (ftp://ftp.isi.edu/in-notes/rfc2486.txt) to identify clients. If > the NAI "realm" is local, I used a LDAP repository, if not, it is possible > to send a request to an AAA infrastructure (using the realm to route the > request). Where your proposed format falls down is not in the implementation, but in the deployment. Coming up with an ad-hoc identifier that is unique within an administrative domain is difficult. Coming up with one that continues to be unique when you move to a new administrative domain, or detecting that you have changed administrative domains and therefore generating a new identifier for that domain is even more difficult. This is why none of the proposed formats for DUID attempt to solve this problem. > Actually, I think it is also possible to map authentification of DHCP > messages on identification/authentification of clients in a generic way. That's certainly true. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 16:47:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29449; Wed, 18 Jul 2001 16:47:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IKlCL25937; Wed, 18 Jul 2001 16:47:12 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IKl1L27284 for ; Wed, 18 Jul 2001 16:47:01 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6IKgmf14905 for ; Wed, 18 Jul 2001 13:42:48 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6IKgnw00560 for ; Wed, 18 Jul 2001 13:42:49 -0700 (MST) Message-Id: <200107182042.f6IKgnw00560@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Rules for message transmission and retransmission In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 18 Jul 2001 09:08:16 EST." <66F66129A77AD411B76200508B65AC697B32B6@eambunt705.ena-east.ericsson.se> Date: Wed, 18 Jul 2001 13:42:48 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > One statement that we might want to modify slightly is "In any case, timeout > processing MUST be accurate to at least 500 milliseconds." As few operating > systems are truely real-time (this is probably more of a semantics issue), > it may not be possible to honor this requirement. I know what you want, but > am not sure how to say it better so perhaps it is a non-issue. Oops, I hadn't intended to place a real-time requirement on the client. What I intended here is just that the client application should store timeouts with at least 500ms granularity, so as to honor some of the defaults defined in section 7. > The client MAY transmit messages to a server directly if it has an address > of sufficient scope to communicate with the server and the server has > previously communicated to the client that it is allowed to do so via > the Server unicast option (Section 18.10). Otherwise, the client MUST > transmit all of its messages to the All DHCP Agents multicast address. Actually, we can't do this - certain client messages MUST be transmitted through the relay, and there is already language in the draft stating this requirement (IIRC!). _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 16:49:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29864; Wed, 18 Jul 2001 16:49:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IKoNL21959; Wed, 18 Jul 2001 16:50:23 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IKo7L22498 for ; Wed, 18 Jul 2001 16:50:07 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6IKjtf14910 for ; Wed, 18 Jul 2001 13:45:55 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6IKk0w00570 for ; Wed, 18 Jul 2001 13:46:00 -0700 (MST) Message-Id: <200107182046.f6IKk0w00570@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Simplify release and decline of addresses In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 18 Jul 2001 09:16:59 EST." <66F66129A77AD411B76200508B65AC697B32B7@eambunt705.ena-east.ericsson.se> Date: Wed, 18 Jul 2001 13:46:00 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > - The client always has the ability to Release/Decline all address > if it gets an error back. Then the client/server should be in > agreement regarding that IA (no addresses). In this case, the client > MUST send an IA with no addresses. If the client doesn't have a routable address, I don't think it can send a Release message. It doesn't seem like a good idea to just broadcast a Release message through a relay agent. I can't really justify that, but that's my gut feeling on the matter. :'} _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 16:53:40 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00780; Wed, 18 Jul 2001 16:53:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IKs2L10099; Wed, 18 Jul 2001 16:54:02 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IKrmL25704 for ; Wed, 18 Jul 2001 16:53:48 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6IKnZf14914 for ; Wed, 18 Jul 2001 13:49:36 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6IKnew00580 for ; Wed, 18 Jul 2001 13:49:40 -0700 (MST) Message-Id: <200107182049.f6IKnew00580@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Circuit ID and Remote ID options In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 18 Jul 2001 09:48:39 EST." <66F66129A77AD411B76200508B65AC697B32BA@eambunt705.ena-east.ericsson.se> Date: Wed, 18 Jul 2001 13:49:39 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I think this should be a separate specification. Easier to review/edit and > makes the DHCPv6 specification look less daunting. It also isn't a REQUIRED > part of the protocol. I was under the impression that we were trying to specify options that we know are needed in the main draft. If that is not the case, then it's fine with me if we put them in a seperate draft. > Please note that giaddr is used in the text and should be changed to DHCPv6 > terminology. Oops! > I'm also wondering whether it would be easier to just assign a DHCP Relay > Agent Information Option number (16-bit) and use the suboptions per RFC > 3046. Though, as the giaddr reference points out, it may require some minor > text to explain how to adapt this RFC to IPv6. This wouldn't make a whole lot of sense, frankly - the relay mechanism in DHCPv6 is completely different. There is no need for a suboption encapsulation - the relay agent is already encapsulating the client's packet, so the whole kludge we had to do for DHCPv4 is unnecessary. RFC3046 mostly describes the kludge, which we don't want people to even think about in DHCPv6. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 16:55:16 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01060; Wed, 18 Jul 2001 16:55:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IKtiL04038; Wed, 18 Jul 2001 16:55:44 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IKtfL06672 for ; Wed, 18 Jul 2001 16:55:41 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6IKpTf14922 for ; Wed, 18 Jul 2001 13:51:29 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6IKpXw00593 for ; Wed, 18 Jul 2001 13:51:33 -0700 (MST) Message-Id: <200107182051.f6IKpXw00593@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 18 Jul 2001 10:01:29 EST." <66F66129A77AD411B76200508B65AC697B32BE@eambunt705.ena-east.ericsson.se> Date: Wed, 18 Jul 2001 13:51:33 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > [Should we include Renew in the message list and add to 14.4.3?] The renew message can be unicast (IIRC) so the server can't make a determination as to the validity of the prefix. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 18:13:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18220; Wed, 18 Jul 2001 18:13:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IMDZL24282; Wed, 18 Jul 2001 18:13:35 -0400 (EDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IMDTL02660 for ; Wed, 18 Jul 2001 18:13:29 -0400 (EDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel1.hp.com (Postfix) with ESMTP id C1C161613 for ; Wed, 18 Jul 2001 15:13:26 -0700 (PDT) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id SAA15956; Wed, 18 Jul 2001 18:16:34 -0400 (EDT) From: Vijay Bhaskar A K Message-Id: <200107182216.SAA15956@dce.india.hp.com> Subject: RE: Simplify release and decline of addresses To: DHCPv6 discussion list Date: Wed, 18 Jul 2001 18:16:33 -0400 (EDT) X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, Find my comments inline. ~Vijay > -----Original Message----- > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > Behalf Of Ralph Droms > Sent: Wednesday, July 18, 2001 7:13 PM > To: DHCPv6 discussion list > Subject: Simplify release and decline of addresses > > > Ted suggests a simplification: requiring that all the > addresses in an IA be > released or declined, rather than just some of those > addresses. Ted also > wrote text describing the server behavior in response to a > Decline message > (which is missing from the -19 rev). > > - Ralph > > 14.4.5. Receipt of Release messages > > Upon the receipt of a valid Release message, the server > examines the > IAs and the addresses in the IAs for validity. If the IAs in the > message are in a binding for the client and the addresses > in the IAs > have been assigned by the server to those IA, the server deletes > the addresses from the IAs and makes the addresses available for > assignment to other clients. > > [IMHO, this is too complicated. I think the client should always > release all addresses in an IA - that is, it should just send an empty > IA as described below. Otherwise you get into complexities about how > to back out of an erroneous transaction that I think can't be solved.] Yes. I agree that, the release/decline of addresses as whole IA will simplify the more. So, here,the status field returned will be the same for all the addresses of the IA and it can be very well reflected in IA status. So, do we really need the "addr status" field? Whatever the error status defined can be returned in IA status itself. So, i feel that, we can remove the "addr status" field in IA. It can save many bytes, if the addresses in th IA are very large in number. Another suggestion is, because of handling Temporary address only, we have introduced the "T" bit in IA option. Why can't we define a new option for temporary address IA (TMP_IA). Using this TMP_IA, the client can ask for one or more temporary addresses. The main reason behind is, * The time values T1 and T2 are defined for specifying the time at which the client has to contact the server. But, for the temporary addresses, renewal and rebind is not possible. So, T1 and T2 are not necessary. So, we can remove these fields. * Normally, if the clients are requesting for the normal addresses, they will not be needing temporary addresses. The clients requesting for both will be rare. So, why do we need to put a bit in IA and giving more burden to IA option. So, the TMP_IA option looks like this. 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 TMP_IA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IA status | num-addrs | prefix length | IPv6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | addresses | | (16 octets) +-+-+-+-+-+-+ | | preferred | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | valid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime |IPv6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | addresses | | (16 octets) +-+-+-+-+-+-+ | | preferred | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | valid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I'm not sure whether there will be an allignment problem. But, we can reduce unnecessary bytes using this option. * One more point to be noted is, a fair implementation of DHCPv6 should support "graceful renumbering". It should provide some grace period to the old prefixes. The deprecated IPv6 addresses (addresses of old prefixes) almost look like the temporary address with preferred life time as 0 and valid life time as 1-2 days. This option will be more useful for handling those deprecated addresses, since those addresses are not supposed to be renewed/rebinded. > > 14.4.5-1/2. Receipt of Decline messages (To be inserted after existing > section 14.4.5 in -19 rev) > > Upon the receipt of a valid Decline message, the server > examines the > IAs and the addresses in the IAs for validity. If any IA in the > message is not an IA that has been assigned by the server to that > client, or if any addresses are mentioned in an IA that were not > assigned by the server to the client, the server MUST NOT further > process the message, but should send a Reply message indicating a > NoBinding status. > > For each IA in the message, if there are any addresses > mentioned in > that IA, the server SHOULD mark each of these addresses as in > conflict and SHOULD NOT make these addresses available for > allocation to other clients. Any addresses that the server has > allocated to that IA but that are not mentioned in the message > SHOULD be made available for assignment to other clients. > > [As above, I would argue that the client should simply send empty IAs, > and let all the addresses be declined. This has the disadvantage > that you can lose addresses that were not in conflict, but it makes > the whole transaction a lot simpler, and I think simplicity is a real > virtue in this case.] > > If an IA is mentioned in the Decline message without any > accompanying addresses, the server SHOULD mark all the > addresses in > the IA as being in conflict, and SHOULD NOT make these addresses > available for immediate assignment to other clients. > > Server implementors SHOULD implement a strategy for reclaiming > these IP addresses if there are no addresses available for > allocation. Server implementors MAY also implement a strategy to > detect a client that is repeatedly allocating and then declining > addresses. When such a client is detected, the server SHOULD > refuse to allocate further addresses to that client for > DECLINE_COOLOFF (see section 7.5) seconds. > > The server then generates a Reply message. If all of the IAs were > valid, the server sets the "status" field to "Success". If any of > the IAs were invalid, the server sets the "status" field to > "NoBinding" (section 7.4). > -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ From owner-dhcp-v6@bucknell.edu Wed Jul 18 18:33:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21580; Wed, 18 Jul 2001 18:33:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IMY0L09020; Wed, 18 Jul 2001 18:34:00 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IMXwL07797 for ; Wed, 18 Jul 2001 18:33:58 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6IMXg500088 for ; Wed, 18 Jul 2001 17:33:43 -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 f6IMXgc00470 for ; Wed, 18 Jul 2001 17:33:42 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jul 18 17:33:42 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP203TW>; Wed, 18 Jul 2001 17:33:41 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32C9@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Rules for message transmission and retransmission Date: Wed, 18 Jul 2001 17:33:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FD9.B1861980" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10FD9.B1861980 Content-Type: text/plain; charset="iso-8859-1" Regarding the transmission rules, I wasn't attempting to change them. Sorry for my error - I missed the case where the Reconfigure-Init is sent via the Relay. It should be added. If that revised text is desired, let me know. -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 4:43 PM To: DHCPv6 discussion list Subject: Re: Rules for message transmission and retransmission > One statement that we might want to modify slightly is "In any case, timeout > processing MUST be accurate to at least 500 milliseconds." As few operating > systems are truely real-time (this is probably more of a semantics issue), > it may not be possible to honor this requirement. I know what you want, but > am not sure how to say it better so perhaps it is a non-issue. Oops, I hadn't intended to place a real-time requirement on the client. What I intended here is just that the client application should store timeouts with at least 500ms granularity, so as to honor some of the defaults defined in section 7. > The client MAY transmit messages to a server directly if it has an address > of sufficient scope to communicate with the server and the server has > previously communicated to the client that it is allowed to do so via > the Server unicast option (Section 18.10). Otherwise, the client MUST > transmit all of its messages to the All DHCP Agents multicast address. Actually, we can't do this - certain client messages MUST be transmitted through the relay, and there is already language in the draft stating this requirement (IIRC!). _MelloN_ ------_=_NextPart_001_01C10FD9.B1861980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Rules for message transmission and retransmission

Regarding the transmission rules, I wasn't attempting = to change them. Sorry
for my error - I missed the case where the = Reconfigure-Init is sent via the
Relay. It should be added. If that revised text is = desired, let me know.

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Wednesday, July 18, 2001 4:43 PM
To: DHCPv6 discussion list
Subject: Re: Rules for message transmission and = retransmission



> One statement that we might want to modify = slightly is "In any case, timeout
> processing MUST be accurate to at least 500 = milliseconds." As few operating
> systems are truely real-time (this is probably = more of a semantics issue),
> it may not be possible to honor this = requirement. I know what you want, but
> am not sure how to say it better so perhaps it = is a non-issue.

Oops, I hadn't intended to place a real-time = requirement on the
client.   What I intended here is just = that the client application
should store timeouts with at least 500ms = granularity, so as to honor
some of the defaults defined in section 7.

> The client MAY transmit messages to a server = directly if it has an address
> of sufficient scope to communicate with the = server and the server has
> previously communicated to the client that it = is allowed to do so via
> the Server unicast option (Section 18.10). = Otherwise, the client MUST
> transmit all of its messages to the All DHCP = Agents multicast address.

Actually, we can't do this - certain client messages = MUST be
transmitted through the relay, and there is already = language in the
draft stating this requirement (IIRC!).

        =         =                _MelloN_

------_=_NextPart_001_01C10FD9.B1861980-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 18:37:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22320; Wed, 18 Jul 2001 18:37:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IMbuL18960; Wed, 18 Jul 2001 18:37:56 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IMbsL23420 for ; Wed, 18 Jul 2001 18:37:55 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6IMbd501023 for ; Wed, 18 Jul 2001 17:37: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 f6IMbdc01743 for ; Wed, 18 Jul 2001 17:37:39 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Jul 18 17:37:38 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKH1H9>; Wed, 18 Jul 2001 17:37:37 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32CA@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses Date: Wed, 18 Jul 2001 17:37:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FDA.3EC96E00" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10FDA.3EC96E00 Content-Type: text/plain; charset="iso-8859-1" For a Release and Decline, these are sent to a specific server and can reach the server via a relay. But the server might receive multiple copies (and if it has no transaction cache ...). However, that's exactly the case my suggested processing for the client covers - ignore addresses not assigned to the IA (don't consider this an error). BTW, in this case the server must be able to handle a Release or a Decline of an IA that doesn't exist. Or, if it returns an error the client must be able to handle it. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 4:46 PM To: DHCPv6 discussion list Subject: Re: Simplify release and decline of addresses > - The client always has the ability to Release/Decline all address > if it gets an error back. Then the client/server should be in > agreement regarding that IA (no addresses). In this case, the client > MUST send an IA with no addresses. If the client doesn't have a routable address, I don't think it can send a Release message. It doesn't seem like a good idea to just broadcast a Release message through a relay agent. I can't really justify that, but that's my gut feeling on the matter. :'} _MelloN_ ------_=_NextPart_001_01C10FDA.3EC96E00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Simplify release and decline of addresses

For a Release and Decline, these are sent to a = specific server and can reach
the server via a relay.

But the server might receive multiple copies (and if = it has no transaction
cache ...). However, that's exactly the case my = suggested processing
for the client covers - ignore addresses not = assigned to the IA (don't
consider this an error).

BTW, in this case the server must be able to handle a = Release or a Decline of
an IA that doesn't exist. Or, if it returns an error = the client must be able
to handle it.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Wednesday, July 18, 2001 4:46 PM
To: DHCPv6 discussion list
Subject: Re: Simplify release and decline of = addresses



> - The client always has the ability to = Release/Decline all address
> if it gets an error back. Then the = client/server should be in
> agreement regarding that IA (no addresses). In = this case, the client
> MUST send an IA with no addresses.

If the client doesn't have a routable address, I = don't think it can
send a Release message.   It doesn't seem = like a good idea to just
broadcast a Release message through a relay = agent.   I can't really
justify that, but that's my gut feeling on the = matter.   :'}

        =         =                _MelloN_

------_=_NextPart_001_01C10FDA.3EC96E00-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 18:43:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA23579; Wed, 18 Jul 2001 18:43:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IMi6L10363; Wed, 18 Jul 2001 18:44:06 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IMi5L14248 for ; Wed, 18 Jul 2001 18:44:05 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6IMhn502721 for ; Wed, 18 Jul 2001 17:43:49 -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 f6IMhnc03822 for ; Wed, 18 Jul 2001 17:43:49 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Jul 18 17:43:48 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKH1TD>; Wed, 18 Jul 2001 17:43:47 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32CB@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Wed, 18 Jul 2001 17:43:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FDB.1A647450" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10FDB.1A647450 Content-Type: text/plain; charset="iso-8859-1" I don't understand this reasoning. (Whats IIRC anyway?) What difference does that make? A Release or Decline can be unicast as well (if the client has another address - in a different IA - than what it is releasing and the server has told the client it can unicast). Why does *HOW* the packet was sent make any difference? Remember, we're dealing with MANY addresses so an individual message's IAs have nothing to do with other IAs (and hence addresses) that client has. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 4:52 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > [Should we include Renew in the message list and add to 14.4.3?] The renew message can be unicast (IIRC) so the server can't make a determination as to the validity of the prefix. _MelloN_ ------_=_NextPart_001_01C10FDB.1A647450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

I don't understand this reasoning. (Whats IIRC = anyway?)

What difference does that make? A Release or Decline = can be unicast as well
(if the client has another address - in a different = IA - than what it is
releasing and the server has told the client it can = unicast).

Why does *HOW* the packet was sent make any = difference? Remember, we're
dealing with MANY addresses so an individual = message's IAs have nothing to
do with other IAs (and hence addresses) that client = has.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Wednesday, July 18, 2001 4:52 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft = Changes]



>    [Should we include Renew in = the message list and add to 14.4.3?]

The renew message can be unicast (IIRC) so the server = can't make a
determination as to the validity of the = prefix.

        =         =                _MelloN_

------_=_NextPart_001_01C10FDB.1A647450-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 18:53:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25261; Wed, 18 Jul 2001 18:53:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IMs1L32211; Wed, 18 Jul 2001 18:54:02 -0400 (EDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IMrpL20031 for ; Wed, 18 Jul 2001 18:53:51 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel2.hp.com (Postfix) with ESMTP id CCBA97FC for ; Wed, 18 Jul 2001 15:53:46 -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 EAA23138 for ; Thu, 19 Jul 2001 04:20:47 +0530 (IST) Reply-To: From: "Vijay Bhaskar A K" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 19 Jul 2001 04:23:39 +0530 Message-ID: <009301c10fdc$7cc854d0$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0094_01C1100A.968090D0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <66F66129A77AD411B76200508B65AC697B32BE@eambunt705.ena-east.ericsson.se> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------=_NextPart_000_0094_01C1100A.968090D0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] -----Original Message----- From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On Behalf Of Bernie Volz (EUD) Sent: Wednesday, July 18, 2001 8:31 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] Ralph, et al: Here's proposed text for dealing with the DHCPNACK issue. Ted and I exchanged messages on this text and I've used most of Ted's feedback here - though Ted has not seen this latest round. 1) Add to section 7.4.2: |NoPrefixMatch_|26______|_An addr in IA not valid for prefix_|_ [Vijay Bhaskar A K] ********* The format of "Error Code" option is not specified in the draft. It is needed to be included. 2) Add to 14.4.1, 14.4.2, 14.4.4: If the server finds that the prefix on one or more IP addresses in any IA in the {Request,Confirm,Rebind} message is not a valid prefix for the link to which the client is connected, the server MUST send an NoPrefixMatch status in the IA status field for that IA in the DHCP Reply message. [Should we include Renew in the message list and add to 14.4.3?] [Vijay Bhaskar A K] **************** It will be better, if this functionality can be incorporated in the agent,since, it is the only thing which knows well about the prefix in which the client message is received. And the advantage is, if this checking is done, this packet can be prevented from forwarding it to the multiple servers and save multiple processing time. The agent itself can send the NoPrefixMatch status directly to the client. 3) Add to Section 14.3.5. (Receipt of Reply message in response to a Request, Confirm, Renew or Rebind message): When the client receives a NoPrefixMatch error status in the IA status field of a Reply to a Confirm message, the client MUST make a determination as to whether it has moved to a different link. If the client is unable to make such a determination it MUST assume that it has moved to a new link. In this case the client MAY discard the IA that received the NoPrefixMatch status, or may retain it as long as the addresses in the IA continue to be valid. [Vijay Bhaskar A K] ********* If the client is receiving the error status as NoPrefixMatch error, what may be the reason other than client's plugging in to different subnet. I agree that, some roghe server can send this status, but, it can be prevented by authentication. 4) Add somewhere (perhaps in 18.3, Identity Associatin Option): The client MUST NOT send any address in an IA once that address' valid lifetime has expired. [Vijay Bhaskar A K] ********** Is there any reason in doing this specifically? Any how, the server is going to delete the expired leases, then what way it is going to make difference? - Bernie (and Ted) ------=_NextPart_000_0094_01C1100A.968090D0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]
 
-----Original Message-----
From: = owner-dhcp-v6@bucknell.edu=20 [mailto:owner-dhcp-v6@bucknell.edu]On Behalf Of Bernie Volz=20 (EUD)
Sent: Wednesday, July 18, 2001 8:31 PM
To: = DHCPv6=20 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed = Draft=20 Changes]

Ralph, et al:

Here's proposed text for = dealing with the=20 DHCPNACK issue. Ted and I
exchanged=20 messages on this text and I've used most of Ted's feedback =
here - though Ted has not seen this = latest=20 round.

1) Add to section 7.4.2: =

   = |NoPrefixMatch_|26______|_An=20 addr in IA not valid for prefix_|_
[Vijay Bhaskar = A=20 K] *********

The = format of=20 "Error Code" option is not specified in the draft. It is needed = to be=20 included. 

2) Add to 14.4.1, 14.4.2, = 14.4.4:=20

   If the server = finds that the=20 prefix on one or more IP addresses in
   any IA in the {Request,Confirm,Rebind} message = is not a=20 valid
   = prefix for the=20 link to which the client is connected, the server
   MUST send an NoPrefixMatch = status in=20 the IA status field for that
   IA in the DHCP Reply message.

   [Should we include = Renew in=20 the message list and add to 14.4.3?]
[Vijay Bhaskar = A=20 K] ****************

It = will be=20 better, if this functionality can be incorporated in the = agent,since, it=20 is the only thing which knows well about the prefix in which the = client=20 message is received. And the advantage is, if this checking is done,=20 this packet can be prevented from forwarding it to the = multiple=20 servers and save multiple processing time. The agent itself can send=20 the NoPrefixMatch status directly to the = client.

3)=20 Add to Section 14.3.5. (Receipt of Reply message in response =
   to a Request, Confirm, = Renew or Rebind=20 message):

   When the client = receives a=20 NoPrefixMatch error status in the IA status
   field of a Reply to a = Confirm message,=20 the client MUST make a
  =20 determination as to whether it has moved to a different link.  If = the
   client = is unable=20 to make such a determination it MUST assume that it
   has moved to a new = link.  In this=20 case the client MAY discard the IA
   that received the NoPrefixMatch status, or may = retain it=20 as long as
   = the=20 addresses in the IA continue to be valid.
[Vijay Bhaskar = A=20 K] *********

If = the=20 client is receiving the error status as NoPrefixMatch error, what = may be=20 the reason other than client's plugging in to different = subnet. I=20 agree that, some roghe server can send this status, but, it can be = prevented=20 by authentication. 

4) Add somewhere (perhaps in = 18.3, Identity=20 Associatin Option):

   The client MUST = NOT send any=20 address in an IA once that address'
   valid lifetime has expired.
[Vijay Bhaskar = A=20 K] **********

Is = there any=20 reason in doing this specifically? Any how, the server = is going to=20 delete the expired leases, then what way it is going to make=20 difference?

 

- Bernie (and Ted)=20

------=_NextPart_000_0094_01C1100A.968090D0-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 18:55:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25497; Wed, 18 Jul 2001 18:55:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IMtUL23254; Wed, 18 Jul 2001 18:55:30 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IMtIL04545 for ; Wed, 18 Jul 2001 18:55:19 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6IMp6f15116 for ; Wed, 18 Jul 2001 15:51:06 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6IMp2w00814 for ; Wed, 18 Jul 2001 15:51:02 -0700 (MST) Message-Id: <200107182251.f6IMp2w00814@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 18 Jul 2001 17:43:45 EST." <66F66129A77AD411B76200508B65AC697B32CB@eambunt705.ena-east.ericsson.se> Date: Wed, 18 Jul 2001 15:51:02 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN IIRC = If I Recall Correctly > What difference does that make? A Release or Decline can be unicast as well > (if the client has another address - in a different IA - than what it is > releasing and the server has told the client it can unicast). The server doesn't need to make a determination as to what link the client is on in the case of Release. Decline probably does need to go through the relay. > Why does *HOW* the packet was sent make any difference? Remember, we're > dealing with MANY addresses so an individual message's IAs have nothing to > do with other IAs (and hence addresses) that client has. If the packet goes through a relay, the relay can say on which link the packet was received. If it is unicast through a router, that is not the case. In the case where it is unicast through a router, therefore, it doesn't make sense to check the prefix - we can only assume that it is correct. In the case where it is not correct, the packet probably wouldn't have gotten to us, and even if it did somehow get to us, we couldn't reply, because our reply will go to the link where the prefix *is* valid. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 18:57:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25998; Wed, 18 Jul 2001 18:57:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IMvNL10237; Wed, 18 Jul 2001 18:57:23 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6IMv5L22224 for ; Wed, 18 Jul 2001 18:57:05 -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 f6IMv5p21851 for ; Wed, 18 Jul 2001 17:57:05 -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 f6IMv5I00555 for ; Wed, 18 Jul 2001 17:57:05 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jul 18 17:57:04 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP20PYZ>; Wed, 18 Jul 2001 17:57:03 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32CC@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses Date: Wed, 18 Jul 2001 17:57:03 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FDC.F5D05EE0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10FDC.F5D05EE0 Content-Type: text/plain; charset="iso-8859-1" Vijay: Removing "addr status" in the IA option without also removing the T bit won't help save bytes since the T bit will require the byte anyway. We might change "addr status" to "unused - MBZ" though if we're not using it. Regarding a new option to handle Temporary Addresses, I think this has merit simply because there has been no way for a client to communicate what kind of addresses it wants. Having this option provides that mechanism. Alternatives, such as allowing 'num-addrs' and thus some address information (T bit) to be specified by the client in a Request were discussed at one point but did not make it into the -19 draft and I'm not sure if it would be in the -20. Perhaps Ralph and Jim will care to provide some indication of how this will be resolved in the -20 draft - to give the client some ability to communicate to the server what it needs. OR, perhaps the answer is simply "no, we're not going to support it - it is up to the server to figure it out." There are some issues with a new option - such as the IAID spaces must not overlap, and then what happens if the wrong option is used with an IAID in a Renew (or Release, ...). So, it gets messy and is probably not the best approach. Your point about graceful renumbering doesn't make sense ... IPv6 (and DHCPV6) already provide for this. I don't think we want addresses to between IA's so I think this concept is a bad one. Just like stateless addresses where lifetimes can be extended, so can they with DHCPv6 (that is either or both the preferred and valid). - Bernie -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, July 18, 2001 6:17 PM To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses Hi, Find my comments inline. ~Vijay > -----Original Message----- > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > Behalf Of Ralph Droms > Sent: Wednesday, July 18, 2001 7:13 PM > To: DHCPv6 discussion list > Subject: Simplify release and decline of addresses > > > Ted suggests a simplification: requiring that all the > addresses in an IA be > released or declined, rather than just some of those > addresses. Ted also > wrote text describing the server behavior in response to a > Decline message > (which is missing from the -19 rev). > > - Ralph > > 14.4.5. Receipt of Release messages > > Upon the receipt of a valid Release message, the server > examines the > IAs and the addresses in the IAs for validity. If the IAs in the > message are in a binding for the client and the addresses > in the IAs > have been assigned by the server to those IA, the server deletes > the addresses from the IAs and makes the addresses available for > assignment to other clients. > > [IMHO, this is too complicated. I think the client should always > release all addresses in an IA - that is, it should just send an empty > IA as described below. Otherwise you get into complexities about how > to back out of an erroneous transaction that I think can't be solved.] Yes. I agree that, the release/decline of addresses as whole IA will simplify the more. So, here,the status field returned will be the same for all the addresses of the IA and it can be very well reflected in IA status. So, do we really need the "addr status" field? Whatever the error status defined can be returned in IA status itself. So, i feel that, we can remove the "addr status" field in IA. It can save many bytes, if the addresses in th IA are very large in number. Another suggestion is, because of handling Temporary address only, we have introduced the "T" bit in IA option. Why can't we define a new option for temporary address IA (TMP_IA). Using this TMP_IA, the client can ask for one or more temporary addresses. The main reason behind is, * The time values T1 and T2 are defined for specifying the time at which the client has to contact the server. But, for the temporary addresses, renewal and rebind is not possible. So, T1 and T2 are not necessary. So, we can remove these fields. * Normally, if the clients are requesting for the normal addresses, they will not be needing temporary addresses. The clients requesting for both will be rare. So, why do we need to put a bit in IA and giving more burden to IA option. So, the TMP_IA option looks like this. 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 TMP_IA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IA status | num-addrs | prefix length | IPv6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | addresses | | (16 octets) +-+-+-+-+-+-+ | | preferred | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | valid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime |IPv6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | addresses | | (16 octets) +-+-+-+-+-+-+ | | preferred | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | valid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ I'm not sure whether there will be an allignment problem. But, we can reduce unnecessary bytes using this option. * One more point to be noted is, a fair implementation of DHCPv6 should support "graceful renumbering". It should provide some grace period to the old prefixes. The deprecated IPv6 addresses (addresses of old prefixes) almost look like the temporary address with preferred life time as 0 and valid life time as 1-2 days. This option will be more useful for handling those deprecated addresses, since those addresses are not supposed to be renewed/rebinded. > > 14.4.5-1/2. Receipt of Decline messages (To be inserted after existing > section 14.4.5 in -19 rev) > > Upon the receipt of a valid Decline message, the server > examines the > IAs and the addresses in the IAs for validity. If any IA in the > message is not an IA that has been assigned by the server to that > client, or if any addresses are mentioned in an IA that were not > assigned by the server to the client, the server MUST NOT further > process the message, but should send a Reply message indicating a > NoBinding status. > > For each IA in the message, if there are any addresses > mentioned in > that IA, the server SHOULD mark each of these addresses as in > conflict and SHOULD NOT make these addresses available for > allocation to other clients. Any addresses that the server has > allocated to that IA but that are not mentioned in the message > SHOULD be made available for assignment to other clients. > > [As above, I would argue that the client should simply send empty IAs, > and let all the addresses be declined. This has the disadvantage > that you can lose addresses that were not in conflict, but it makes > the whole transaction a lot simpler, and I think simplicity is a real > virtue in this case.] > > If an IA is mentioned in the Decline message without any > accompanying addresses, the server SHOULD mark all the > addresses in > the IA as being in conflict, and SHOULD NOT make these addresses > available for immediate assignment to other clients. > > Server implementors SHOULD implement a strategy for reclaiming > these IP addresses if there are no addresses available for > allocation. Server implementors MAY also implement a strategy to > detect a client that is repeatedly allocating and then declining > addresses. When such a client is detected, the server SHOULD > refuse to allocate further addresses to that client for > DECLINE_COOLOFF (see section 7.5) seconds. > > The server then generates a Reply message. If all of the IAs were > valid, the server sets the "status" field to "Success". If any of > the IAs were invalid, the server sets the "status" field to > "NoBinding" (section 7.4). > -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ ------_=_NextPart_001_01C10FDC.F5D05EE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Simplify release and decline of addresses

Vijay:

Removing "addr status" in the IA option = without also removing the T bit
won't help save bytes since the T bit will require = the byte anyway. We
might change "addr status" to "unused = - MBZ" though if we're not using it.

Regarding a new option to handle Temporary Addresses, = I think this has
merit simply because there has been no way for a = client to communicate
what kind of addresses it wants. Having this option = provides that mechanism.
Alternatives, such as allowing 'num-addrs' and thus = some address information
(T bit) to be specified by the client in a Request = were discussed at one
point but did not make it into the -19 draft and I'm = not sure if it would be
in the -20.

Perhaps Ralph and Jim will care to provide some = indication of how this will be
resolved in the -20 draft - to give the client some = ability to communicate to
the server what it needs. OR, perhaps the answer is = simply "no, we're not
going to support it - it is up to the server to = figure it out."

There are some issues with a new option - such as the = IAID spaces must not
overlap, and then what happens if the wrong option = is used with an IAID in
a Renew (or Release, ...). So, it gets messy and is = probably not the best
approach.

Your point about graceful renumbering doesn't make = sense ... IPv6 (and
DHCPV6) already provide for this. I don't think we = want addresses to between
IA's so I think this concept is a bad one. Just like = stateless addresses where
lifetimes can be extended, so can they with DHCPv6 = (that is either or both
the preferred and valid).

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Wednesday, July 18, 2001 6:17 PM
To: DHCPv6 discussion list
Subject: RE: Simplify release and decline of = addresses


Hi,
Find my comments inline.
~Vijay

> -----Original Message-----
> From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell= .edu]On
> Behalf Of Ralph Droms
> Sent: Wednesday, July 18, 2001 7:13 PM
> To: DHCPv6 discussion list
> Subject: Simplify release and decline of = addresses
>
>
> Ted suggests a simplification: requiring that = all the
> addresses in an IA be
> released or declined, rather than just some of = those
> addresses.  Ted also
> wrote text describing the server behavior in = response to a
> Decline message
> (which is missing from the -19 rev).
>
> - Ralph
>
> 14.4.5. Receipt of Release messages
>
>     Upon the receipt of a = valid Release message, the server
> examines the
>     IAs and the addresses = in the IAs for validity.  If the IAs in the
>     message are in a = binding for the client and the addresses
> in the IAs
>     have been assigned by = the server to those IA, the server deletes
>     the addresses from the = IAs and makes the addresses available for
>     assignment to other = clients.
>
> [IMHO, this is too complicated.  I think = the client should always
> release all addresses in an IA - that is, it = should just send an empty
> IA as described below.   Otherwise = you get into complexities about how
> to back out of an erroneous transaction that I = think can't be solved.]

Yes.  I agree that, the  = release/decline  of  addresses as whole IA will
simplify the more.  So, here,the  status = field returned will be the same
for all the addresses of the IA and it can be very = well  reflected in IA
status.  So, do we really need the = "addr  status"  field?  Whatever  = the
error  status  defined can be returned in = IA status  itself.  So, i feel
that, we can  remove  the "addr  = status"  field in IA.  It can save many
bytes, if the addresses in th IA are very large in = number.

Another  suggestion is, because of = handling  Temporary  address only, we
have  introduced  the "T" bit in = IA  option.  Why  can't we define a new
option for temporary address IA (TMP_IA).  = Using this TMP_IA, the client
can ask for one or more temporary addresses.  =

The main reason behind is,

* The time values T1 and T2 are defined for = specifying the time at which
the client has to contact the server.  But, for = the temporary addresses,
renewal  and rebind is not  = possible.  So, T1 and T2 are not  necessary.
So, we can remove these fields.

* Normally, if the clients are requesting for the = normal addresses, they
will not be needing  temporary  = addresses.  The clients  requesting  for
both  will be  rare.  So,  why = do we need to put a bit in IA and  giving
more burden to IA option.

So, the TMP_IA option looks like this.

   = 0            = ;       = 1            = ;       2     &nb= sp;           &nb= sp; 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 = TMP_IA        = |          = option-len          | =
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |            = ;            = IAID (4 = octets)           = ;            = ; |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     |   IA = status   |   num-addrs   | prefix = length  | IPv6         = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|=
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;            = ;  = addresses          &nb= sp;           &nb= sp;     = |         
     = |            = ;            = ;  (16 = octets)           = ;  +-+-+-+-+-+-+
     = |            = ;            = ;            = ;            = ; | preferred   |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            = ;          = lifetime          &nbs= p;        | = valid       |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            = ;           = lifetime          &nbs= p;       = |IPv6         |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|=
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;            = ;  = addresses          &nb= sp;           &nb= sp;     = |         
     = |            = ;            = ;  (16 = octets)           = ;  +-+-+-+-+-+-+
     = |            = ;            = ;            = ;            = ; | preferred   |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            = ;          = lifetime          &nbs= p;        | = valid       |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     = |            = ;           = lifetime          &nbs= p;       |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I'm not sure whether  there will be an = allignment  problem.  But, we can
reduce unnecessary bytes using this option.

* One more point to be noted is, a fair  = implementation of DHCPv6 should
support "graceful  = renumbering".  It should provide some grace period to
the old  prefixes.  The  = deprecated  IPv6  addresses  (addresses  of = old
prefixes)  almost look like the temporary  = address with  preferred  life
time as 0 and valid  life time as 1-2  = days.  This  option  will be more
useful for handling those  deprecated  = addresses,  since those addresses
are not supposed to be renewed/rebinded.

>
> 14.4.5-1/2. Receipt of Decline messages (To be = inserted after existing
>          = ;            = ;            = ;         section 14.4.5 in -19 = rev)
>
>     Upon the receipt of a = valid Decline message, the server
> examines the
>     IAs and the addresses = in the IAs for validity.  If any IA in the
>     message is not an IA = that has been assigned by the server to that
>     client, or if any = addresses are mentioned in an IA that were not
>     assigned by the server = to the client, the server MUST NOT further
>     process the message, = but should send a Reply message indicating a
>     NoBinding = status.
>
>     For each IA in the = message, if there are any addresses
> mentioned in
>     that IA, the server = SHOULD mark each of these addresses as in
>     conflict and SHOULD NOT = make these addresses available for
>     allocation to other = clients.  Any addresses that the server has
>     allocated to that IA = but that are not mentioned in the message
>     SHOULD be made = available for assignment to other clients.
>
> [As above, I would argue that the client should = simply send empty IAs,
> and let all the addresses be = declined.   This has the disadvantage
> that you can lose addresses that were not in = conflict, but it makes
> the whole transaction a lot simpler, and I = think simplicity is a real
> virtue in this case.]
>
>     If an IA is mentioned = in the Decline message without any
>     accompanying addresses, = the server SHOULD mark all the
> addresses in
>     the IA as being in = conflict, and SHOULD NOT make these addresses
>     available for immediate = assignment to other clients.
>
>     Server implementors = SHOULD implement a strategy for reclaiming
>     these IP addresses if = there are no addresses available for
>     allocation.   = Server implementors MAY also implement a strategy to
>     detect a client that is = repeatedly allocating and then declining
>     addresses.   = When such a client is detected, the server SHOULD
>     refuse to allocate = further addresses to that client for
>     DECLINE_COOLOFF (see = section 7.5) seconds.
>
>     The server then = generates a Reply message.  If all of the IAs were
>     valid, the server sets = the "status" field to "Success".  If any = of
>     the IAs were invalid, = the server sets the "status" field to
>     "NoBinding" = (section 7.4).
>

--
____Vijay_Bhaskar_A_K____
______Inet_Services______
________HP_ISO___________
____Ph:_2251554_1424_____
___Pager:_9624_371137____

------_=_NextPart_001_01C10FDC.F5D05EE0-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:10:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29001; Wed, 18 Jul 2001 19:10:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INALL02334; Wed, 18 Jul 2001 19:10:21 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INAAL24175 for ; Wed, 18 Jul 2001 19:10:11 -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 f6INAAp25610 for ; Wed, 18 Jul 2001 18:10:10 -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 f6INAAc12146 for ; Wed, 18 Jul 2001 18:10:10 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Jul 18 18:10:09 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP20QL3>; Wed, 18 Jul 2001 18:10:09 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32CD@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Wed, 18 Jul 2001 18:10:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FDE.C96E7420" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10FDE.C96E7420 Content-Type: text/plain; charset="iso-8859-1" OK. I understand your point. BTW, I was originally thinking that only the Reply to a Confirm message would do this prefix checking and hence return a NoPrefixMatch status. But, even that would not have been safe. Note that text for the "Server Unicast Option": "This option is used by a server to send to a client to inform the client it can send a Request, Renew, Confirm, Release, and Decline by unicasting directly to the server instead of the All DHCPv6 Agents multicast adress as an optimization." I think we need to change this OR we need to add a statement to the prefix checking that prohibits it if the server can't tell where the client is. Now, this raises the nasty issue of if the client unicasts a message, how does the server reply to it (I already raised this issue). One solution is to use the IPv6 Source Address - but that has problems since then why not always use it? Another is for the server to save information on how to reach the client (which it might need to do anyway to send it Reconfigure-Inits?) via a Relay (or directly if on-link). But this is messy and what if the client has moved (I guess you could argue then it might not need to be Reconfigured)? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 6:51 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] IIRC = If I Recall Correctly > What difference does that make? A Release or Decline can be unicast as well > (if the client has another address - in a different IA - than what it is > releasing and the server has told the client it can unicast). The server doesn't need to make a determination as to what link the client is on in the case of Release. Decline probably does need to go through the relay. > Why does *HOW* the packet was sent make any difference? Remember, we're > dealing with MANY addresses so an individual message's IAs have nothing to > do with other IAs (and hence addresses) that client has. If the packet goes through a relay, the relay can say on which link the packet was received. If it is unicast through a router, that is not the case. In the case where it is unicast through a router, therefore, it doesn't make sense to check the prefix - we can only assume that it is correct. In the case where it is not correct, the packet probably wouldn't have gotten to us, and even if it did somehow get to us, we couldn't reply, because our reply will go to the link where the prefix *is* valid. _MelloN_ ------_=_NextPart_001_01C10FDE.C96E7420 Content-Type: text/html; charset="iso-8859-1" RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

OK. I understand your point.

BTW, I was originally thinking that only the Reply to a Confirm message
would do this prefix checking and hence return a NoPrefixMatch status.

But, even that would not have been safe. Note that text for the "Server
Unicast Option":

        "This option is used by a server to send to a client to inform the
        client it can send a Request, Renew, Confirm, Release, and Decline
        by unicasting directly to the server instead of the All DHCPv6 Agents
        multicast adress as an optimization."

I think we need to change this OR we need to add a statement to the prefix
checking that prohibits it if the server can't tell where the client is.

Now, this raises the nasty issue of if the client unicasts a message, how
does the server reply to it (I already raised this issue). One solution is
to use the IPv6 Source Address - but that has problems since then why not
always use it? Another is for the server to save information on how to reach
the client (which it might need to do anyway to send it Reconfigure-Inits?)
via a Relay (or directly if on-link). But this is messy and what if the
client has moved (I guess you could argue then it might not need to be
Reconfigured)?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, July 18, 2001 6:51 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]



IIRC = If I Recall Correctly

> What difference does that make? A Release or Decline can be unicast as well
> (if the client has another address - in a different IA - than what it is
> releasing and the server has told the client it can unicast).

The server doesn't need to make a determination as to what link the
client is on in the case of Release.   Decline probably does need to
go through the relay.

> Why does *HOW* the packet was sent make any difference? Remember, we're
> dealing with MANY addresses so an individual message's IAs have nothing to
> do with other IAs (and hence addresses) that client has.

If the packet goes through a relay, the relay can say on which link
the packet was received.  If it is unicast through a router, that is
not the case.  In the case where it is unicast through a router,
therefore, it doesn't make sense to check the prefix - we can only
assume that it is correct.  In the case where it is not correct, the
packet probably wouldn't have gotten to us, and even if it did somehow
get to us, we couldn't reply, because our reply will go to the link
where the prefix *is* valid.

                               _MelloN_

------_=_NextPart_001_01C10FDE.C96E7420-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:13:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00077; Wed, 18 Jul 2001 19:13:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6IND0L07030; Wed, 18 Jul 2001 19:13:00 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INCqL12050 for ; Wed, 18 Jul 2001 19:12:52 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6IN8ef15158; Wed, 18 Jul 2001 16:08:40 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6IN8Zw00843; Wed, 18 Jul 2001 16:08:35 -0700 (MST) Message-Id: <200107182308.f6IN8Zw00843@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from "Vijay Bhaskar A K" of "Thu, 19 Jul 2001 04:23:39 +0530." <009301c10fdc$7cc854d0$2f290a0f@india.hp.com> Date: Wed, 18 Jul 2001 16:08:35 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The format of "Error Code" option is not specified in the draft. It is > needed to be included. I think it goes into the IA option, but you're right - it needs to be clarified. > It will be better, if this functionality can be incorporated in the > agent,since, it is the only thing which knows well about the prefix in which > the client message is received. And the advantage is, if this checking is > done, this packet can be prevented from forwarding it to the multiple > servers and save multiple processing time. The agent itself can send the > NoPrefixMatch status directly to the client. Ooh, good point! I think it would be good if the agent could do this, although I have to admit that I am concerned that some people who implement relay agents may not want to have to delve into the IA to validate a packet. I'm in favor of doing as you suggest, but I suggest that we defer to the working group to see if any router vendors have a problem with this. Also, the timing is a bit tight on making this change, and I wouldn't blame the authors if they said "no, sorry, do this in a new draft." I think it's okay to make this optional, so doing it in a seperate draft should be fine. > If the client is receiving the error status as NoPrefixMatch error, what > may be the reason other than client's plugging in to different subnet. I > agree that, some roghe server can send this status, but, it can be prevented > by authentication. The client may be mobile, and may be able to reach more than one mobile access point. The two access points may want to think of themselves as seperate links, even though their physical link-layers overlap. I don't know how likely this is with existing technology, but it's certainly been discussed with respect to 3G phones. I think it's important to leave the language open for this case. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:15:48 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00850; Wed, 18 Jul 2001 19:15:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6ING9L17664; Wed, 18 Jul 2001 19:16:09 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INFsL16176 for ; Wed, 18 Jul 2001 19:15:54 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6INFd511625 for ; Wed, 18 Jul 2001 18:15:39 -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 f6INFcc13545 for ; Wed, 18 Jul 2001 18:15:38 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jul 18 18:15:37 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP20QW2>; Wed, 18 Jul 2001 18:15:37 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32CE@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Wed, 18 Jul 2001 18:15:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FDF.8D6402F0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10FDF.8D6402F0 Content-Type: text/plain; charset="iso-8859-1" One more comment ... in some cases (agreed not all) a server *CAN* determine that a prefix is invalid in its domain regardless of where the client actually is. For example, if a server receives a Confirm for a global prefix it has no knowledge of, why does it care where it came from? If it can send a Reply back to the client, it can tell it - hey, you're using invalid prefixes. If relays are configured incorrectly and forwarding packets to where they shouldn't be going, that's not the servers fault. Again, the entire point of the NoPrefixMatch is to tell the client quickly that it may have moved. So, one bad prefix in a list of addresses (regardless of whether that server even has any knowledge of that client or that IA) is sufficient to communicate that to the client quickly and effectively. Just returning NoBinding or another error doesn't help the client at all. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 6:51 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] IIRC = If I Recall Correctly > What difference does that make? A Release or Decline can be unicast as well > (if the client has another address - in a different IA - than what it is > releasing and the server has told the client it can unicast). The server doesn't need to make a determination as to what link the client is on in the case of Release. Decline probably does need to go through the relay. > Why does *HOW* the packet was sent make any difference? Remember, we're > dealing with MANY addresses so an individual message's IAs have nothing to > do with other IAs (and hence addresses) that client has. If the packet goes through a relay, the relay can say on which link the packet was received. If it is unicast through a router, that is not the case. In the case where it is unicast through a router, therefore, it doesn't make sense to check the prefix - we can only assume that it is correct. In the case where it is not correct, the packet probably wouldn't have gotten to us, and even if it did somehow get to us, we couldn't reply, because our reply will go to the link where the prefix *is* valid. _MelloN_ ------_=_NextPart_001_01C10FDF.8D6402F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

One more comment ... in some cases (agreed not all) a = server *CAN* determine
that a prefix is invalid in its domain regardless of = where the client actually
is.

For example, if a server receives a Confirm for a = global prefix it has no
knowledge of, why does it care where it came from? = If it can send a Reply
back to the client, it can tell it - hey, you're = using invalid prefixes.

If relays are configured incorrectly and forwarding = packets to where they
shouldn't be going, that's not the servers = fault.

Again, the entire point of the NoPrefixMatch is to = tell the client quickly
that it may have moved. So, one bad prefix in a list = of addresses (regardless
of whether that server even has any knowledge of = that client or that IA) is
sufficient to communicate that to the client quickly = and effectively.

Just returning NoBinding or another error doesn't = help the client at all.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Wednesday, July 18, 2001 6:51 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft = Changes]



IIRC =3D If I Recall Correctly

> What difference does that make? A Release or = Decline can be unicast as well
> (if the client has another address - in a = different IA - than what it is
> releasing and the server has told the client it = can unicast).

The server doesn't need to make a determination as to = what link the
client is on in the case of Release.   = Decline probably does need to
go through the relay.

> Why does *HOW* the packet was sent make any = difference? Remember, we're
> dealing with MANY addresses so an individual = message's IAs have nothing to
> do with other IAs (and hence addresses) that = client has.

If the packet goes through a relay, the relay can say = on which link
the packet was received.  If it is unicast = through a router, that is
not the case.  In the case where it is unicast = through a router,
therefore, it doesn't make sense to check the prefix = - we can only
assume that it is correct.  In the case where = it is not correct, the
packet probably wouldn't have gotten to us, and even = if it did somehow
get to us, we couldn't reply, because our reply will = go to the link
where the prefix *is* valid.

        =         =                _MelloN_

------_=_NextPart_001_01C10FDF.8D6402F0-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:18:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA01937; Wed, 18 Jul 2001 19:18:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INJ8L18951; Wed, 18 Jul 2001 19:19:08 -0400 (EDT) Received: from mail-gw01.gap.com ([206.16.32.97]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INIsL22719 for ; Wed, 18 Jul 2001 19:18:54 -0400 (EDT) Received: from mailhub01.gap.com (mailhub01.gap.com [9.32.202.151]) by mail-gw01.gap.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA07487 for ; Wed, 18 Jul 2001 16:18:13 -0700 (PDT) From: Relfe_Tan@gap.com Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43]) by mailhub01.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id QAA20023 for ; Wed, 18 Jul 2001 16:18:46 -0700 (PDT) Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A8D.007FA0A5 ; Wed, 18 Jul 2001 16:14:01 -0700 X-Lotus-FromDomain: GAPINC To: DHCPv6 discussion list Message-ID: <88256A8D.007F9FF9.00@smtpmta01.gap.com> Date: Wed, 18 Jul 2001 16:16:36 -0700 Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=USoBXHmwJAyskJRxsJPXOvNReQFMlL8bxQ5n5rzZws324t39gZAiluP5" Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --0__=USoBXHmwJAyskJRxsJPXOvNReQFMlL8bxQ5n5rzZws324t39gZAiluP5 Content-type: text/plain; charset=us-ascii Content-Disposition: inline unsubscribe "Bernie Volz (EUD)" on 07/18/2001 04:10:07 PM Please respond to dhcp-v6@bucknell.edu To: "DHCPv6 discussion list" cc: (bcc: Relfe Tan/SB/GAPINC) Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] OK. I understand your point. BTW, I was originally thinking that only the Reply to a Confirm message would do this prefix checking and hence return a NoPrefixMatch status. But, even that would not have been safe. Note that text for the "Server Unicast Option": "This option is used by a server to send to a client to inform the client it can send a Request, Renew, Confirm, Release, and Decline by unicasting directly to the server instead of the All DHCPv6 Agents multicast adress as an optimization." I think we need to change this OR we need to add a statement to the prefix checking that prohibits it if the server can't tell where the client is. Now, this raises the nasty issue of if the client unicasts a message, how does the server reply to it (I already raised this issue). One solution is to use the IPv6 Source Address - but that has problems since then why not always use it? Another is for the server to save information on how to reach the client (which it might need to do anyway to send it Reconfigure-Inits?) via a Relay (or directly if on-link). But this is messy and what if the client has moved (I guess you could argue then it might not need to be Reconfigured)? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 6:51 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] IIRC = If I Recall Correctly > What difference does that make? A Release or Decline can be unicast as well > (if the client has another address - in a different IA - than what it is > releasing and the server has told the client it can unicast). The server doesn't need to make a determination as to what link the client is on in the case of Release. Decline probably does need to go through the relay. > Why does *HOW* the packet was sent make any difference? Remember, we're > dealing with MANY addresses so an individual message's IAs have nothing to > do with other IAs (and hence addresses) that client has. If the packet goes through a relay, the relay can say on which link the packet was received. If it is unicast through a router, that is not the case. In the case where it is unicast through a router, therefore, it doesn't make sense to check the prefix - we can only assume that it is correct. In the case where it is not correct, the packet probably wouldn't have gotten to us, and even if it did somehow get to us, we couldn't reply, because our reply will go to the link where the prefix *is* valid. _MelloN_ --0__=USoBXHmwJAyskJRxsJPXOvNReQFMlL8bxQ5n5rzZws324t39gZAiluP5 Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC4xOSI+DQo8VElUTEU+UkU6IERI Q1BOQUNLIGZvciBESENQdjYgW1Byb3Bvc2VkIERyYWZ0IENoYW5nZXNdIDwvVElUTEU+DQo8L0hF QUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPk9LLiBJIHVuZGVyc3RhbmQgeW91ciBwb2lu dC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5CVFcsIEkgd2FzIG9yaWdpbmFsbHkg dGhpbmtpbmcgdGhhdCBvbmx5IHRoZSBSZXBseSB0byBhIENvbmZpcm0gbWVzc2FnZTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+d291bGQgZG8gdGhpcyBwcmVmaXggY2hlY2tpbmcgYW5kIGhlbmNl IHJldHVybiBhIE5vUHJlZml4TWF0Y2ggc3RhdHVzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPkJ1dCwgZXZlbiB0aGF0IHdvdWxkIG5vdCBoYXZlIGJlZW4gc2FmZS4gTm90ZSB0aGF0 IHRleHQgZm9yIHRoZSAmcXVvdDtTZXJ2ZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlVuaWNh c3QgT3B0aW9uJnF1b3Q7OjwvRk9OVD4NCjwvUD4NCg0KPFA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIFNJWkU9Mj4mcXVvdDtUaGlzIG9wdGlvbiBpcyB1 c2VkIGJ5IGEgc2VydmVyIHRvIHNlbmQgdG8gYSBjbGllbnQgdG8gaW5mb3JtIHRoZTwvRk9OVD4N CjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0la RT0yPmNsaWVudCBpdCBjYW4gc2VuZCBhIFJlcXVlc3QsIFJlbmV3LCBDb25maXJtLCBSZWxlYXNl LCBhbmQgRGVjbGluZTwvRk9OVD4NCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPmJ5IHVuaWNhc3RpbmcgZGlyZWN0bHkgdG8gdGhlIHNl cnZlciBpbnN0ZWFkIG9mIHRoZSBBbGwgREhDUHY2IEFnZW50czwvRk9OVD4NCjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPm11bHRpY2Fz dCBhZHJlc3MgYXMgYW4gb3B0aW1pemF0aW9uLiZxdW90OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkkgdGhpbmsgd2UgbmVlZCB0byBjaGFuZ2UgdGhpcyBPUiB3ZSBuZWVkIHRvIGFk ZCBhIHN0YXRlbWVudCB0byB0aGUgcHJlZml4PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5jaGVj a2luZyB0aGF0IHByb2hpYml0cyBpdCBpZiB0aGUgc2VydmVyIGNhbid0IHRlbGwgd2hlcmUgdGhl IGNsaWVudCBpcy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Ob3csIHRoaXMgcmFp c2VzIHRoZSBuYXN0eSBpc3N1ZSBvZiBpZiB0aGUgY2xpZW50IHVuaWNhc3RzIGEgbWVzc2FnZSwg aG93PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5kb2VzIHRoZSBzZXJ2ZXIgcmVwbHkgdG8gaXQg KEkgYWxyZWFkeSByYWlzZWQgdGhpcyBpc3N1ZSkuIE9uZSBzb2x1dGlvbiBpczwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+dG8gdXNlIHRoZSBJUHY2IFNvdXJjZSBBZGRyZXNzIC0gYnV0IHRoYXQg aGFzIHByb2JsZW1zIHNpbmNlIHRoZW4gd2h5IG5vdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ YWx3YXlzIHVzZSBpdD8gQW5vdGhlciBpcyBmb3IgdGhlIHNlcnZlciB0byBzYXZlIGluZm9ybWF0 aW9uIG9uIGhvdyB0byByZWFjaDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlIGNsaWVudCAo d2hpY2ggaXQgbWlnaHQgbmVlZCB0byBkbyBhbnl3YXkgdG8gc2VuZCBpdCBSZWNvbmZpZ3VyZS1J bml0cz8pPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj52aWEgYSBSZWxheSAob3IgZGlyZWN0bHkg aWYgb24tbGluaykuIEJ1dCB0aGlzIGlzIG1lc3N5IGFuZCB3aGF0IGlmIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGhhcyBtb3ZlZCAoSSBndWVzcyB5b3UgY291bGQgYXJndWUg dGhlbiBpdCBtaWdodCBub3QgbmVlZCB0byBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UmVj b25maWd1cmVkKT88L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tIEJlcm5pZTwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBUZWQgTGVtb24gWzxBIEhSRUY9Im1haWx0bzpt ZWxsb25Abm9taW51bS5jb20iPm1haWx0bzptZWxsb25Abm9taW51bS5jb208L0E+XTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+U2VudDogV2VkbmVzZGF5LCBKdWx5IDE4LCAyMDAxIDY6NTEgUE08 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBESENQdjYgZGlzY3Vzc2lvbiBsaXN0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSZTogREhDUE5BQ0sgZm9yIERIQ1B2NiBbUHJv cG9zZWQgRHJhZnQgQ2hhbmdlc10gPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9O VCBTSVpFPTI+SUlSQyA9IElmIEkgUmVjYWxsIENvcnJlY3RseTwvRk9OVD4NCjwvUD4NCg0KPFA+ PEZPTlQgU0laRT0yPiZndDsgV2hhdCBkaWZmZXJlbmNlIGRvZXMgdGhhdCBtYWtlPyBBIFJlbGVh c2Ugb3IgRGVjbGluZSBjYW4gYmUgdW5pY2FzdCBhcyB3ZWxsPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IChpZiB0aGUgY2xpZW50IGhhcyBhbm90aGVyIGFkZHJlc3MgLSBpbiBhIGRpZmZl cmVudCBJQSAtIHRoYW4gd2hhdCBpdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBy ZWxlYXNpbmcgYW5kIHRoZSBzZXJ2ZXIgaGFzIHRvbGQgdGhlIGNsaWVudCBpdCBjYW4gdW5pY2Fz dCkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIHNlcnZlciBkb2Vzbid0IG5l ZWQgdG8gbWFrZSBhIGRldGVybWluYXRpb24gYXMgdG8gd2hhdCBsaW5rIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGlzIG9uIGluIHRoZSBjYXNlIG9mIFJlbGVhc2UuJm5ic3A7 Jm5ic3A7IERlY2xpbmUgcHJvYmFibHkgZG9lcyBuZWVkIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5nbyB0aHJvdWdoIHRoZSByZWxheS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj4mZ3Q7IFdoeSBkb2VzICpIT1cqIHRoZSBwYWNrZXQgd2FzIHNlbnQgbWFrZSBhbnkgZGlmZmVy ZW5jZT8gUmVtZW1iZXIsIHdlJ3JlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRlYWxp bmcgd2l0aCBNQU5ZIGFkZHJlc3NlcyBzbyBhbiBpbmRpdmlkdWFsIG1lc3NhZ2UncyBJQXMgaGF2 ZSBub3RoaW5nIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRvIHdpdGggb3RoZXIg SUFzIChhbmQgaGVuY2UgYWRkcmVzc2VzKSB0aGF0IGNsaWVudCBoYXMuPC9GT05UPg0KPC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+SWYgdGhlIHBhY2tldCBnb2VzIHRocm91Z2ggYSByZWxheSwgdGhl IHJlbGF5IGNhbiBzYXkgb24gd2hpY2ggbGluazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhl IHBhY2tldCB3YXMgcmVjZWl2ZWQuJm5ic3A7IElmIGl0IGlzIHVuaWNhc3QgdGhyb3VnaCBhIHJv dXRlciwgdGhhdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+bm90IHRoZSBjYXNlLiZuYnNw OyBJbiB0aGUgY2FzZSB3aGVyZSBpdCBpcyB1bmljYXN0IHRocm91Z2ggYSByb3V0ZXIsPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj50aGVyZWZvcmUsIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBj aGVjayB0aGUgcHJlZml4IC0gd2UgY2FuIG9ubHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmFz c3VtZSB0aGF0IGl0IGlzIGNvcnJlY3QuJm5ic3A7IEluIHRoZSBjYXNlIHdoZXJlIGl0IGlzIG5v dCBjb3JyZWN0LCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnBhY2tldCBwcm9iYWJseSB3 b3VsZG4ndCBoYXZlIGdvdHRlbiB0byB1cywgYW5kIGV2ZW4gaWYgaXQgZGlkIHNvbWVob3c8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmdldCB0byB1cywgd2UgY291bGRuJ3QgcmVwbHksIGJlY2F1 c2Ugb3VyIHJlcGx5IHdpbGwgZ28gdG8gdGhlIGxpbms8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PndoZXJlIHRoZSBwcmVmaXggKmlzKiB2YWxpZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg X01lbGxvTl88L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=USoBXHmwJAyskJRxsJPXOvNReQFMlL8bxQ5n5rzZws324t39gZAiluP5-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:18:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02021; Wed, 18 Jul 2001 19:18:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INJFL06670; Wed, 18 Jul 2001 19:19:15 -0400 (EDT) Received: from mail-gw01.gap.com ([206.16.32.97]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INIxL01883 for ; Wed, 18 Jul 2001 19:18:59 -0400 (EDT) Received: from mailhub01.gap.com (mailhub01.gap.com [9.32.202.151]) by mail-gw01.gap.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA07508 for ; Wed, 18 Jul 2001 16:18:18 -0700 (PDT) From: Relfe_Tan@gap.com Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43]) by mailhub01.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id QAA20040 for ; Wed, 18 Jul 2001 16:18:51 -0700 (PDT) Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A8D.007F9A12 ; Wed, 18 Jul 2001 16:13:45 -0700 X-Lotus-FromDomain: GAPINC To: DHCPv6 discussion list Message-ID: <88256A8D.007F9944.00@smtpmta01.gap.com> Date: Wed, 18 Jul 2001 16:16:13 -0700 Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=q7KkifzO4ict1lG2vlKJokQIkcm037H5ZShx8Djw088UKypocI4KUfld" Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --0__=q7KkifzO4ict1lG2vlKJokQIkcm037H5ZShx8Djw088UKypocI4KUfld Content-type: text/plain; charset=us-ascii Content-Disposition: inline unsubscribe "Bernie Volz (EUD)" on 07/18/2001 04:10:07 PM Please respond to dhcp-v6@bucknell.edu To: "DHCPv6 discussion list" cc: (bcc: Relfe Tan/SB/GAPINC) Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] OK. I understand your point. BTW, I was originally thinking that only the Reply to a Confirm message would do this prefix checking and hence return a NoPrefixMatch status. But, even that would not have been safe. Note that text for the "Server Unicast Option": "This option is used by a server to send to a client to inform the client it can send a Request, Renew, Confirm, Release, and Decline by unicasting directly to the server instead of the All DHCPv6 Agents multicast adress as an optimization." I think we need to change this OR we need to add a statement to the prefix checking that prohibits it if the server can't tell where the client is. Now, this raises the nasty issue of if the client unicasts a message, how does the server reply to it (I already raised this issue). One solution is to use the IPv6 Source Address - but that has problems since then why not always use it? Another is for the server to save information on how to reach the client (which it might need to do anyway to send it Reconfigure-Inits?) via a Relay (or directly if on-link). But this is messy and what if the client has moved (I guess you could argue then it might not need to be Reconfigured)? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 6:51 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] IIRC = If I Recall Correctly > What difference does that make? A Release or Decline can be unicast as well > (if the client has another address - in a different IA - than what it is > releasing and the server has told the client it can unicast). The server doesn't need to make a determination as to what link the client is on in the case of Release. Decline probably does need to go through the relay. > Why does *HOW* the packet was sent make any difference? Remember, we're > dealing with MANY addresses so an individual message's IAs have nothing to > do with other IAs (and hence addresses) that client has. If the packet goes through a relay, the relay can say on which link the packet was received. If it is unicast through a router, that is not the case. In the case where it is unicast through a router, therefore, it doesn't make sense to check the prefix - we can only assume that it is correct. In the case where it is not correct, the packet probably wouldn't have gotten to us, and even if it did somehow get to us, we couldn't reply, because our reply will go to the link where the prefix *is* valid. _MelloN_ --0__=q7KkifzO4ict1lG2vlKJokQIkcm037H5ZShx8Djw088UKypocI4KUfld Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC4xOSI+DQo8VElUTEU+UkU6IERI Q1BOQUNLIGZvciBESENQdjYgW1Byb3Bvc2VkIERyYWZ0IENoYW5nZXNdIDwvVElUTEU+DQo8L0hF QUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPk9LLiBJIHVuZGVyc3RhbmQgeW91ciBwb2lu dC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5CVFcsIEkgd2FzIG9yaWdpbmFsbHkg dGhpbmtpbmcgdGhhdCBvbmx5IHRoZSBSZXBseSB0byBhIENvbmZpcm0gbWVzc2FnZTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+d291bGQgZG8gdGhpcyBwcmVmaXggY2hlY2tpbmcgYW5kIGhlbmNl IHJldHVybiBhIE5vUHJlZml4TWF0Y2ggc3RhdHVzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPkJ1dCwgZXZlbiB0aGF0IHdvdWxkIG5vdCBoYXZlIGJlZW4gc2FmZS4gTm90ZSB0aGF0 IHRleHQgZm9yIHRoZSAmcXVvdDtTZXJ2ZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlVuaWNh c3QgT3B0aW9uJnF1b3Q7OjwvRk9OVD4NCjwvUD4NCg0KPFA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIFNJWkU9Mj4mcXVvdDtUaGlzIG9wdGlvbiBpcyB1 c2VkIGJ5IGEgc2VydmVyIHRvIHNlbmQgdG8gYSBjbGllbnQgdG8gaW5mb3JtIHRoZTwvRk9OVD4N CjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0la RT0yPmNsaWVudCBpdCBjYW4gc2VuZCBhIFJlcXVlc3QsIFJlbmV3LCBDb25maXJtLCBSZWxlYXNl LCBhbmQgRGVjbGluZTwvRk9OVD4NCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPmJ5IHVuaWNhc3RpbmcgZGlyZWN0bHkgdG8gdGhlIHNl cnZlciBpbnN0ZWFkIG9mIHRoZSBBbGwgREhDUHY2IEFnZW50czwvRk9OVD4NCjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPm11bHRpY2Fz dCBhZHJlc3MgYXMgYW4gb3B0aW1pemF0aW9uLiZxdW90OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkkgdGhpbmsgd2UgbmVlZCB0byBjaGFuZ2UgdGhpcyBPUiB3ZSBuZWVkIHRvIGFk ZCBhIHN0YXRlbWVudCB0byB0aGUgcHJlZml4PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5jaGVj a2luZyB0aGF0IHByb2hpYml0cyBpdCBpZiB0aGUgc2VydmVyIGNhbid0IHRlbGwgd2hlcmUgdGhl IGNsaWVudCBpcy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Ob3csIHRoaXMgcmFp c2VzIHRoZSBuYXN0eSBpc3N1ZSBvZiBpZiB0aGUgY2xpZW50IHVuaWNhc3RzIGEgbWVzc2FnZSwg aG93PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5kb2VzIHRoZSBzZXJ2ZXIgcmVwbHkgdG8gaXQg KEkgYWxyZWFkeSByYWlzZWQgdGhpcyBpc3N1ZSkuIE9uZSBzb2x1dGlvbiBpczwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+dG8gdXNlIHRoZSBJUHY2IFNvdXJjZSBBZGRyZXNzIC0gYnV0IHRoYXQg aGFzIHByb2JsZW1zIHNpbmNlIHRoZW4gd2h5IG5vdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ YWx3YXlzIHVzZSBpdD8gQW5vdGhlciBpcyBmb3IgdGhlIHNlcnZlciB0byBzYXZlIGluZm9ybWF0 aW9uIG9uIGhvdyB0byByZWFjaDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlIGNsaWVudCAo d2hpY2ggaXQgbWlnaHQgbmVlZCB0byBkbyBhbnl3YXkgdG8gc2VuZCBpdCBSZWNvbmZpZ3VyZS1J bml0cz8pPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj52aWEgYSBSZWxheSAob3IgZGlyZWN0bHkg aWYgb24tbGluaykuIEJ1dCB0aGlzIGlzIG1lc3N5IGFuZCB3aGF0IGlmIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGhhcyBtb3ZlZCAoSSBndWVzcyB5b3UgY291bGQgYXJndWUg dGhlbiBpdCBtaWdodCBub3QgbmVlZCB0byBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UmVj b25maWd1cmVkKT88L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tIEJlcm5pZTwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBUZWQgTGVtb24gWzxBIEhSRUY9Im1haWx0bzpt ZWxsb25Abm9taW51bS5jb20iPm1haWx0bzptZWxsb25Abm9taW51bS5jb208L0E+XTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+U2VudDogV2VkbmVzZGF5LCBKdWx5IDE4LCAyMDAxIDY6NTEgUE08 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBESENQdjYgZGlzY3Vzc2lvbiBsaXN0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSZTogREhDUE5BQ0sgZm9yIERIQ1B2NiBbUHJv cG9zZWQgRHJhZnQgQ2hhbmdlc10gPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9O VCBTSVpFPTI+SUlSQyA9IElmIEkgUmVjYWxsIENvcnJlY3RseTwvRk9OVD4NCjwvUD4NCg0KPFA+ PEZPTlQgU0laRT0yPiZndDsgV2hhdCBkaWZmZXJlbmNlIGRvZXMgdGhhdCBtYWtlPyBBIFJlbGVh c2Ugb3IgRGVjbGluZSBjYW4gYmUgdW5pY2FzdCBhcyB3ZWxsPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IChpZiB0aGUgY2xpZW50IGhhcyBhbm90aGVyIGFkZHJlc3MgLSBpbiBhIGRpZmZl cmVudCBJQSAtIHRoYW4gd2hhdCBpdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBy ZWxlYXNpbmcgYW5kIHRoZSBzZXJ2ZXIgaGFzIHRvbGQgdGhlIGNsaWVudCBpdCBjYW4gdW5pY2Fz dCkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIHNlcnZlciBkb2Vzbid0IG5l ZWQgdG8gbWFrZSBhIGRldGVybWluYXRpb24gYXMgdG8gd2hhdCBsaW5rIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGlzIG9uIGluIHRoZSBjYXNlIG9mIFJlbGVhc2UuJm5ic3A7 Jm5ic3A7IERlY2xpbmUgcHJvYmFibHkgZG9lcyBuZWVkIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5nbyB0aHJvdWdoIHRoZSByZWxheS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj4mZ3Q7IFdoeSBkb2VzICpIT1cqIHRoZSBwYWNrZXQgd2FzIHNlbnQgbWFrZSBhbnkgZGlmZmVy ZW5jZT8gUmVtZW1iZXIsIHdlJ3JlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRlYWxp bmcgd2l0aCBNQU5ZIGFkZHJlc3NlcyBzbyBhbiBpbmRpdmlkdWFsIG1lc3NhZ2UncyBJQXMgaGF2 ZSBub3RoaW5nIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRvIHdpdGggb3RoZXIg SUFzIChhbmQgaGVuY2UgYWRkcmVzc2VzKSB0aGF0IGNsaWVudCBoYXMuPC9GT05UPg0KPC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+SWYgdGhlIHBhY2tldCBnb2VzIHRocm91Z2ggYSByZWxheSwgdGhl IHJlbGF5IGNhbiBzYXkgb24gd2hpY2ggbGluazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhl IHBhY2tldCB3YXMgcmVjZWl2ZWQuJm5ic3A7IElmIGl0IGlzIHVuaWNhc3QgdGhyb3VnaCBhIHJv dXRlciwgdGhhdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+bm90IHRoZSBjYXNlLiZuYnNw OyBJbiB0aGUgY2FzZSB3aGVyZSBpdCBpcyB1bmljYXN0IHRocm91Z2ggYSByb3V0ZXIsPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj50aGVyZWZvcmUsIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBj aGVjayB0aGUgcHJlZml4IC0gd2UgY2FuIG9ubHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmFz c3VtZSB0aGF0IGl0IGlzIGNvcnJlY3QuJm5ic3A7IEluIHRoZSBjYXNlIHdoZXJlIGl0IGlzIG5v dCBjb3JyZWN0LCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnBhY2tldCBwcm9iYWJseSB3 b3VsZG4ndCBoYXZlIGdvdHRlbiB0byB1cywgYW5kIGV2ZW4gaWYgaXQgZGlkIHNvbWVob3c8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmdldCB0byB1cywgd2UgY291bGRuJ3QgcmVwbHksIGJlY2F1 c2Ugb3VyIHJlcGx5IHdpbGwgZ28gdG8gdGhlIGxpbms8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PndoZXJlIHRoZSBwcmVmaXggKmlzKiB2YWxpZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg X01lbGxvTl88L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=q7KkifzO4ict1lG2vlKJokQIkcm037H5ZShx8Djw088UKypocI4KUfld-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:19:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02083; Wed, 18 Jul 2001 19:18:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INJML17718; Wed, 18 Jul 2001 19:19:22 -0400 (EDT) Received: from mail-gw01.gap.com ([206.16.32.97]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INJCL31730 for ; Wed, 18 Jul 2001 19:19:12 -0400 (EDT) Received: from mailhub02.gap.com (mailhub02.gap.com [9.32.202.152]) by mail-gw01.gap.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA07580 for ; Wed, 18 Jul 2001 16:18:31 -0700 (PDT) From: Relfe_Tan@gap.com Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43]) by mailhub02.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id QAA03864 for ; Wed, 18 Jul 2001 16:16:46 -0700 (PDT) Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A8D.007FA565 ; Wed, 18 Jul 2001 16:14:13 -0700 X-Lotus-FromDomain: GAPINC To: DHCPv6 discussion list Message-ID: <88256A8D.007FA4B9.00@smtpmta01.gap.com> Date: Wed, 18 Jul 2001 16:16:49 -0700 Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=enz8R9lY56jSbbAhMTybGLsLqHKxVfJTX2nSqgL41UN7uW7aPt42LC6d" Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --0__=enz8R9lY56jSbbAhMTybGLsLqHKxVfJTX2nSqgL41UN7uW7aPt42LC6d Content-type: text/plain; charset=us-ascii Content-Disposition: inline unsubscribe "Bernie Volz (EUD)" on 07/18/2001 04:10:07 PM Please respond to dhcp-v6@bucknell.edu To: "DHCPv6 discussion list" cc: (bcc: Relfe Tan/SB/GAPINC) Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] OK. I understand your point. BTW, I was originally thinking that only the Reply to a Confirm message would do this prefix checking and hence return a NoPrefixMatch status. But, even that would not have been safe. Note that text for the "Server Unicast Option": "This option is used by a server to send to a client to inform the client it can send a Request, Renew, Confirm, Release, and Decline by unicasting directly to the server instead of the All DHCPv6 Agents multicast adress as an optimization." I think we need to change this OR we need to add a statement to the prefix checking that prohibits it if the server can't tell where the client is. Now, this raises the nasty issue of if the client unicasts a message, how does the server reply to it (I already raised this issue). One solution is to use the IPv6 Source Address - but that has problems since then why not always use it? Another is for the server to save information on how to reach the client (which it might need to do anyway to send it Reconfigure-Inits?) via a Relay (or directly if on-link). But this is messy and what if the client has moved (I guess you could argue then it might not need to be Reconfigured)? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 6:51 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] IIRC = If I Recall Correctly > What difference does that make? A Release or Decline can be unicast as well > (if the client has another address - in a different IA - than what it is > releasing and the server has told the client it can unicast). The server doesn't need to make a determination as to what link the client is on in the case of Release. Decline probably does need to go through the relay. > Why does *HOW* the packet was sent make any difference? Remember, we're > dealing with MANY addresses so an individual message's IAs have nothing to > do with other IAs (and hence addresses) that client has. If the packet goes through a relay, the relay can say on which link the packet was received. If it is unicast through a router, that is not the case. In the case where it is unicast through a router, therefore, it doesn't make sense to check the prefix - we can only assume that it is correct. In the case where it is not correct, the packet probably wouldn't have gotten to us, and even if it did somehow get to us, we couldn't reply, because our reply will go to the link where the prefix *is* valid. _MelloN_ --0__=enz8R9lY56jSbbAhMTybGLsLqHKxVfJTX2nSqgL41UN7uW7aPt42LC6d Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC4xOSI+DQo8VElUTEU+UkU6IERI Q1BOQUNLIGZvciBESENQdjYgW1Byb3Bvc2VkIERyYWZ0IENoYW5nZXNdIDwvVElUTEU+DQo8L0hF QUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPk9LLiBJIHVuZGVyc3RhbmQgeW91ciBwb2lu dC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5CVFcsIEkgd2FzIG9yaWdpbmFsbHkg dGhpbmtpbmcgdGhhdCBvbmx5IHRoZSBSZXBseSB0byBhIENvbmZpcm0gbWVzc2FnZTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+d291bGQgZG8gdGhpcyBwcmVmaXggY2hlY2tpbmcgYW5kIGhlbmNl IHJldHVybiBhIE5vUHJlZml4TWF0Y2ggc3RhdHVzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPkJ1dCwgZXZlbiB0aGF0IHdvdWxkIG5vdCBoYXZlIGJlZW4gc2FmZS4gTm90ZSB0aGF0 IHRleHQgZm9yIHRoZSAmcXVvdDtTZXJ2ZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlVuaWNh c3QgT3B0aW9uJnF1b3Q7OjwvRk9OVD4NCjwvUD4NCg0KPFA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIFNJWkU9Mj4mcXVvdDtUaGlzIG9wdGlvbiBpcyB1 c2VkIGJ5IGEgc2VydmVyIHRvIHNlbmQgdG8gYSBjbGllbnQgdG8gaW5mb3JtIHRoZTwvRk9OVD4N CjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0la RT0yPmNsaWVudCBpdCBjYW4gc2VuZCBhIFJlcXVlc3QsIFJlbmV3LCBDb25maXJtLCBSZWxlYXNl LCBhbmQgRGVjbGluZTwvRk9OVD4NCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPmJ5IHVuaWNhc3RpbmcgZGlyZWN0bHkgdG8gdGhlIHNl cnZlciBpbnN0ZWFkIG9mIHRoZSBBbGwgREhDUHY2IEFnZW50czwvRk9OVD4NCjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPm11bHRpY2Fz dCBhZHJlc3MgYXMgYW4gb3B0aW1pemF0aW9uLiZxdW90OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkkgdGhpbmsgd2UgbmVlZCB0byBjaGFuZ2UgdGhpcyBPUiB3ZSBuZWVkIHRvIGFk ZCBhIHN0YXRlbWVudCB0byB0aGUgcHJlZml4PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5jaGVj a2luZyB0aGF0IHByb2hpYml0cyBpdCBpZiB0aGUgc2VydmVyIGNhbid0IHRlbGwgd2hlcmUgdGhl IGNsaWVudCBpcy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Ob3csIHRoaXMgcmFp c2VzIHRoZSBuYXN0eSBpc3N1ZSBvZiBpZiB0aGUgY2xpZW50IHVuaWNhc3RzIGEgbWVzc2FnZSwg aG93PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5kb2VzIHRoZSBzZXJ2ZXIgcmVwbHkgdG8gaXQg KEkgYWxyZWFkeSByYWlzZWQgdGhpcyBpc3N1ZSkuIE9uZSBzb2x1dGlvbiBpczwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+dG8gdXNlIHRoZSBJUHY2IFNvdXJjZSBBZGRyZXNzIC0gYnV0IHRoYXQg aGFzIHByb2JsZW1zIHNpbmNlIHRoZW4gd2h5IG5vdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ YWx3YXlzIHVzZSBpdD8gQW5vdGhlciBpcyBmb3IgdGhlIHNlcnZlciB0byBzYXZlIGluZm9ybWF0 aW9uIG9uIGhvdyB0byByZWFjaDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlIGNsaWVudCAo d2hpY2ggaXQgbWlnaHQgbmVlZCB0byBkbyBhbnl3YXkgdG8gc2VuZCBpdCBSZWNvbmZpZ3VyZS1J bml0cz8pPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj52aWEgYSBSZWxheSAob3IgZGlyZWN0bHkg aWYgb24tbGluaykuIEJ1dCB0aGlzIGlzIG1lc3N5IGFuZCB3aGF0IGlmIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGhhcyBtb3ZlZCAoSSBndWVzcyB5b3UgY291bGQgYXJndWUg dGhlbiBpdCBtaWdodCBub3QgbmVlZCB0byBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UmVj b25maWd1cmVkKT88L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tIEJlcm5pZTwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBUZWQgTGVtb24gWzxBIEhSRUY9Im1haWx0bzpt ZWxsb25Abm9taW51bS5jb20iPm1haWx0bzptZWxsb25Abm9taW51bS5jb208L0E+XTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+U2VudDogV2VkbmVzZGF5LCBKdWx5IDE4LCAyMDAxIDY6NTEgUE08 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBESENQdjYgZGlzY3Vzc2lvbiBsaXN0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSZTogREhDUE5BQ0sgZm9yIERIQ1B2NiBbUHJv cG9zZWQgRHJhZnQgQ2hhbmdlc10gPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9O VCBTSVpFPTI+SUlSQyA9IElmIEkgUmVjYWxsIENvcnJlY3RseTwvRk9OVD4NCjwvUD4NCg0KPFA+ PEZPTlQgU0laRT0yPiZndDsgV2hhdCBkaWZmZXJlbmNlIGRvZXMgdGhhdCBtYWtlPyBBIFJlbGVh c2Ugb3IgRGVjbGluZSBjYW4gYmUgdW5pY2FzdCBhcyB3ZWxsPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IChpZiB0aGUgY2xpZW50IGhhcyBhbm90aGVyIGFkZHJlc3MgLSBpbiBhIGRpZmZl cmVudCBJQSAtIHRoYW4gd2hhdCBpdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBy ZWxlYXNpbmcgYW5kIHRoZSBzZXJ2ZXIgaGFzIHRvbGQgdGhlIGNsaWVudCBpdCBjYW4gdW5pY2Fz dCkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIHNlcnZlciBkb2Vzbid0IG5l ZWQgdG8gbWFrZSBhIGRldGVybWluYXRpb24gYXMgdG8gd2hhdCBsaW5rIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGlzIG9uIGluIHRoZSBjYXNlIG9mIFJlbGVhc2UuJm5ic3A7 Jm5ic3A7IERlY2xpbmUgcHJvYmFibHkgZG9lcyBuZWVkIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5nbyB0aHJvdWdoIHRoZSByZWxheS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj4mZ3Q7IFdoeSBkb2VzICpIT1cqIHRoZSBwYWNrZXQgd2FzIHNlbnQgbWFrZSBhbnkgZGlmZmVy ZW5jZT8gUmVtZW1iZXIsIHdlJ3JlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRlYWxp bmcgd2l0aCBNQU5ZIGFkZHJlc3NlcyBzbyBhbiBpbmRpdmlkdWFsIG1lc3NhZ2UncyBJQXMgaGF2 ZSBub3RoaW5nIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRvIHdpdGggb3RoZXIg SUFzIChhbmQgaGVuY2UgYWRkcmVzc2VzKSB0aGF0IGNsaWVudCBoYXMuPC9GT05UPg0KPC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+SWYgdGhlIHBhY2tldCBnb2VzIHRocm91Z2ggYSByZWxheSwgdGhl IHJlbGF5IGNhbiBzYXkgb24gd2hpY2ggbGluazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhl IHBhY2tldCB3YXMgcmVjZWl2ZWQuJm5ic3A7IElmIGl0IGlzIHVuaWNhc3QgdGhyb3VnaCBhIHJv dXRlciwgdGhhdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+bm90IHRoZSBjYXNlLiZuYnNw OyBJbiB0aGUgY2FzZSB3aGVyZSBpdCBpcyB1bmljYXN0IHRocm91Z2ggYSByb3V0ZXIsPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj50aGVyZWZvcmUsIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBj aGVjayB0aGUgcHJlZml4IC0gd2UgY2FuIG9ubHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmFz c3VtZSB0aGF0IGl0IGlzIGNvcnJlY3QuJm5ic3A7IEluIHRoZSBjYXNlIHdoZXJlIGl0IGlzIG5v dCBjb3JyZWN0LCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnBhY2tldCBwcm9iYWJseSB3 b3VsZG4ndCBoYXZlIGdvdHRlbiB0byB1cywgYW5kIGV2ZW4gaWYgaXQgZGlkIHNvbWVob3c8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmdldCB0byB1cywgd2UgY291bGRuJ3QgcmVwbHksIGJlY2F1 c2Ugb3VyIHJlcGx5IHdpbGwgZ28gdG8gdGhlIGxpbms8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PndoZXJlIHRoZSBwcmVmaXggKmlzKiB2YWxpZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg X01lbGxvTl88L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=enz8R9lY56jSbbAhMTybGLsLqHKxVfJTX2nSqgL41UN7uW7aPt42LC6d-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:19:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02134; Wed, 18 Jul 2001 19:19:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INJTL00716; Wed, 18 Jul 2001 19:19:29 -0400 (EDT) Received: from mail-gw01.gap.com ([206.16.32.97]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INJNL22812 for ; Wed, 18 Jul 2001 19:19:23 -0400 (EDT) Received: from mailhub02.gap.com (mailhub02.gap.com [9.32.202.152]) by mail-gw01.gap.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA07659 for ; Wed, 18 Jul 2001 16:18:43 -0700 (PDT) From: Relfe_Tan@gap.com Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43]) by mailhub02.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id QAA03911 for ; Wed, 18 Jul 2001 16:16:57 -0700 (PDT) Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A8D.007FA972 ; Wed, 18 Jul 2001 16:14:24 -0700 X-Lotus-FromDomain: GAPINC To: DHCPv6 discussion list Message-ID: <88256A8D.007FA916.00@smtpmta01.gap.com> Date: Wed, 18 Jul 2001 16:17:02 -0700 Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=GSgUyjLrWKdV5KDW2vPmC0UMPD0AtH43IZyel2dmqzQsRvY1elnpdkFa" Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --0__=GSgUyjLrWKdV5KDW2vPmC0UMPD0AtH43IZyel2dmqzQsRvY1elnpdkFa Content-type: text/plain; charset=us-ascii Content-Disposition: inline unsubscribe "Bernie Volz (EUD)" on 07/18/2001 04:10:07 PM Please respond to dhcp-v6@bucknell.edu To: "DHCPv6 discussion list" cc: (bcc: Relfe Tan/SB/GAPINC) Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] OK. I understand your point. BTW, I was originally thinking that only the Reply to a Confirm message would do this prefix checking and hence return a NoPrefixMatch status. But, even that would not have been safe. Note that text for the "Server Unicast Option": "This option is used by a server to send to a client to inform the client it can send a Request, Renew, Confirm, Release, and Decline by unicasting directly to the server instead of the All DHCPv6 Agents multicast adress as an optimization." I think we need to change this OR we need to add a statement to the prefix checking that prohibits it if the server can't tell where the client is. Now, this raises the nasty issue of if the client unicasts a message, how does the server reply to it (I already raised this issue). One solution is to use the IPv6 Source Address - but that has problems since then why not always use it? Another is for the server to save information on how to reach the client (which it might need to do anyway to send it Reconfigure-Inits?) via a Relay (or directly if on-link). But this is messy and what if the client has moved (I guess you could argue then it might not need to be Reconfigured)? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 6:51 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] IIRC = If I Recall Correctly > What difference does that make? A Release or Decline can be unicast as well > (if the client has another address - in a different IA - than what it is > releasing and the server has told the client it can unicast). The server doesn't need to make a determination as to what link the client is on in the case of Release. Decline probably does need to go through the relay. > Why does *HOW* the packet was sent make any difference? Remember, we're > dealing with MANY addresses so an individual message's IAs have nothing to > do with other IAs (and hence addresses) that client has. If the packet goes through a relay, the relay can say on which link the packet was received. If it is unicast through a router, that is not the case. In the case where it is unicast through a router, therefore, it doesn't make sense to check the prefix - we can only assume that it is correct. In the case where it is not correct, the packet probably wouldn't have gotten to us, and even if it did somehow get to us, we couldn't reply, because our reply will go to the link where the prefix *is* valid. _MelloN_ --0__=GSgUyjLrWKdV5KDW2vPmC0UMPD0AtH43IZyel2dmqzQsRvY1elnpdkFa Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC4xOSI+DQo8VElUTEU+UkU6IERI Q1BOQUNLIGZvciBESENQdjYgW1Byb3Bvc2VkIERyYWZ0IENoYW5nZXNdIDwvVElUTEU+DQo8L0hF QUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPk9LLiBJIHVuZGVyc3RhbmQgeW91ciBwb2lu dC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5CVFcsIEkgd2FzIG9yaWdpbmFsbHkg dGhpbmtpbmcgdGhhdCBvbmx5IHRoZSBSZXBseSB0byBhIENvbmZpcm0gbWVzc2FnZTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+d291bGQgZG8gdGhpcyBwcmVmaXggY2hlY2tpbmcgYW5kIGhlbmNl IHJldHVybiBhIE5vUHJlZml4TWF0Y2ggc3RhdHVzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPkJ1dCwgZXZlbiB0aGF0IHdvdWxkIG5vdCBoYXZlIGJlZW4gc2FmZS4gTm90ZSB0aGF0 IHRleHQgZm9yIHRoZSAmcXVvdDtTZXJ2ZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlVuaWNh c3QgT3B0aW9uJnF1b3Q7OjwvRk9OVD4NCjwvUD4NCg0KPFA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIFNJWkU9Mj4mcXVvdDtUaGlzIG9wdGlvbiBpcyB1 c2VkIGJ5IGEgc2VydmVyIHRvIHNlbmQgdG8gYSBjbGllbnQgdG8gaW5mb3JtIHRoZTwvRk9OVD4N CjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0la RT0yPmNsaWVudCBpdCBjYW4gc2VuZCBhIFJlcXVlc3QsIFJlbmV3LCBDb25maXJtLCBSZWxlYXNl LCBhbmQgRGVjbGluZTwvRk9OVD4NCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPmJ5IHVuaWNhc3RpbmcgZGlyZWN0bHkgdG8gdGhlIHNl cnZlciBpbnN0ZWFkIG9mIHRoZSBBbGwgREhDUHY2IEFnZW50czwvRk9OVD4NCjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPm11bHRpY2Fz dCBhZHJlc3MgYXMgYW4gb3B0aW1pemF0aW9uLiZxdW90OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkkgdGhpbmsgd2UgbmVlZCB0byBjaGFuZ2UgdGhpcyBPUiB3ZSBuZWVkIHRvIGFk ZCBhIHN0YXRlbWVudCB0byB0aGUgcHJlZml4PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5jaGVj a2luZyB0aGF0IHByb2hpYml0cyBpdCBpZiB0aGUgc2VydmVyIGNhbid0IHRlbGwgd2hlcmUgdGhl IGNsaWVudCBpcy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Ob3csIHRoaXMgcmFp c2VzIHRoZSBuYXN0eSBpc3N1ZSBvZiBpZiB0aGUgY2xpZW50IHVuaWNhc3RzIGEgbWVzc2FnZSwg aG93PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5kb2VzIHRoZSBzZXJ2ZXIgcmVwbHkgdG8gaXQg KEkgYWxyZWFkeSByYWlzZWQgdGhpcyBpc3N1ZSkuIE9uZSBzb2x1dGlvbiBpczwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+dG8gdXNlIHRoZSBJUHY2IFNvdXJjZSBBZGRyZXNzIC0gYnV0IHRoYXQg aGFzIHByb2JsZW1zIHNpbmNlIHRoZW4gd2h5IG5vdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ YWx3YXlzIHVzZSBpdD8gQW5vdGhlciBpcyBmb3IgdGhlIHNlcnZlciB0byBzYXZlIGluZm9ybWF0 aW9uIG9uIGhvdyB0byByZWFjaDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlIGNsaWVudCAo d2hpY2ggaXQgbWlnaHQgbmVlZCB0byBkbyBhbnl3YXkgdG8gc2VuZCBpdCBSZWNvbmZpZ3VyZS1J bml0cz8pPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj52aWEgYSBSZWxheSAob3IgZGlyZWN0bHkg aWYgb24tbGluaykuIEJ1dCB0aGlzIGlzIG1lc3N5IGFuZCB3aGF0IGlmIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGhhcyBtb3ZlZCAoSSBndWVzcyB5b3UgY291bGQgYXJndWUg dGhlbiBpdCBtaWdodCBub3QgbmVlZCB0byBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UmVj b25maWd1cmVkKT88L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tIEJlcm5pZTwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBUZWQgTGVtb24gWzxBIEhSRUY9Im1haWx0bzpt ZWxsb25Abm9taW51bS5jb20iPm1haWx0bzptZWxsb25Abm9taW51bS5jb208L0E+XTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+U2VudDogV2VkbmVzZGF5LCBKdWx5IDE4LCAyMDAxIDY6NTEgUE08 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBESENQdjYgZGlzY3Vzc2lvbiBsaXN0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSZTogREhDUE5BQ0sgZm9yIERIQ1B2NiBbUHJv cG9zZWQgRHJhZnQgQ2hhbmdlc10gPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9O VCBTSVpFPTI+SUlSQyA9IElmIEkgUmVjYWxsIENvcnJlY3RseTwvRk9OVD4NCjwvUD4NCg0KPFA+ PEZPTlQgU0laRT0yPiZndDsgV2hhdCBkaWZmZXJlbmNlIGRvZXMgdGhhdCBtYWtlPyBBIFJlbGVh c2Ugb3IgRGVjbGluZSBjYW4gYmUgdW5pY2FzdCBhcyB3ZWxsPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IChpZiB0aGUgY2xpZW50IGhhcyBhbm90aGVyIGFkZHJlc3MgLSBpbiBhIGRpZmZl cmVudCBJQSAtIHRoYW4gd2hhdCBpdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBy ZWxlYXNpbmcgYW5kIHRoZSBzZXJ2ZXIgaGFzIHRvbGQgdGhlIGNsaWVudCBpdCBjYW4gdW5pY2Fz dCkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIHNlcnZlciBkb2Vzbid0IG5l ZWQgdG8gbWFrZSBhIGRldGVybWluYXRpb24gYXMgdG8gd2hhdCBsaW5rIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGlzIG9uIGluIHRoZSBjYXNlIG9mIFJlbGVhc2UuJm5ic3A7 Jm5ic3A7IERlY2xpbmUgcHJvYmFibHkgZG9lcyBuZWVkIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5nbyB0aHJvdWdoIHRoZSByZWxheS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj4mZ3Q7IFdoeSBkb2VzICpIT1cqIHRoZSBwYWNrZXQgd2FzIHNlbnQgbWFrZSBhbnkgZGlmZmVy ZW5jZT8gUmVtZW1iZXIsIHdlJ3JlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRlYWxp bmcgd2l0aCBNQU5ZIGFkZHJlc3NlcyBzbyBhbiBpbmRpdmlkdWFsIG1lc3NhZ2UncyBJQXMgaGF2 ZSBub3RoaW5nIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRvIHdpdGggb3RoZXIg SUFzIChhbmQgaGVuY2UgYWRkcmVzc2VzKSB0aGF0IGNsaWVudCBoYXMuPC9GT05UPg0KPC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+SWYgdGhlIHBhY2tldCBnb2VzIHRocm91Z2ggYSByZWxheSwgdGhl IHJlbGF5IGNhbiBzYXkgb24gd2hpY2ggbGluazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhl IHBhY2tldCB3YXMgcmVjZWl2ZWQuJm5ic3A7IElmIGl0IGlzIHVuaWNhc3QgdGhyb3VnaCBhIHJv dXRlciwgdGhhdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+bm90IHRoZSBjYXNlLiZuYnNw OyBJbiB0aGUgY2FzZSB3aGVyZSBpdCBpcyB1bmljYXN0IHRocm91Z2ggYSByb3V0ZXIsPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj50aGVyZWZvcmUsIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBj aGVjayB0aGUgcHJlZml4IC0gd2UgY2FuIG9ubHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmFz c3VtZSB0aGF0IGl0IGlzIGNvcnJlY3QuJm5ic3A7IEluIHRoZSBjYXNlIHdoZXJlIGl0IGlzIG5v dCBjb3JyZWN0LCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnBhY2tldCBwcm9iYWJseSB3 b3VsZG4ndCBoYXZlIGdvdHRlbiB0byB1cywgYW5kIGV2ZW4gaWYgaXQgZGlkIHNvbWVob3c8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmdldCB0byB1cywgd2UgY291bGRuJ3QgcmVwbHksIGJlY2F1 c2Ugb3VyIHJlcGx5IHdpbGwgZ28gdG8gdGhlIGxpbms8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PndoZXJlIHRoZSBwcmVmaXggKmlzKiB2YWxpZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg X01lbGxvTl88L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=GSgUyjLrWKdV5KDW2vPmC0UMPD0AtH43IZyel2dmqzQsRvY1elnpdkFa-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:19:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02186; Wed, 18 Jul 2001 19:19:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INJbL07192; Wed, 18 Jul 2001 19:19:37 -0400 (EDT) Received: from mail-gw01.gap.com ([206.16.32.97]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INJYL14607 for ; Wed, 18 Jul 2001 19:19:34 -0400 (EDT) Received: from mailhub02.gap.com (mailhub02.gap.com [9.32.202.152]) by mail-gw01.gap.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA07757 for ; Wed, 18 Jul 2001 16:18:54 -0700 (PDT) From: Relfe_Tan@gap.com Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43]) by mailhub02.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id QAA03954 for ; Wed, 18 Jul 2001 16:17:08 -0700 (PDT) Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A8D.007FADB2 ; Wed, 18 Jul 2001 16:14:35 -0700 X-Lotus-FromDomain: GAPINC To: DHCPv6 discussion list Message-ID: <88256A8D.007FAC3F.00@smtpmta01.gap.com> Date: Wed, 18 Jul 2001 16:17:10 -0700 Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=wbdYykMRFcU4mBQPfL2cjUw0FlVb9zBqBOPjtwXY6wqil7Rbebc291A5" Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --0__=wbdYykMRFcU4mBQPfL2cjUw0FlVb9zBqBOPjtwXY6wqil7Rbebc291A5 Content-type: text/plain; charset=us-ascii Content-Disposition: inline unsubscribe "Bernie Volz (EUD)" on 07/18/2001 04:10:07 PM Please respond to dhcp-v6@bucknell.edu To: "DHCPv6 discussion list" cc: (bcc: Relfe Tan/SB/GAPINC) Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] OK. I understand your point. BTW, I was originally thinking that only the Reply to a Confirm message would do this prefix checking and hence return a NoPrefixMatch status. But, even that would not have been safe. Note that text for the "Server Unicast Option": "This option is used by a server to send to a client to inform the client it can send a Request, Renew, Confirm, Release, and Decline by unicasting directly to the server instead of the All DHCPv6 Agents multicast adress as an optimization." I think we need to change this OR we need to add a statement to the prefix checking that prohibits it if the server can't tell where the client is. Now, this raises the nasty issue of if the client unicasts a message, how does the server reply to it (I already raised this issue). One solution is to use the IPv6 Source Address - but that has problems since then why not always use it? Another is for the server to save information on how to reach the client (which it might need to do anyway to send it Reconfigure-Inits?) via a Relay (or directly if on-link). But this is messy and what if the client has moved (I guess you could argue then it might not need to be Reconfigured)? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 6:51 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] IIRC = If I Recall Correctly > What difference does that make? A Release or Decline can be unicast as well > (if the client has another address - in a different IA - than what it is > releasing and the server has told the client it can unicast). The server doesn't need to make a determination as to what link the client is on in the case of Release. Decline probably does need to go through the relay. > Why does *HOW* the packet was sent make any difference? Remember, we're > dealing with MANY addresses so an individual message's IAs have nothing to > do with other IAs (and hence addresses) that client has. If the packet goes through a relay, the relay can say on which link the packet was received. If it is unicast through a router, that is not the case. In the case where it is unicast through a router, therefore, it doesn't make sense to check the prefix - we can only assume that it is correct. In the case where it is not correct, the packet probably wouldn't have gotten to us, and even if it did somehow get to us, we couldn't reply, because our reply will go to the link where the prefix *is* valid. _MelloN_ --0__=wbdYykMRFcU4mBQPfL2cjUw0FlVb9zBqBOPjtwXY6wqil7Rbebc291A5 Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC4xOSI+DQo8VElUTEU+UkU6IERI Q1BOQUNLIGZvciBESENQdjYgW1Byb3Bvc2VkIERyYWZ0IENoYW5nZXNdIDwvVElUTEU+DQo8L0hF QUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPk9LLiBJIHVuZGVyc3RhbmQgeW91ciBwb2lu dC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5CVFcsIEkgd2FzIG9yaWdpbmFsbHkg dGhpbmtpbmcgdGhhdCBvbmx5IHRoZSBSZXBseSB0byBhIENvbmZpcm0gbWVzc2FnZTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+d291bGQgZG8gdGhpcyBwcmVmaXggY2hlY2tpbmcgYW5kIGhlbmNl IHJldHVybiBhIE5vUHJlZml4TWF0Y2ggc3RhdHVzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPkJ1dCwgZXZlbiB0aGF0IHdvdWxkIG5vdCBoYXZlIGJlZW4gc2FmZS4gTm90ZSB0aGF0 IHRleHQgZm9yIHRoZSAmcXVvdDtTZXJ2ZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlVuaWNh c3QgT3B0aW9uJnF1b3Q7OjwvRk9OVD4NCjwvUD4NCg0KPFA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIFNJWkU9Mj4mcXVvdDtUaGlzIG9wdGlvbiBpcyB1 c2VkIGJ5IGEgc2VydmVyIHRvIHNlbmQgdG8gYSBjbGllbnQgdG8gaW5mb3JtIHRoZTwvRk9OVD4N CjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0la RT0yPmNsaWVudCBpdCBjYW4gc2VuZCBhIFJlcXVlc3QsIFJlbmV3LCBDb25maXJtLCBSZWxlYXNl LCBhbmQgRGVjbGluZTwvRk9OVD4NCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPmJ5IHVuaWNhc3RpbmcgZGlyZWN0bHkgdG8gdGhlIHNl cnZlciBpbnN0ZWFkIG9mIHRoZSBBbGwgREhDUHY2IEFnZW50czwvRk9OVD4NCjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPm11bHRpY2Fz dCBhZHJlc3MgYXMgYW4gb3B0aW1pemF0aW9uLiZxdW90OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkkgdGhpbmsgd2UgbmVlZCB0byBjaGFuZ2UgdGhpcyBPUiB3ZSBuZWVkIHRvIGFk ZCBhIHN0YXRlbWVudCB0byB0aGUgcHJlZml4PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5jaGVj a2luZyB0aGF0IHByb2hpYml0cyBpdCBpZiB0aGUgc2VydmVyIGNhbid0IHRlbGwgd2hlcmUgdGhl IGNsaWVudCBpcy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Ob3csIHRoaXMgcmFp c2VzIHRoZSBuYXN0eSBpc3N1ZSBvZiBpZiB0aGUgY2xpZW50IHVuaWNhc3RzIGEgbWVzc2FnZSwg aG93PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5kb2VzIHRoZSBzZXJ2ZXIgcmVwbHkgdG8gaXQg KEkgYWxyZWFkeSByYWlzZWQgdGhpcyBpc3N1ZSkuIE9uZSBzb2x1dGlvbiBpczwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+dG8gdXNlIHRoZSBJUHY2IFNvdXJjZSBBZGRyZXNzIC0gYnV0IHRoYXQg aGFzIHByb2JsZW1zIHNpbmNlIHRoZW4gd2h5IG5vdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ YWx3YXlzIHVzZSBpdD8gQW5vdGhlciBpcyBmb3IgdGhlIHNlcnZlciB0byBzYXZlIGluZm9ybWF0 aW9uIG9uIGhvdyB0byByZWFjaDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlIGNsaWVudCAo d2hpY2ggaXQgbWlnaHQgbmVlZCB0byBkbyBhbnl3YXkgdG8gc2VuZCBpdCBSZWNvbmZpZ3VyZS1J bml0cz8pPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj52aWEgYSBSZWxheSAob3IgZGlyZWN0bHkg aWYgb24tbGluaykuIEJ1dCB0aGlzIGlzIG1lc3N5IGFuZCB3aGF0IGlmIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGhhcyBtb3ZlZCAoSSBndWVzcyB5b3UgY291bGQgYXJndWUg dGhlbiBpdCBtaWdodCBub3QgbmVlZCB0byBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UmVj b25maWd1cmVkKT88L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tIEJlcm5pZTwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBUZWQgTGVtb24gWzxBIEhSRUY9Im1haWx0bzpt ZWxsb25Abm9taW51bS5jb20iPm1haWx0bzptZWxsb25Abm9taW51bS5jb208L0E+XTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+U2VudDogV2VkbmVzZGF5LCBKdWx5IDE4LCAyMDAxIDY6NTEgUE08 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBESENQdjYgZGlzY3Vzc2lvbiBsaXN0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSZTogREhDUE5BQ0sgZm9yIERIQ1B2NiBbUHJv cG9zZWQgRHJhZnQgQ2hhbmdlc10gPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9O VCBTSVpFPTI+SUlSQyA9IElmIEkgUmVjYWxsIENvcnJlY3RseTwvRk9OVD4NCjwvUD4NCg0KPFA+ PEZPTlQgU0laRT0yPiZndDsgV2hhdCBkaWZmZXJlbmNlIGRvZXMgdGhhdCBtYWtlPyBBIFJlbGVh c2Ugb3IgRGVjbGluZSBjYW4gYmUgdW5pY2FzdCBhcyB3ZWxsPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IChpZiB0aGUgY2xpZW50IGhhcyBhbm90aGVyIGFkZHJlc3MgLSBpbiBhIGRpZmZl cmVudCBJQSAtIHRoYW4gd2hhdCBpdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBy ZWxlYXNpbmcgYW5kIHRoZSBzZXJ2ZXIgaGFzIHRvbGQgdGhlIGNsaWVudCBpdCBjYW4gdW5pY2Fz dCkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIHNlcnZlciBkb2Vzbid0IG5l ZWQgdG8gbWFrZSBhIGRldGVybWluYXRpb24gYXMgdG8gd2hhdCBsaW5rIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGlzIG9uIGluIHRoZSBjYXNlIG9mIFJlbGVhc2UuJm5ic3A7 Jm5ic3A7IERlY2xpbmUgcHJvYmFibHkgZG9lcyBuZWVkIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5nbyB0aHJvdWdoIHRoZSByZWxheS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj4mZ3Q7IFdoeSBkb2VzICpIT1cqIHRoZSBwYWNrZXQgd2FzIHNlbnQgbWFrZSBhbnkgZGlmZmVy ZW5jZT8gUmVtZW1iZXIsIHdlJ3JlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRlYWxp bmcgd2l0aCBNQU5ZIGFkZHJlc3NlcyBzbyBhbiBpbmRpdmlkdWFsIG1lc3NhZ2UncyBJQXMgaGF2 ZSBub3RoaW5nIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRvIHdpdGggb3RoZXIg SUFzIChhbmQgaGVuY2UgYWRkcmVzc2VzKSB0aGF0IGNsaWVudCBoYXMuPC9GT05UPg0KPC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+SWYgdGhlIHBhY2tldCBnb2VzIHRocm91Z2ggYSByZWxheSwgdGhl IHJlbGF5IGNhbiBzYXkgb24gd2hpY2ggbGluazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhl IHBhY2tldCB3YXMgcmVjZWl2ZWQuJm5ic3A7IElmIGl0IGlzIHVuaWNhc3QgdGhyb3VnaCBhIHJv dXRlciwgdGhhdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+bm90IHRoZSBjYXNlLiZuYnNw OyBJbiB0aGUgY2FzZSB3aGVyZSBpdCBpcyB1bmljYXN0IHRocm91Z2ggYSByb3V0ZXIsPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj50aGVyZWZvcmUsIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBj aGVjayB0aGUgcHJlZml4IC0gd2UgY2FuIG9ubHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmFz c3VtZSB0aGF0IGl0IGlzIGNvcnJlY3QuJm5ic3A7IEluIHRoZSBjYXNlIHdoZXJlIGl0IGlzIG5v dCBjb3JyZWN0LCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnBhY2tldCBwcm9iYWJseSB3 b3VsZG4ndCBoYXZlIGdvdHRlbiB0byB1cywgYW5kIGV2ZW4gaWYgaXQgZGlkIHNvbWVob3c8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmdldCB0byB1cywgd2UgY291bGRuJ3QgcmVwbHksIGJlY2F1 c2Ugb3VyIHJlcGx5IHdpbGwgZ28gdG8gdGhlIGxpbms8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PndoZXJlIHRoZSBwcmVmaXggKmlzKiB2YWxpZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg X01lbGxvTl88L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=wbdYykMRFcU4mBQPfL2cjUw0FlVb9zBqBOPjtwXY6wqil7Rbebc291A5-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:19:17 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02219; Wed, 18 Jul 2001 19:19:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INJiL15966; Wed, 18 Jul 2001 19:19:44 -0400 (EDT) Received: from mail-gw01.gap.com ([206.16.32.97]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INJZL00582 for ; Wed, 18 Jul 2001 19:19:35 -0400 (EDT) Received: from mailhub01.gap.com (mailhub01.gap.com [9.32.202.151]) by mail-gw01.gap.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA07771 for ; Wed, 18 Jul 2001 16:18:55 -0700 (PDT) From: Relfe_Tan@gap.com Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43]) by mailhub01.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id QAA20145 for ; Wed, 18 Jul 2001 16:19:27 -0700 (PDT) Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A8D.007FB0C4 ; Wed, 18 Jul 2001 16:14:42 -0700 X-Lotus-FromDomain: GAPINC To: DHCPv6 discussion list Message-ID: <88256A8D.007FAF71.00@smtpmta01.gap.com> Date: Wed, 18 Jul 2001 16:17:15 -0700 Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=s26QT2Ik8wu348bva2lFy1AKuejFUstvijfJvIAhfsml0uj6xDZUF0dv" Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --0__=s26QT2Ik8wu348bva2lFy1AKuejFUstvijfJvIAhfsml0uj6xDZUF0dv Content-type: text/plain; charset=us-ascii Content-Disposition: inline unsubscribe "Bernie Volz (EUD)" on 07/18/2001 04:10:07 PM Please respond to dhcp-v6@bucknell.edu To: "DHCPv6 discussion list" cc: (bcc: Relfe Tan/SB/GAPINC) Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] OK. I understand your point. BTW, I was originally thinking that only the Reply to a Confirm message would do this prefix checking and hence return a NoPrefixMatch status. But, even that would not have been safe. Note that text for the "Server Unicast Option": "This option is used by a server to send to a client to inform the client it can send a Request, Renew, Confirm, Release, and Decline by unicasting directly to the server instead of the All DHCPv6 Agents multicast adress as an optimization." I think we need to change this OR we need to add a statement to the prefix checking that prohibits it if the server can't tell where the client is. Now, this raises the nasty issue of if the client unicasts a message, how does the server reply to it (I already raised this issue). One solution is to use the IPv6 Source Address - but that has problems since then why not always use it? Another is for the server to save information on how to reach the client (which it might need to do anyway to send it Reconfigure-Inits?) via a Relay (or directly if on-link). But this is messy and what if the client has moved (I guess you could argue then it might not need to be Reconfigured)? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 6:51 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] IIRC = If I Recall Correctly > What difference does that make? A Release or Decline can be unicast as well > (if the client has another address - in a different IA - than what it is > releasing and the server has told the client it can unicast). The server doesn't need to make a determination as to what link the client is on in the case of Release. Decline probably does need to go through the relay. > Why does *HOW* the packet was sent make any difference? Remember, we're > dealing with MANY addresses so an individual message's IAs have nothing to > do with other IAs (and hence addresses) that client has. If the packet goes through a relay, the relay can say on which link the packet was received. If it is unicast through a router, that is not the case. In the case where it is unicast through a router, therefore, it doesn't make sense to check the prefix - we can only assume that it is correct. In the case where it is not correct, the packet probably wouldn't have gotten to us, and even if it did somehow get to us, we couldn't reply, because our reply will go to the link where the prefix *is* valid. _MelloN_ --0__=s26QT2Ik8wu348bva2lFy1AKuejFUstvijfJvIAhfsml0uj6xDZUF0dv Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC4xOSI+DQo8VElUTEU+UkU6IERI Q1BOQUNLIGZvciBESENQdjYgW1Byb3Bvc2VkIERyYWZ0IENoYW5nZXNdIDwvVElUTEU+DQo8L0hF QUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPk9LLiBJIHVuZGVyc3RhbmQgeW91ciBwb2lu dC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5CVFcsIEkgd2FzIG9yaWdpbmFsbHkg dGhpbmtpbmcgdGhhdCBvbmx5IHRoZSBSZXBseSB0byBhIENvbmZpcm0gbWVzc2FnZTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+d291bGQgZG8gdGhpcyBwcmVmaXggY2hlY2tpbmcgYW5kIGhlbmNl IHJldHVybiBhIE5vUHJlZml4TWF0Y2ggc3RhdHVzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPkJ1dCwgZXZlbiB0aGF0IHdvdWxkIG5vdCBoYXZlIGJlZW4gc2FmZS4gTm90ZSB0aGF0 IHRleHQgZm9yIHRoZSAmcXVvdDtTZXJ2ZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlVuaWNh c3QgT3B0aW9uJnF1b3Q7OjwvRk9OVD4NCjwvUD4NCg0KPFA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIFNJWkU9Mj4mcXVvdDtUaGlzIG9wdGlvbiBpcyB1 c2VkIGJ5IGEgc2VydmVyIHRvIHNlbmQgdG8gYSBjbGllbnQgdG8gaW5mb3JtIHRoZTwvRk9OVD4N CjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0la RT0yPmNsaWVudCBpdCBjYW4gc2VuZCBhIFJlcXVlc3QsIFJlbmV3LCBDb25maXJtLCBSZWxlYXNl LCBhbmQgRGVjbGluZTwvRk9OVD4NCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPmJ5IHVuaWNhc3RpbmcgZGlyZWN0bHkgdG8gdGhlIHNl cnZlciBpbnN0ZWFkIG9mIHRoZSBBbGwgREhDUHY2IEFnZW50czwvRk9OVD4NCjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPm11bHRpY2Fz dCBhZHJlc3MgYXMgYW4gb3B0aW1pemF0aW9uLiZxdW90OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkkgdGhpbmsgd2UgbmVlZCB0byBjaGFuZ2UgdGhpcyBPUiB3ZSBuZWVkIHRvIGFk ZCBhIHN0YXRlbWVudCB0byB0aGUgcHJlZml4PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5jaGVj a2luZyB0aGF0IHByb2hpYml0cyBpdCBpZiB0aGUgc2VydmVyIGNhbid0IHRlbGwgd2hlcmUgdGhl IGNsaWVudCBpcy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Ob3csIHRoaXMgcmFp c2VzIHRoZSBuYXN0eSBpc3N1ZSBvZiBpZiB0aGUgY2xpZW50IHVuaWNhc3RzIGEgbWVzc2FnZSwg aG93PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5kb2VzIHRoZSBzZXJ2ZXIgcmVwbHkgdG8gaXQg KEkgYWxyZWFkeSByYWlzZWQgdGhpcyBpc3N1ZSkuIE9uZSBzb2x1dGlvbiBpczwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+dG8gdXNlIHRoZSBJUHY2IFNvdXJjZSBBZGRyZXNzIC0gYnV0IHRoYXQg aGFzIHByb2JsZW1zIHNpbmNlIHRoZW4gd2h5IG5vdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ YWx3YXlzIHVzZSBpdD8gQW5vdGhlciBpcyBmb3IgdGhlIHNlcnZlciB0byBzYXZlIGluZm9ybWF0 aW9uIG9uIGhvdyB0byByZWFjaDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlIGNsaWVudCAo d2hpY2ggaXQgbWlnaHQgbmVlZCB0byBkbyBhbnl3YXkgdG8gc2VuZCBpdCBSZWNvbmZpZ3VyZS1J bml0cz8pPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj52aWEgYSBSZWxheSAob3IgZGlyZWN0bHkg aWYgb24tbGluaykuIEJ1dCB0aGlzIGlzIG1lc3N5IGFuZCB3aGF0IGlmIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGhhcyBtb3ZlZCAoSSBndWVzcyB5b3UgY291bGQgYXJndWUg dGhlbiBpdCBtaWdodCBub3QgbmVlZCB0byBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UmVj b25maWd1cmVkKT88L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tIEJlcm5pZTwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBUZWQgTGVtb24gWzxBIEhSRUY9Im1haWx0bzpt ZWxsb25Abm9taW51bS5jb20iPm1haWx0bzptZWxsb25Abm9taW51bS5jb208L0E+XTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+U2VudDogV2VkbmVzZGF5LCBKdWx5IDE4LCAyMDAxIDY6NTEgUE08 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBESENQdjYgZGlzY3Vzc2lvbiBsaXN0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSZTogREhDUE5BQ0sgZm9yIERIQ1B2NiBbUHJv cG9zZWQgRHJhZnQgQ2hhbmdlc10gPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9O VCBTSVpFPTI+SUlSQyA9IElmIEkgUmVjYWxsIENvcnJlY3RseTwvRk9OVD4NCjwvUD4NCg0KPFA+ PEZPTlQgU0laRT0yPiZndDsgV2hhdCBkaWZmZXJlbmNlIGRvZXMgdGhhdCBtYWtlPyBBIFJlbGVh c2Ugb3IgRGVjbGluZSBjYW4gYmUgdW5pY2FzdCBhcyB3ZWxsPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IChpZiB0aGUgY2xpZW50IGhhcyBhbm90aGVyIGFkZHJlc3MgLSBpbiBhIGRpZmZl cmVudCBJQSAtIHRoYW4gd2hhdCBpdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBy ZWxlYXNpbmcgYW5kIHRoZSBzZXJ2ZXIgaGFzIHRvbGQgdGhlIGNsaWVudCBpdCBjYW4gdW5pY2Fz dCkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIHNlcnZlciBkb2Vzbid0IG5l ZWQgdG8gbWFrZSBhIGRldGVybWluYXRpb24gYXMgdG8gd2hhdCBsaW5rIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGlzIG9uIGluIHRoZSBjYXNlIG9mIFJlbGVhc2UuJm5ic3A7 Jm5ic3A7IERlY2xpbmUgcHJvYmFibHkgZG9lcyBuZWVkIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5nbyB0aHJvdWdoIHRoZSByZWxheS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj4mZ3Q7IFdoeSBkb2VzICpIT1cqIHRoZSBwYWNrZXQgd2FzIHNlbnQgbWFrZSBhbnkgZGlmZmVy ZW5jZT8gUmVtZW1iZXIsIHdlJ3JlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRlYWxp bmcgd2l0aCBNQU5ZIGFkZHJlc3NlcyBzbyBhbiBpbmRpdmlkdWFsIG1lc3NhZ2UncyBJQXMgaGF2 ZSBub3RoaW5nIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRvIHdpdGggb3RoZXIg SUFzIChhbmQgaGVuY2UgYWRkcmVzc2VzKSB0aGF0IGNsaWVudCBoYXMuPC9GT05UPg0KPC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+SWYgdGhlIHBhY2tldCBnb2VzIHRocm91Z2ggYSByZWxheSwgdGhl IHJlbGF5IGNhbiBzYXkgb24gd2hpY2ggbGluazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhl IHBhY2tldCB3YXMgcmVjZWl2ZWQuJm5ic3A7IElmIGl0IGlzIHVuaWNhc3QgdGhyb3VnaCBhIHJv dXRlciwgdGhhdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+bm90IHRoZSBjYXNlLiZuYnNw OyBJbiB0aGUgY2FzZSB3aGVyZSBpdCBpcyB1bmljYXN0IHRocm91Z2ggYSByb3V0ZXIsPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj50aGVyZWZvcmUsIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBj aGVjayB0aGUgcHJlZml4IC0gd2UgY2FuIG9ubHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmFz c3VtZSB0aGF0IGl0IGlzIGNvcnJlY3QuJm5ic3A7IEluIHRoZSBjYXNlIHdoZXJlIGl0IGlzIG5v dCBjb3JyZWN0LCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnBhY2tldCBwcm9iYWJseSB3 b3VsZG4ndCBoYXZlIGdvdHRlbiB0byB1cywgYW5kIGV2ZW4gaWYgaXQgZGlkIHNvbWVob3c8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmdldCB0byB1cywgd2UgY291bGRuJ3QgcmVwbHksIGJlY2F1 c2Ugb3VyIHJlcGx5IHdpbGwgZ28gdG8gdGhlIGxpbms8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PndoZXJlIHRoZSBwcmVmaXggKmlzKiB2YWxpZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg X01lbGxvTl88L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=s26QT2Ik8wu348bva2lFy1AKuejFUstvijfJvIAhfsml0uj6xDZUF0dv-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:19:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA02333; Wed, 18 Jul 2001 19:19:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INK7L02864; Wed, 18 Jul 2001 19:20:07 -0400 (EDT) Received: from mail-gw01.gap.com ([206.16.32.97]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INJtL11941 for ; Wed, 18 Jul 2001 19:19:55 -0400 (EDT) Received: from mailhub02.gap.com (mailhub02.gap.com [9.32.202.152]) by mail-gw01.gap.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA07831 for ; Wed, 18 Jul 2001 16:19:14 -0700 (PDT) From: Relfe_Tan@gap.com Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43]) by mailhub02.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id QAA03998 for ; Wed, 18 Jul 2001 16:17:28 -0700 (PDT) Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A8D.007FB298 ; Wed, 18 Jul 2001 16:14:47 -0700 X-Lotus-FromDomain: GAPINC To: DHCPv6 discussion list Message-ID: <88256A8D.007FB0AF.00@smtpmta01.gap.com> Date: Wed, 18 Jul 2001 16:17:21 -0700 Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=AfsygFcaIRtUia2YIUG6zifz5hQ1JnLzTyxQRxUTLqMTDUlX59L9kA6a" Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --0__=AfsygFcaIRtUia2YIUG6zifz5hQ1JnLzTyxQRxUTLqMTDUlX59L9kA6a Content-type: text/plain; charset=us-ascii Content-Disposition: inline unsubscribe "Bernie Volz (EUD)" on 07/18/2001 04:10:07 PM Please respond to dhcp-v6@bucknell.edu To: "DHCPv6 discussion list" cc: (bcc: Relfe Tan/SB/GAPINC) Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] OK. I understand your point. BTW, I was originally thinking that only the Reply to a Confirm message would do this prefix checking and hence return a NoPrefixMatch status. But, even that would not have been safe. Note that text for the "Server Unicast Option": "This option is used by a server to send to a client to inform the client it can send a Request, Renew, Confirm, Release, and Decline by unicasting directly to the server instead of the All DHCPv6 Agents multicast adress as an optimization." I think we need to change this OR we need to add a statement to the prefix checking that prohibits it if the server can't tell where the client is. Now, this raises the nasty issue of if the client unicasts a message, how does the server reply to it (I already raised this issue). One solution is to use the IPv6 Source Address - but that has problems since then why not always use it? Another is for the server to save information on how to reach the client (which it might need to do anyway to send it Reconfigure-Inits?) via a Relay (or directly if on-link). But this is messy and what if the client has moved (I guess you could argue then it might not need to be Reconfigured)? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 6:51 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] IIRC = If I Recall Correctly > What difference does that make? A Release or Decline can be unicast as well > (if the client has another address - in a different IA - than what it is > releasing and the server has told the client it can unicast). The server doesn't need to make a determination as to what link the client is on in the case of Release. Decline probably does need to go through the relay. > Why does *HOW* the packet was sent make any difference? Remember, we're > dealing with MANY addresses so an individual message's IAs have nothing to > do with other IAs (and hence addresses) that client has. If the packet goes through a relay, the relay can say on which link the packet was received. If it is unicast through a router, that is not the case. In the case where it is unicast through a router, therefore, it doesn't make sense to check the prefix - we can only assume that it is correct. In the case where it is not correct, the packet probably wouldn't have gotten to us, and even if it did somehow get to us, we couldn't reply, because our reply will go to the link where the prefix *is* valid. _MelloN_ --0__=AfsygFcaIRtUia2YIUG6zifz5hQ1JnLzTyxQRxUTLqMTDUlX59L9kA6a Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1NC4xOSI+DQo8VElUTEU+UkU6IERI Q1BOQUNLIGZvciBESENQdjYgW1Byb3Bvc2VkIERyYWZ0IENoYW5nZXNdIDwvVElUTEU+DQo8L0hF QUQ+DQo8Qk9EWT4NCg0KPFA+PEZPTlQgU0laRT0yPk9LLiBJIHVuZGVyc3RhbmQgeW91ciBwb2lu dC48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5CVFcsIEkgd2FzIG9yaWdpbmFsbHkg dGhpbmtpbmcgdGhhdCBvbmx5IHRoZSBSZXBseSB0byBhIENvbmZpcm0gbWVzc2FnZTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+d291bGQgZG8gdGhpcyBwcmVmaXggY2hlY2tpbmcgYW5kIGhlbmNl IHJldHVybiBhIE5vUHJlZml4TWF0Y2ggc3RhdHVzLjwvRk9OVD4NCjwvUD4NCg0KPFA+PEZPTlQg U0laRT0yPkJ1dCwgZXZlbiB0aGF0IHdvdWxkIG5vdCBoYXZlIGJlZW4gc2FmZS4gTm90ZSB0aGF0 IHRleHQgZm9yIHRoZSAmcXVvdDtTZXJ2ZXI8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlVuaWNh c3QgT3B0aW9uJnF1b3Q7OjwvRk9OVD4NCjwvUD4NCg0KPFA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxGT05UIFNJWkU9Mj4mcXVvdDtUaGlzIG9wdGlvbiBpcyB1 c2VkIGJ5IGEgc2VydmVyIHRvIHNlbmQgdG8gYSBjbGllbnQgdG8gaW5mb3JtIHRoZTwvRk9OVD4N CjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0la RT0yPmNsaWVudCBpdCBjYW4gc2VuZCBhIFJlcXVlc3QsIFJlbmV3LCBDb25maXJtLCBSZWxlYXNl LCBhbmQgRGVjbGluZTwvRk9OVD4NCjxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPmJ5IHVuaWNhc3RpbmcgZGlyZWN0bHkgdG8gdGhlIHNl cnZlciBpbnN0ZWFkIG9mIHRoZSBBbGwgREhDUHY2IEFnZW50czwvRk9OVD4NCjxCUj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPEZPTlQgU0laRT0yPm11bHRpY2Fz dCBhZHJlc3MgYXMgYW4gb3B0aW1pemF0aW9uLiZxdW90OzwvRk9OVD4NCjwvUD4NCg0KPFA+PEZP TlQgU0laRT0yPkkgdGhpbmsgd2UgbmVlZCB0byBjaGFuZ2UgdGhpcyBPUiB3ZSBuZWVkIHRvIGFk ZCBhIHN0YXRlbWVudCB0byB0aGUgcHJlZml4PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5jaGVj a2luZyB0aGF0IHByb2hpYml0cyBpdCBpZiB0aGUgc2VydmVyIGNhbid0IHRlbGwgd2hlcmUgdGhl IGNsaWVudCBpcy48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj5Ob3csIHRoaXMgcmFp c2VzIHRoZSBuYXN0eSBpc3N1ZSBvZiBpZiB0aGUgY2xpZW50IHVuaWNhc3RzIGEgbWVzc2FnZSwg aG93PC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj5kb2VzIHRoZSBzZXJ2ZXIgcmVwbHkgdG8gaXQg KEkgYWxyZWFkeSByYWlzZWQgdGhpcyBpc3N1ZSkuIE9uZSBzb2x1dGlvbiBpczwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+dG8gdXNlIHRoZSBJUHY2IFNvdXJjZSBBZGRyZXNzIC0gYnV0IHRoYXQg aGFzIHByb2JsZW1zIHNpbmNlIHRoZW4gd2h5IG5vdDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+ YWx3YXlzIHVzZSBpdD8gQW5vdGhlciBpcyBmb3IgdGhlIHNlcnZlciB0byBzYXZlIGluZm9ybWF0 aW9uIG9uIGhvdyB0byByZWFjaDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhlIGNsaWVudCAo d2hpY2ggaXQgbWlnaHQgbmVlZCB0byBkbyBhbnl3YXkgdG8gc2VuZCBpdCBSZWNvbmZpZ3VyZS1J bml0cz8pPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj52aWEgYSBSZWxheSAob3IgZGlyZWN0bHkg aWYgb24tbGluaykuIEJ1dCB0aGlzIGlzIG1lc3N5IGFuZCB3aGF0IGlmIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGhhcyBtb3ZlZCAoSSBndWVzcyB5b3UgY291bGQgYXJndWUg dGhlbiBpdCBtaWdodCBub3QgbmVlZCB0byBiZTwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+UmVj b25maWd1cmVkKT88L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9Mj4tIEJlcm5pZTwvRk9O VD4NCjwvUD4NCg0KPFA+PEZPTlQgU0laRT0yPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9Mj5Gcm9tOiBUZWQgTGVtb24gWzxBIEhSRUY9Im1haWx0bzpt ZWxsb25Abm9taW51bS5jb20iPm1haWx0bzptZWxsb25Abm9taW51bS5jb208L0E+XTwvRk9OVD4N CjxCUj48Rk9OVCBTSVpFPTI+U2VudDogV2VkbmVzZGF5LCBKdWx5IDE4LCAyMDAxIDY6NTEgUE08 L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPlRvOiBESENQdjYgZGlzY3Vzc2lvbiBsaXN0PC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj5TdWJqZWN0OiBSZTogREhDUE5BQ0sgZm9yIERIQ1B2NiBbUHJv cG9zZWQgRHJhZnQgQ2hhbmdlc10gPC9GT05UPg0KPC9QPg0KPEJSPg0KPEJSPg0KDQo8UD48Rk9O VCBTSVpFPTI+SUlSQyA9IElmIEkgUmVjYWxsIENvcnJlY3RseTwvRk9OVD4NCjwvUD4NCg0KPFA+ PEZPTlQgU0laRT0yPiZndDsgV2hhdCBkaWZmZXJlbmNlIGRvZXMgdGhhdCBtYWtlPyBBIFJlbGVh c2Ugb3IgRGVjbGluZSBjYW4gYmUgdW5pY2FzdCBhcyB3ZWxsPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj4mZ3Q7IChpZiB0aGUgY2xpZW50IGhhcyBhbm90aGVyIGFkZHJlc3MgLSBpbiBhIGRpZmZl cmVudCBJQSAtIHRoYW4gd2hhdCBpdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+Jmd0OyBy ZWxlYXNpbmcgYW5kIHRoZSBzZXJ2ZXIgaGFzIHRvbGQgdGhlIGNsaWVudCBpdCBjYW4gdW5pY2Fz dCkuPC9GT05UPg0KPC9QPg0KDQo8UD48Rk9OVCBTSVpFPTI+VGhlIHNlcnZlciBkb2Vzbid0IG5l ZWQgdG8gbWFrZSBhIGRldGVybWluYXRpb24gYXMgdG8gd2hhdCBsaW5rIHRoZTwvRk9OVD4NCjxC Uj48Rk9OVCBTSVpFPTI+Y2xpZW50IGlzIG9uIGluIHRoZSBjYXNlIG9mIFJlbGVhc2UuJm5ic3A7 Jm5ic3A7IERlY2xpbmUgcHJvYmFibHkgZG9lcyBuZWVkIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJ WkU9Mj5nbyB0aHJvdWdoIHRoZSByZWxheS48L0ZPTlQ+DQo8L1A+DQoNCjxQPjxGT05UIFNJWkU9 Mj4mZ3Q7IFdoeSBkb2VzICpIT1cqIHRoZSBwYWNrZXQgd2FzIHNlbnQgbWFrZSBhbnkgZGlmZmVy ZW5jZT8gUmVtZW1iZXIsIHdlJ3JlPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRlYWxp bmcgd2l0aCBNQU5ZIGFkZHJlc3NlcyBzbyBhbiBpbmRpdmlkdWFsIG1lc3NhZ2UncyBJQXMgaGF2 ZSBub3RoaW5nIHRvPC9GT05UPg0KPEJSPjxGT05UIFNJWkU9Mj4mZ3Q7IGRvIHdpdGggb3RoZXIg SUFzIChhbmQgaGVuY2UgYWRkcmVzc2VzKSB0aGF0IGNsaWVudCBoYXMuPC9GT05UPg0KPC9QPg0K DQo8UD48Rk9OVCBTSVpFPTI+SWYgdGhlIHBhY2tldCBnb2VzIHRocm91Z2ggYSByZWxheSwgdGhl IHJlbGF5IGNhbiBzYXkgb24gd2hpY2ggbGluazwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+dGhl IHBhY2tldCB3YXMgcmVjZWl2ZWQuJm5ic3A7IElmIGl0IGlzIHVuaWNhc3QgdGhyb3VnaCBhIHJv dXRlciwgdGhhdCBpczwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTI+bm90IHRoZSBjYXNlLiZuYnNw OyBJbiB0aGUgY2FzZSB3aGVyZSBpdCBpcyB1bmljYXN0IHRocm91Z2ggYSByb3V0ZXIsPC9GT05U Pg0KPEJSPjxGT05UIFNJWkU9Mj50aGVyZWZvcmUsIGl0IGRvZXNuJ3QgbWFrZSBzZW5zZSB0byBj aGVjayB0aGUgcHJlZml4IC0gd2UgY2FuIG9ubHk8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPmFz c3VtZSB0aGF0IGl0IGlzIGNvcnJlY3QuJm5ic3A7IEluIHRoZSBjYXNlIHdoZXJlIGl0IGlzIG5v dCBjb3JyZWN0LCB0aGU8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0yPnBhY2tldCBwcm9iYWJseSB3 b3VsZG4ndCBoYXZlIGdvdHRlbiB0byB1cywgYW5kIGV2ZW4gaWYgaXQgZGlkIHNvbWVob3c8L0ZP TlQ+DQo8QlI+PEZPTlQgU0laRT0yPmdldCB0byB1cywgd2UgY291bGRuJ3QgcmVwbHksIGJlY2F1 c2Ugb3VyIHJlcGx5IHdpbGwgZ28gdG8gdGhlIGxpbms8L0ZPTlQ+DQo8QlI+PEZPTlQgU0laRT0y PndoZXJlIHRoZSBwcmVmaXggKmlzKiB2YWxpZC48L0ZPTlQ+DQo8L1A+DQoNCjxQPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDxGT05UIFNJWkU9Mj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg X01lbGxvTl88L0ZPTlQ+DQo8L1A+DQoNCjwvQk9EWT4NCjwvSFRNTD4NCg== --0__=AfsygFcaIRtUia2YIUG6zifz5hQ1JnLzTyxQRxUTLqMTDUlX59L9kA6a-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:23:07 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03347; Wed, 18 Jul 2001 19:23:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INNWL22292; Wed, 18 Jul 2001 19:23:32 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INNLL01086 for ; Wed, 18 Jul 2001 19:23:21 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6INN5513592 for ; Wed, 18 Jul 2001 18:23:05 -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 f6INN5X15861 for ; Wed, 18 Jul 2001 18:23:05 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jul 18 18:23:05 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKHGWP>; Wed, 18 Jul 2001 18:23:04 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32CF@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Wed, 18 Jul 2001 18:23:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FE0.96E6BEC0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10FE0.96E6BEC0 Content-Type: text/plain; charset="iso-8859-1" While moving this functionality to the Relays is certainly very interesting: - Servers will need to do it anyway (what if no relays) - Servers have more complete network knowledge. While a router may be a relay, a relay does not have to be a router. Sure, the relay could look at the Router Advertisements (or the hosts routing table) to see what prefixes are currently valid. - I think most vendors would rather have relays be relatively dumb? And, (IIRC) I don't believe there is anything in the spec prohibiting it at this point? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 7:09 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > The format of "Error Code" option is not specified in the draft. It is > needed to be included. I think it goes into the IA option, but you're right - it needs to be clarified. > It will be better, if this functionality can be incorporated in the > agent,since, it is the only thing which knows well about the prefix in which > the client message is received. And the advantage is, if this checking is > done, this packet can be prevented from forwarding it to the multiple > servers and save multiple processing time. The agent itself can send the > NoPrefixMatch status directly to the client. Ooh, good point! I think it would be good if the agent could do this, although I have to admit that I am concerned that some people who implement relay agents may not want to have to delve into the IA to validate a packet. I'm in favor of doing as you suggest, but I suggest that we defer to the working group to see if any router vendors have a problem with this. Also, the timing is a bit tight on making this change, and I wouldn't blame the authors if they said "no, sorry, do this in a new draft." I think it's okay to make this optional, so doing it in a seperate draft should be fine. > If the client is receiving the error status as NoPrefixMatch error, what > may be the reason other than client's plugging in to different subnet. I > agree that, some roghe server can send this status, but, it can be prevented > by authentication. The client may be mobile, and may be able to reach more than one mobile access point. The two access points may want to think of themselves as seperate links, even though their physical link-layers overlap. I don't know how likely this is with existing technology, but it's certainly been discussed with respect to 3G phones. I think it's important to leave the language open for this case. _MelloN_ ------_=_NextPart_001_01C10FE0.96E6BEC0 Content-Type: text/html; charset="iso-8859-1" RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

While moving this functionality to the Relays is certainly very interesting:
- Servers will need to do it anyway (what if no relays)
- Servers have more complete network knowledge. While a router may be a relay,
a relay does not have to be a router. Sure, the relay could look at the Router
Advertisements (or the hosts routing table) to see what prefixes are currently
valid.
- I think most vendors would rather have relays be relatively dumb?

And, (IIRC) I don't believe there is anything in the spec prohibiting it at
this point?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, July 18, 2001 7:09 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]



>   The format of "Error Code" option is not specified in the draft. It is
> needed to be included.

I think it goes into the IA option, but you're right - it needs to be
clarified.

>   It will be better, if this functionality can be incorporated in the
> agent,since, it is the only thing which knows well about the prefix in which
> the client message is received. And the advantage is, if this checking is
> done, this packet can be prevented from forwarding it to the multiple
> servers and save multiple processing time. The agent itself can send the
> NoPrefixMatch status directly to the client.

Ooh, good point!   I think it would be good if the agent could do
this, although I have to admit that I am concerned that some people
who implement relay agents may not want to have to delve into the IA
to validate a packet.   I'm in favor of doing as you suggest, but I
suggest that we defer to the working group to see if any router
vendors have a problem with this.

Also, the timing is a bit tight on making this change, and I wouldn't
blame the authors if they said "no, sorry, do this in a new draft."  I
think it's okay to make this optional, so doing it in a seperate draft
should be fine.

>   If the client is receiving the error status as NoPrefixMatch error, what
> may be the reason other than client's plugging in to different subnet. I
> agree that, some roghe server can send this status, but, it can be prevented
> by authentication.

The client may be mobile, and may be able to reach more than one
mobile access point.  The two access points may want to think of
themselves as seperate links, even though their physical link-layers
overlap.  I don't know how likely this is with existing technology,
but it's certainly been discussed with respect to 3G phones.  I think
it's important to leave the language open for this case.

                               _MelloN_

------_=_NextPart_001_01C10FE0.96E6BEC0-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:28:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04864; Wed, 18 Jul 2001 19:28:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INSSL27798; Wed, 18 Jul 2001 19:28:28 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INSGL17021 for ; Wed, 18 Jul 2001 19:28:16 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6INO4f15199 for ; Wed, 18 Jul 2001 16:24:04 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6INNvw00886 for ; Wed, 18 Jul 2001 16:23:57 -0700 (MST) Message-Id: <200107182323.f6INNvw00886@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 18 Jul 2001 18:15:36 EST." <66F66129A77AD411B76200508B65AC697B32CE@eambunt705.ena-east.ericsson.se> Date: Wed, 18 Jul 2001 16:23:57 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > For example, if a server receives a Confirm for a global prefix it has no > knowledge of, why does it care where it came from? If it can send a Reply > back to the client, it can tell it - hey, you're using invalid prefixes. Sure. But it can't get such a unicast message unless the client already has an address with a valid prefix (by valid, I mean that the server can successfully send a packet to the client, not just that a site-local prefix looks valid by coincidence). So this case isn't one that we need to deal with, as far as I can see. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:31:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06182; Wed, 18 Jul 2001 19:31:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INW7L18787; Wed, 18 Jul 2001 19:32:07 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INVsL17460 for ; Wed, 18 Jul 2001 19:31:54 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6INVd515291 for ; Wed, 18 Jul 2001 18:31:39 -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 f6INVdb06958 for ; Wed, 18 Jul 2001 18:31:39 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Jul 18 18:31:30 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CP20RRA>; Wed, 18 Jul 2001 18:31:30 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32D2@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Wed, 18 Jul 2001 18:31:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FE1.C4D869E0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C10FE1.C4D869E0 Content-Type: text/plain; charset="iso-8859-1" Why? The Confirm is multicast by the client, picked up a relay and sent to a server. The server can return the Reply the same way. Or, what about the case where the client and server are on the same link? In both these cases all the client needs is a valid link local address. Nothing else to communicate between client/server. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 7:24 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > For example, if a server receives a Confirm for a global prefix it has no > knowledge of, why does it care where it came from? If it can send a Reply > back to the client, it can tell it - hey, you're using invalid prefixes. Sure. But it can't get such a unicast message unless the client already has an address with a valid prefix (by valid, I mean that the server can successfully send a packet to the client, not just that a site-local prefix looks valid by coincidence). So this case isn't one that we need to deal with, as far as I can see. _MelloN_ ------_=_NextPart_001_01C10FE1.C4D869E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

Why?

The Confirm is multicast by the client, picked up a = relay and sent to a server.

The server can return the Reply the same way.

Or, what about the case where the client and server = are on the same link?

In both these cases all the client needs is a valid = link local address. Nothing
else to communicate between client/server.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Wednesday, July 18, 2001 7:24 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft = Changes]



> For example, if a server receives a Confirm for = a global prefix it has no
> knowledge of, why does it care where it came = from? If it can send a Reply
> back to the client, it can tell it - hey, = you're using invalid prefixes.

Sure.  But it can't get such a unicast message = unless the client
already has an address with a valid prefix (by = valid, I mean that the
server can successfully send a packet to the client, = not just that a
site-local prefix looks valid by coincidence).  = So this case isn't one
that we need to deal with, as far as I can = see.

        =         =                _MelloN_

------_=_NextPart_001_01C10FE1.C4D869E0-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:35:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA07292; Wed, 18 Jul 2001 19:35:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INZVL22164; Wed, 18 Jul 2001 19:35:31 -0400 (EDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INZOL24618 for ; Wed, 18 Jul 2001 19:35:25 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel2.hp.com (Postfix) with ESMTP id 0FAF313A8 for ; Wed, 18 Jul 2001 16:35:22 -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 FAA26562 for ; Thu, 19 Jul 2001 05:02:22 +0530 (IST) Reply-To: From: "Vijay Bhaskar A K" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 19 Jul 2001 05:05:14 +0530 Message-ID: <000601c10fe2$4bcdab40$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01C11010.6585E740" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <66F66129A77AD411B76200508B65AC697B32CF@eambunt705.ena-east.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------=_NextPart_000_0007_01C11010.6585E740 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] -----Original Message----- From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On Behalf Of Bernie Volz (EUD) Sent: Thursday, July 19, 2001 4:53 AM To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] While moving this functionality to the Relays is certainly very interesting: - Servers will need to do it anyway (what if no relays) - Servers have more complete network knowledge. While a router may be a relay, a relay does not have to be a router. Sure, the relay could look at the Router Advertisements (or the hosts routing table) to see what prefixes are currently valid. [Vijay Bhaskar A K] *********** I think, the relay needs to know at what interface the packet is received. Using that, it can tell prefix is matching or not, i guess. - I think most vendors would rather have relays be relatively dumb? And, (IIRC) I don't believe there is anything in the spec prohibiting it at this point? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, July 18, 2001 7:09 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > The format of "Error Code" option is not specified in the draft. It is > needed to be included. I think it goes into the IA option, but you're right - it needs to be clarified. > It will be better, if this functionality can be incorporated in the > agent,since, it is the only thing which knows well about the prefix in which > the client message is received. And the advantage is, if this checking is > done, this packet can be prevented from forwarding it to the multiple > servers and save multiple processing time. The agent itself can send the > NoPrefixMatch status directly to the client. Ooh, good point! I think it would be good if the agent could do this, although I have to admit that I am concerned that some people who implement relay agents may not want to have to delve into the IA to validate a packet. I'm in favor of doing as you suggest, but I suggest that we defer to the working group to see if any router vendors have a problem with this. Also, the timing is a bit tight on making this change, and I wouldn't blame the authors if they said "no, sorry, do this in a new draft." I think it's okay to make this optional, so doing it in a seperate draft should be fine. > If the client is receiving the error status as NoPrefixMatch error, what > may be the reason other than client's plugging in to different subnet. I > agree that, some roghe server can send this status, but, it can be prevented > by authentication. The client may be mobile, and may be able to reach more than one mobile access point. The two access points may want to think of themselves as seperate links, even though their physical link-layers overlap. I don't know how likely this is with existing technology, but it's certainly been discussed with respect to 3G phones. I think it's important to leave the language open for this case. _MelloN_ ------=_NextPart_000_0007_01C11010.6585E740 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]
 
-----Original Message-----
From: = owner-dhcp-v6@bucknell.edu=20 [mailto:owner-dhcp-v6@bucknell.edu]On Behalf Of Bernie Volz=20 (EUD)
Sent: Thursday, July 19, 2001 4:53 AM
To: = DHCPv6=20 discussion list
Subject: RE: DHCPNACK for DHCPv6 [Proposed = Draft=20 Changes]

While moving this functionality to the Relays is = certainly=20 very interesting:
- Servers will need to do = it anyway=20 (what if no relays)
- Servers have more = complete=20 network knowledge. While a router may be a relay,
a=20 relay does not have to be a router. Sure, the relay could look at the=20 Router
Advertisements (or the hosts routing = table) to=20 see what prefixes are currently
valid.=20
[Vijay Bhaskar A=20 K] ***********

I = think, the=20 relay needs to know at what interface the packet=20 is received. Using that, it can tell prefix is matching = or not,=20 i guess. 
- I think most vendors would rather have relays be relatively = dumb?

And, (IIRC) I don't believe there is anything in the = spec=20 prohibiting it at
this point?

- Bernie

-----Original Message-----
From: Ted=20 Lemon [mailto:mellon@nominum.com] =
Sent: Wednesday, July 18, 2001 7:09 PM =
To: DHCPv6 discussion list
Cc: = DHCPv6=20 discussion list
Subject: Re: DHCPNACK for = DHCPv6=20 [Proposed Draft Changes]



>   The format of "Error Code" option = is not=20 specified in the draft. It is
> needed to = be=20 included.

I think it goes into the IA option, but you're right = - it=20 needs to be
clarified.

>   It will be better, if this = functionality can=20 be incorporated in the
> agent,since, it = is the=20 only thing which knows well about the prefix in which
> the client message is received. And the advantage is, if = this=20 checking is
> done, this packet can be = prevented=20 from forwarding it to the multiple
> = servers and=20 save multiple processing time. The agent itself can send the =
> NoPrefixMatch status directly to the client.

Ooh, good point!   I think it would be = good if the=20 agent could do
this, although I have to = admit that I=20 am concerned that some people
who implement = relay=20 agents may not want to have to delve into the IA
to=20 validate a packet.   I'm in favor of doing as you suggest, = but=20 I
suggest that we defer to the working group = to see if=20 any router
vendors have a problem with = this.=20

Also, the timing is a bit tight on making this = change, and I=20 wouldn't
blame the authors if they said "no, = sorry, do=20 this in a new draft."  I
think it's = okay to make=20 this optional, so doing it in a seperate draft
should=20 be fine.

>   If the client is receiving the = error status=20 as NoPrefixMatch error, what
> may be the = reason=20 other than client's plugging in to different subnet. I =
> agree that, some roghe server can send this status, but, = it can be=20 prevented
> by authentication. =

The client may be mobile, and may be able to reach = more than=20 one
mobile access point.  The two = access points=20 may want to think of
themselves as seperate = links,=20 even though their physical link-layers
overlap. =20 I don't know how likely this is with existing technology, =
but it's certainly been discussed with respect to 3G = phones.  I=20 think
it's important to leave the language = open for=20 this case.

       =20        =20                _MelloN_=20

------=_NextPart_000_0007_01C11010.6585E740-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:39:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08481; Wed, 18 Jul 2001 19:39:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INeOL27213; Wed, 18 Jul 2001 19:40:24 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INeFL22116 for ; Wed, 18 Jul 2001 19:40:15 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6INa2f15232 for ; Wed, 18 Jul 2001 16:36:02 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6INZtw00944 for ; Wed, 18 Jul 2001 16:35:55 -0700 (MST) Message-Id: <200107182335.f6INZtw00944@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 18 Jul 2001 18:31:28 EST." <66F66129A77AD411B76200508B65AC697B32D2@eambunt705.ena-east.ericsson.se> Date: Wed, 18 Jul 2001 16:35:55 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The Confirm is multicast by the client, picked up a relay and sent > to a server. Right, and that's why the language you wrote applies to the Confirm message! _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Jul 18 19:44:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09413; Wed, 18 Jul 2001 19:44:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6INjJL21987; Wed, 18 Jul 2001 19:45:19 -0400 (EDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6INj8L28690 for ; Wed, 18 Jul 2001 19:45:08 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel1.hp.com (Postfix) with ESMTP id BD6B61A13 for ; Wed, 18 Jul 2001 16:44:55 -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 FAA27379 for ; Thu, 19 Jul 2001 05:11:56 +0530 (IST) Reply-To: From: "Vijay Bhaskar A K" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 19 Jul 2001 05:14:49 +0530 Message-ID: <000d01c10fe3$a20b7fe0$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) In-Reply-To: <200107182308.f6IN8Zw00843@grosse.bisbee.fugue.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > Behalf Of Ted Lemon > Sent: Thursday, July 19, 2001 4:39 AM > To: DHCPv6 discussion list > Cc: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > > > The format of "Error Code" option is not specified in the > draft. It is > > needed to be included. > > I think it goes into the IA option, but you're right - it needs to be > clarified. No. What i meant was a seperate option called "Error Code" option. These error codes are specifically releated to IAs. So, these can occur in the IA as IA status. But there are some error status which are very generic. (e.g):- authfail,service not implemented, etc. These things should occur only in the generic error option. I think Ebi (hp) has given the specs to Ralph. I beleive, this option is necessary. > > > It will be better, if this functionality can be > incorporated in the > > agent,since, it is the only thing which knows well about > the prefix in which > > the client message is received. And the advantage is, if > this checking is > > done, this packet can be prevented from forwarding it to > the multiple > > servers and save multiple processing time. The agent itself > can send the > > NoPrefixMatch status directly to the client. > > Ooh, good point! I think it would be good if the agent could do > this, although I have to admit that I am concerned that some people > who implement relay agents may not want to have to delve into the IA > to validate a packet. I'm in favor of doing as you suggest, but I > suggest that we defer to the working group to see if any router > vendors have a problem with this. > > Also, the timing is a bit tight on making this change, and I wouldn't > blame the authors if they said "no, sorry, do this in a new draft." I > think it's okay to make this optional, so doing it in a seperate draft > should be fine. > > > If the client is receiving the error status as > NoPrefixMatch error, what > > may be the reason other than client's plugging in to > different subnet. I > > agree that, some roghe server can send this status, but, it > can be prevented > > by authentication. > > The client may be mobile, and may be able to reach more than one > mobile access point. The two access points may want to think of > themselves as seperate links, even though their physical link-layers > overlap. I don't know how likely this is with existing technology, > but it's certainly been discussed with respect to 3G phones. I think > it's important to leave the language open for this case. > > _MelloN_ > > From owner-dhcp-v6@bucknell.edu Wed Jul 18 20:18:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14926; Wed, 18 Jul 2001 20:18:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J0ICL05977; Wed, 18 Jul 2001 20:18:13 -0400 (EDT) Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6J0I2L28118 for ; Wed, 18 Jul 2001 20:18:02 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel1.hp.com (Postfix) with ESMTP id 90E2F1CC for ; Wed, 18 Jul 2001 20:17:58 -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 FAA29870 for ; Thu, 19 Jul 2001 05:44:52 +0530 (IST) Reply-To: From: "Vijay Bhaskar A K" To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses Date: Thu, 19 Jul 2001 05:47:45 +0530 Message-ID: <000e01c10fe8$3c0ae1e0$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C11016.55C31DE0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <66F66129A77AD411B76200508B65AC697B32CC@eambunt705.ena-east.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C11016.55C31DE0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit RE: Simplify release and decline of addresses -----Original Message----- From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On Behalf Of Bernie Volz (EUD) Sent: Thursday, July 19, 2001 4:27 AM To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses Vijay: Removing "addr status" in the IA option without also removing the T bit won't help save bytes since the T bit will require the byte anyway. We might change "addr status" to "unused - MBZ" though if we're not using it. [Vijay Bhaskar A K] What is the use of having "unused - MBZ". Is it related to allignment problem? But, do we need 4 octets for IAID? It will be hardly 4-5 IA's per client, in the normal case. But, if we reduce 1 byte in IAID, we can escape from alignment problem and another byte "addr status" is also freed. (provided, we are giving a seperate option for temporary address IA) Regarding a new option to handle Temporary Addresses, I think this has merit simply because there has been no way for a client to communicate what kind of addresses it wants. Having this option provides that mechanism. Alternatives, such as allowing 'num-addrs' and thus some address information (T bit) to be specified by the client in a Request were discussed at one point but did not make it into the -19 draft and I'm not sure if it would be in the -20. [Vijay Bhaskar A K] ********* Since, the temporary addresses are to be handled in a different way, we need to keep temporary addresses in a different IA option. This simplifies the IA option and make it easy to process temporary addresses. Perhaps Ralph and Jim will care to provide some indication of how this will be resolved in the -20 draft - to give the client some ability to communicate to the server what it needs. OR, perhaps the answer is simply "no, we're not going to support it - it is up to the server to figure it out." There are some issues with a new option - such as the IAID spaces must not overlap, [Vijay Bhaskar A K] This is just an implementation isuue. What will happen, if the two IAs are given the same IAID? Two IAs should not be given the same IAID. Basically, these two types of IAs are same in the term of content, but, behaviour of the IP addresses are different. Alternative is, we can seperate the address spaces for Temporary addresses. We can put the "T" bit in the IAID, and then what happens if the wrong option is used with an IAID in a Renew (or Release, ...). So, it gets messy and is probably not the best approach. [Vijay Bhaskar A K] For this case, the server has to return error as, Binding not available. Your point about graceful renumbering doesn't make sense ... IPv6 (and DHCPV6) already provide for this. I don't think we want addresses to between IA's so I think this concept is a bad one. Just like stateless addresses where lifetimes can be extended, so can they with DHCPv6 (that is either or both the preferred and valid). [Vijay Bhaskar A K] I agree that the DHCPv6 support graceful renumbering. But, once the subnet has got renumbered, the IA will contain the IP addresses of old and new subnet prefixes. Instead of putting those addresses belonging to two subnets, we can keep the deprecated one seperately. The handling of those deprecated become more easier. I agree that, this is merely an implemntation issue. I felt that putting together the valid and deprecated ones gives a messy look, since T1 and T2 of the IA hold only for the valid addresses and not for deprecated ones. ~vijay - Bernie -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Wednesday, July 18, 2001 6:17 PM To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses Hi, Find my comments inline. ~Vijay > -----Original Message----- > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > Behalf Of Ralph Droms > Sent: Wednesday, July 18, 2001 7:13 PM > To: DHCPv6 discussion list > Subject: Simplify release and decline of addresses > > > Ted suggests a simplification: requiring that all the > addresses in an IA be > released or declined, rather than just some of those > addresses. Ted also > wrote text describing the server behavior in response to a > Decline message > (which is missing from the -19 rev). > > - Ralph > > 14.4.5. Receipt of Release messages > > Upon the receipt of a valid Release message, the server > examines the > IAs and the addresses in the IAs for validity. If the IAs in the > message are in a binding for the client and the addresses > in the IAs > have been assigned by the server to those IA, the server deletes > the addresses from the IAs and makes the addresses available for > assignment to other clients. > > [IMHO, this is too complicated. I think the client should always > release all addresses in an IA - that is, it should just send an empty > IA as described below. Otherwise you get into complexities about how > to back out of an erroneous transaction that I think can't be solved.] Yes. I agree that, the release/decline of addresses as whole IA will simplify the more. So, here,the status field returned will be the same for all the addresses of the IA and it can be very well reflected in IA status. So, do we really need the "addr status" field? Whatever the error status defined can be returned in IA status itself. So, i feel that, we can remove the "addr status" field in IA. It can save many bytes, if the addresses in th IA are very large in number. Another suggestion is, because of handling Temporary address only, we have introduced the "T" bit in IA option. Why can't we define a new option for temporary address IA (TMP_IA). Using this TMP_IA, the client can ask for one or more temporary addresses. The main reason behind is, * The time values T1 and T2 are defined for specifying the time at which the client has to contact the server. But, for the temporary addresses, renewal and rebind is not possible. So, T1 and T2 are not necessary. So, we can remove these fields. * Normally, if the clients are requesting for the normal addresses, they will not be needing temporary addresses. The clients requesting for both will be rare. So, why do we need to put a bit in IA and giving more burden to IA option. So, the TMP_IA option looks like this. 0 1 2 3 ------=_NextPart_000_000F_01C11016.55C31DE0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable RE: Simplify release and decline of addresses
 
-----Original Message-----
From: = owner-dhcp-v6@bucknell.edu=20 [mailto:owner-dhcp-v6@bucknell.edu]On Behalf Of Bernie Volz=20 (EUD)
Sent: Thursday, July 19, 2001 4:27 AM
To: = DHCPv6=20 discussion list
Subject: RE: Simplify release and decline of = addresses

Vijay:

Removing "addr status" in the IA option without also = removing=20 the T bit
won't help save bytes since the T = bit will=20 require the byte anyway. We
might change = "addr status"=20 to "unused - MBZ" though if we're not using it.
[Vijay Bhaskar = A=20 K] What is the use of having "unused - MBZ". Is it = related=20 to allignment problem?

But, = do we need 4=20 octets for IAID? It will be hardly 4-5 IA's per client, in the = normal=20 case. But, if we reduce 1 byte in IAID, we can = escape from=20 alignment problem and another byte "addr status" is also freed. = (provided, we=20 are giving a seperate option for temporary address = IA)

Regarding a new option to handle Temporary = Addresses, I think=20 this has
merit simply because there has been = no way=20 for a client to communicate
what kind of = addresses it=20 wants. Having this option provides that mechanism.
Alternatives, such as allowing 'num-addrs' and thus some = address=20 information
(T bit) to be specified by the = client in a=20 Request were discussed at one
point but did = not make=20 it into the -19 draft and I'm not sure if it would be
in the -20.
[Vijay Bhaskar A = K] *********

Since, the=20 temporary addresses are to be handled in a different way, we need to=20 keep temporary addresses in a different IA option. This = simplifies=20 the IA option and make it easy to process temporary=20 addresses. 

Perhaps Ralph and Jim will care to provide some = indication of=20 how this will be
resolved in the -20 draft - = to give=20 the client some ability to communicate to
the server=20 what it needs. OR, perhaps the answer is simply "no, we're not=20
going to support it - it is up to the server to = figure it=20 out."

There are some issues with a new option - such as = the IAID=20 spaces must not
overlap,
[Vijay Bhaskar A=20 K] This is just an implementation isuue. What will = happen, if the=20 two IAs are given the same IAID? Two IAs should not be given the = same=20 IAID. Basically, these two types of IAs are same in the term of = content,=20 but, behaviour of the IP addresses are different.=20

Alternative is, we can seperate the address spaces for = Temporary=20 addresses. We can put the "T" bit in the IAID, =

 and = then what=20 happens if the wrong option is used with an IAID in
a=20 Renew (or Release, ...). So, it gets messy and is probably not the = best=20
approach.
[Vijay Bhaskar A K]  For this case, = the server=20 has to return error as, Binding not = available. 
Your point about graceful renumbering doesn't make sense ... = IPv6=20 (and
DHCPV6) already provide for this. I = don't think=20 we want addresses to between
IA's so I think = this=20 concept is a bad one. Just like stateless addresses where =
lifetimes can be extended, so can they with DHCPv6 (that is = either or=20 both
the preferred and valid). =
[Vijay Bhaskar = A K] I=20 agree that the DHCPv6 support graceful renumbering. But, once the = subnet has=20 got renumbered, the IA will contain the IP addresses of old and new = subnet=20 prefixes. Instead of putting those addresses belonging to = two=20 subnets, we can keep the deprecated one seperately. The = handling of those=20 deprecated become more easier. I agree that, this=20 is merely an implemntation issue. I felt that putting = together=20 the valid and deprecated ones gives a messy look, since T1 and = T2 of=20 the IA hold only for the valid addresses and not for deprecated=20 ones.

~vijay 

- Bernie

-----Original Message-----
From: Vijay=20 Bhaskar A K [mailto:vijayak@india.hp.com]=20
Sent: Wednesday, July 18, 2001 6:17 PM =
To: DHCPv6 discussion list
Subject: = RE:=20 Simplify release and decline of addresses


Hi,
Find my comments = inline.=20
~Vijay

> -----Original Message-----
>=20 From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.= edu]On=20
> Behalf Of Ralph Droms
> Sent:=20 Wednesday, July 18, 2001 7:13 PM
> To: = DHCPv6=20 discussion list
> Subject: Simplify = release and=20 decline of addresses
>
>=20
> Ted suggests a simplification: = requiring that all=20 the
> addresses in an IA be =
> released or declined, rather than just some of those=20
> addresses.  Ted also =
> wrote text describing the server behavior in response to = a=20
> Decline message
>=20 (which is missing from the -19 rev).
>=20
> - Ralph
>=20
> 14.4.5. Receipt of Release = messages=20
>
>    =20 Upon the receipt of a valid Release message, the server =
> examines the
>    =20 IAs and the addresses in the IAs for validity.  If the IAs in = the=20
>     message are in a = binding for the=20 client and the addresses
> in the = IAs=20
>     have been assigned by = the server=20 to those IA, the server deletes
>     the addresses from the IAs and = makes the=20 addresses available for
>    =20 assignment to other clients.
> =
> [IMHO, this is too complicated.  I think the client = should=20 always
> release all addresses in an IA - = that is,=20 it should just send an empty
> IA as = described=20 below.   Otherwise you get into complexities about = how=20
> to back out of an erroneous transaction that I = think=20 can't be solved.]

Yes.  I agree that, the  = release/decline =20 of  addresses as whole IA will
simplify = the=20 more.  So, here,the  status field returned will be the = same=20
for all the addresses of the IA and it can be very = well =20 reflected in IA
status.  So, do we = really need=20 the "addr  status"  field?  Whatever  the =
error  status  defined can be returned in IA = status =20 itself.  So, i feel
that, we can =20 remove  the "addr  status"  field in IA.  It can = save=20 many
bytes, if the addresses in th IA are = very large=20 in number.

Another  suggestion is, because of = handling =20 Temporary  address only, we
have =20 introduced  the "T" bit in IA  option.  Why  can't = we=20 define a new
option for temporary address IA = (TMP_IA).  Using this TMP_IA, the client
can ask=20 for one or more temporary addresses. 

The main reason behind is,

* The time values T1 and T2 are defined for = specifying the=20 time at which
the client has to contact the=20 server.  But, for the temporary addresses,
renewal  and rebind is not  possible.  So, T1 = and T2 are=20 not  necessary.
So, we can remove these = fields.

* Normally, if the clients are requesting for the = normal=20 addresses, they
will not be needing =20 temporary  addresses.  The clients  requesting  = for=20
both  will be  rare.  So,  why = do we need=20 to put a bit in IA and  giving
more = burden to IA=20 option.

So, the TMP_IA option looks like this.

  =20 = 0            =       =20 = 1            =       =20 = 2            =       =20 3

------=_NextPart_000_000F_01C11016.55C31DE0-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 21:14:57 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22429; Wed, 18 Jul 2001 21:14:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J1FJL25923; Wed, 18 Jul 2001 21:15:20 -0400 (EDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6J1FHL18644 for ; Wed, 18 Jul 2001 21:15:18 -0400 (EDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel1.hp.com (Postfix) with ESMTP id 294271A4A for ; Wed, 18 Jul 2001 18:15:15 -0700 (PDT) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id VAA16568 for dhcp-v6@bucknell.edu; Wed, 18 Jul 2001 21:18:24 -0400 (EDT) From: Vijay Bhaskar A K Message-Id: <200107190118.VAA16568@dce.india.hp.com> Subject: Question on Retransmission parameter option To: DHCPv6 discussion list Date: Wed, 18 Jul 2001 21:18:24 -0400 (EDT) X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, I have few comments abt Retransmission parameter option ~vijay 18.7. Retransmission parameter option 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_RETRANS_PARM | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option-data | | (option-len octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_RETRANS_PARM (5) option-len An unsigned integer giving the length of the data in this option in octets. option-data TBD - The details of the operational parameters to be set in the client I think option-data can be like parm-no (2 bytes) folllowed by parm-value (4 bytes). Thus, this looks like, 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_RETRANS_PARM | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | parm-no (2 octets) | parm-value (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | parm-no (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | parm-value (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ parm-no identifies the retransmission parameter number. The parm-value gives the value of this parameter. For this, we need to index the retransmission variables table. _________________________________________________________________________ No |Parameter__________|Default|_Description______________________________|_ 01 |MIN_SOL_DELAY______|1______|_MIN_(secs)_to_delay_1st_mesg_____________|_ 02 |MAX_SOL_DELAY______|5______|_MAX_(secs)_to_delay_1st_mesg_____________|_ 03 |ADV_MSG_TIMEOUT____|500____|_SOL_Retrans_timer_(msecs)________________|_ 04 |ADV_MSG_MAX________|30_____|_MAX_timer_value_(secs)___________________|_ 05 |SOL_MAX_ATTEMPTS___|-1_____|_MAX_attempts_(-1_=_infinite)_____________|_ 06 |REP_MSG_TIMEOUT____|250____|_Retrans_timer_(msecs)_for_Reply__________|_ 07 |QRY_MSG_ATTEMPTS___|10_____|_MAX_Request/Confirm/Renew/Rebind_attempts|_ 08 |REL_MSG_ATTEMPTS___|5______|_MAX_Release/Decline_attempts_____________|_ 09 |RECREP_MSG_TIMEOUT_|2000___|_Retrans_timer_(msecs)____________________|_ 10 |REC_MSG_ATTEMPTS___|10_____|_Reconfigure_attempts_____________________|_ 11 |REC_THRESHOLD______|100____|_%_of_required_clients____________________|_ 12 |SRVR_PREF_WAIT_____|2______|_Advertise_Collect_timer_(secs)___________|_ The specs from 13.3.1 says that, The Client includes a DUID option to identify itself to the server. The client MUST include options for any IAs to which the client is expecting to have the server assign addresses. Because the client does not have any IAs with addresses when sending a Solicit message, all of the IAs MUST be empty. The client MAY include an Option Request Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. I feel that, this specs should be changed. The Retransmission parameter option MAY occur in SOLICIT message. Assume, the client is not configured with some retransmission parameters like MAX-Reply-attempts, then, this has to be obatained from the server before sending request. * What will happen, if the client is not configured with default values related to SOLICIT/ADVERTISE message transaction like SOL-max-attempts, what it has to do? will it assumes the default value? -- ____Vijay_Bhaskar_A_K____ ______Inet_Services______ ________HP_ISO___________ ____Ph:_2251554_1424_____ ___Pager:_9624_371137____ From owner-dhcp-v6@bucknell.edu Wed Jul 18 21:48:40 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00242; Wed, 18 Jul 2001 21:48:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J1lZL03582; Wed, 18 Jul 2001 21:47:35 -0400 (EDT) Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6J1lML00823 for ; Wed, 18 Jul 2001 21:47:22 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel2.hp.com (Postfix) with ESMTP id 19E4D2EF for ; Wed, 18 Jul 2001 21:47:19 -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 HAA06924 for ; Thu, 19 Jul 2001 07:14:15 +0530 (IST) Reply-To: From: "Vijay Bhaskar A K" To: DHCPv6 discussion list Subject: RE: DHCPv6 -19 Draft Comments Date: Thu, 19 Jul 2001 07:17:08 +0530 Message-ID: <001501c10ff4$b8731070$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C11022.D22B4C70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <66F66129A77AD411B76200508B65AC697B3283@eambunt705.ena-east.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------=_NextPart_000_0016_01C11022.D22B4C70 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit DHCPv6 -19 Draft Comments -----Original Message----- From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On Behalf Of Bernie Volz (EUD) Sent: Monday, July 16, 2001 11:33 PM To: DHCPv6 discussion list Subject: DHCPv6 -19 Draft Comments Ralph, et al: In some further internal discussions and reviews, here are some other issues to address in the revision to the DHCPv6 -19 draft: 1. In Section 14.3.1 (Creation and sending of Request messages), there is no mention of using any of the "information" supplied by a server in the Advertise message (in response to a Solicit). In DHCPv4, the client sent information received in the Offer. We probably should be explicit about this and perhaps even suggest that the information received by a client in an Advertise is basically for information purposes only to help it determine whether this server will offer it what it needs. Perhaps the addresses assigned in the Advertise should even just be prefixes (interface portion all 0's)? [Vijay Bhaskar A K] ***** I think, sending the prefix instead of real addresses in the SOLICIT message is a nice idea. Becaues, for the IP address, we need some knob for the expiration of the "offered" addresses and at the same time, the client will be able to select the server who is giving address of its scope. It can find out that, whether the server is capable of giving the number of address it has asked. I feel that, we have to specifically say that, the server MUST send the IA option filled with prefixes, if it has that free pool of those many addresses. Otherwise, what will happen, if the server's preference value is 255 and it don't have the free pool of addresses to be assigned. If instead we want the server to assign "real" addresses, should something be said about how long those should be valid and whether the server should attempt to assign those same addresses to the client in a subsequent Request/Reply exchange for the IA? Perhaps we could punt and say this is a server implementation issue (whether it assigns real addresses and whether those are held for some (short) time for the client)? NOTE: If real addresses are returned, perhaps a client might even initiate DAD during the Request/Reply in which case it can do these two items in parallel (though this would be somewhat tricky since it would not want to Decline the addresses before receiving the Reply). Also, while checking the draft regarding this issue, I noticed: - Section 13.4.2 (Creation and sending of Advertise messages) does not even say anything about the ORO option that a client might have specified. Shouldn't we indicate that the Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option? - Section 14.3.1 (Creation and sending of Request messages) the first sentence says "If a client has no valid IPv6 addresses of sufficient scope to communicate with a DHCP server, ..." Huh? Even if it *DOES* have an address of sufficient scope, we don't want the client sending messages directly to the server. This must be some old text that should be dropped. 2. In Section 14.3.1, we should perhaps explicitly indicate that the client should add an ORO option (it now says "The client adds any appropriate options" ... but in many cases that just means an ORO option with appropriate options specified in that option. 3. During the WG / Design Team (I forget which, if not both) we did discuss designing a "quick" handshake for allowing a client to assign an address. I would assume we'd define a new option that the client could use to communicate to the server that it is doing this. Would we use Solicit/Advertise or Request/Reply for this (in many ways, Request/Reply seems like a better mechanism - the Request could simply leave the "server address" field as all 0's and that could even be the flag to the server). Perhaps we decided to defer this for now and do it later? 4. At another time we also discussed using the server to just advertise prefixes and allowing the client to generate the addresses? What about adding a "P" bit (next to the "T"-temporary bit) to indicate that this is a prefix from which the client should generate an address (or simply allowing it to do so if the link-identifier field is all 0's). Willl there be lease for these kind of addresses or these are same as the address formed by the stateful autoconf with infinite leases? Bernie Volz Chief Technical Officer - DNS & DHCP Development Unit Ericsson, Inc. Tel: +1-508-875-3162 Fax: +1-508-875-3018 Mobile: +1-617-513-9060 mailto:bernie.volz@ericsson.com ------=_NextPart_000_0016_01C11022.D22B4C70 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable DHCPv6 -19 Draft Comments
 
-----Original Message-----
From: = owner-dhcp-v6@bucknell.edu=20 [mailto:owner-dhcp-v6@bucknell.edu]On Behalf Of Bernie Volz=20 (EUD)
Sent: Monday, July 16, 2001 11:33 PM
To: = DHCPv6=20 discussion list
Subject: DHCPv6 -19 Draft=20 Comments

Ralph, et al:

In some further internal discussions = and reviews,=20 here are some other issues to address in the revision to the DHCPv6 = -19=20 draft:

1. In Section 14.3.1 (Creation and = sending of=20 Request messages), there is no mention of using any of the = "information"=20 supplied by a server in the Advertise message (in response to a = Solicit). In=20 DHCPv4, the client sent information received in the Offer. We probably = should=20 be explicit about this and perhaps even suggest that the information = received=20 by a client in an Advertise is basically for information purposes only = to help=20 it determine whether this server will offer it what it needs. Perhaps = the=20 addresses assigned in the Advertise should even just be prefixes = (interface=20 portion all 0's)?

[Vijay=20 Bhaskar A K] *****

I = think, sending=20 the prefix instead of real addresses in the SOLICIT message is a nice = idea.=20 Becaues, for the IP address, we need some knob for the expiration of = the=20 "offered" addresses and at the same time, the client will be able to = select=20 the server who is giving address of its scope. It can find out that, = whether=20 the server is capable of giving the number of address it has asked. I = feel=20 that, we have to specifically say that, the server MUST send the IA = option=20 filled with prefixes, if it has that free pool of those many = addresses.=20 Otherwise, what will happen, if the server's preference value is 255 = and it=20 don't have the free pool of addresses to be = assigned.

If instead we want the server to assign = "real"=20 addresses, should something be said about how long those should be = valid and=20 whether the server should attempt to assign those same addresses to = the client=20 in a subsequent Request/Reply exchange for the IA? Perhaps we could = punt and=20 say this is a server implementation issue (whether it assigns real = addresses=20 and whether those are held for some (short) time for the = client)?

NOTE: If real addresses are returned, = perhaps a=20 client might even initiate DAD during the Request/Reply in which case = it can=20 do these two items in parallel (though this would be somewhat tricky = since it=20 would not want to Decline the addresses before receiving the=20 Reply).

Also, while checking the draft = regarding this=20 issue, I noticed:
- Section = 13.4.2=20 (Creation and sending of Advertise messages) does not even say = anything about=20 the ORO option that a client might have specified. Shouldn't we = indicate that=20 the Advertise message SHOULD include options for all OROs that were = included=20 in the Solicit if the server is willing/capable of offering a value = for that=20 option?

- Section 14.3.1 (Creation and sending = of Request=20 messages) the first sentence says "If a client has no valid IPv6 = addresses of=20 sufficient scope to communicate with a DHCP server, ..." Huh? Even if = it=20 *DOES* have an address of sufficient scope, we don't want the client = sending=20 messages directly to the server. This must be some old text that = should be=20 dropped.

2. In Section 14.3.1, we should perhaps = explicitly=20 indicate that the client should add an ORO option (it now says "The = client=20 adds any appropriate options" ... but in many cases that just means an = ORO=20 option with appropriate options specified in that option.

3. During the WG / Design Team (I = forget which, if=20 not both) we did discuss designing a "quick" handshake for allowing a = client=20 to assign an address. I would assume we'd define a new option that the = client=20 could use to communicate to the server that it is doing this. Would we = use=20 Solicit/Advertise or Request/Reply for this (in many ways, = Request/Reply seems=20 like a better mechanism - the Request could simply leave the "server = address"=20 field as all 0's and that could even be the flag to the server). = Perhaps we=20 decided to defer this for now and do it later?

4. At another time we also discussed = using the=20 server to just advertise prefixes and allowing the client to generate = the=20 addresses? What about adding a "P" bit (next to the "T"-temporary bit) = to=20 indicate that this is a prefix from which the client should generate = an=20 address (or simply allowing it to do so if the link-identifier field = is all=20 0's).

Willl there be lease for these kind of = addresses or=20 these are same as the address formed by the stateful autoconf with = infinite=20 leases?

Bernie Volz
Chief=20 Technical Officer - DNS & DHCP Development Unit
Ericsson, Inc.
Tel:=20 +1-508-875-3162
Fax: = +1-508-875-3018=20
Mobile: +1-617-513-9060
mailto:bernie.volz@ericsson.com<= /A>=20


------=_NextPart_000_0016_01C11022.D22B4C70-- From owner-dhcp-v6@bucknell.edu Wed Jul 18 22:27:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07203; Wed, 18 Jul 2001 22:27:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J2RwL27281; Wed, 18 Jul 2001 22:27:58 -0400 (EDT) Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J2RlL21100 for ; Wed, 18 Jul 2001 22:27:47 -0400 (EDT) Received: from 157.54.9.101 by mail4.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 18 Jul 2001 19:27:30 -0700 (Pacific Daylight Time) Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jul 2001 19:26:50 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jul 2001 19:26:50 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 18 Jul 2001 19:25:44 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C10FFA.1C9176D6" Subject: RE: Circuit ID and Remote ID options Date: Wed, 18 Jul 2001 19:25:43 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10191E0DC@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Circuit ID and Remote ID options Thread-Index: AcEPmODJxRRK6UYYTSS4XZ188kh3egAYTbxA From: "Thirumalesh Bhat" To: DHCPv6 discussion list Cc: "Drew Baron" X-OriginalArrivalTime: 19 Jul 2001 02:25:44.0200 (UTC) FILETIME=[1CC50880:01C10FFA] Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------_=_NextPart_001_01C10FFA.1C9176D6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes - I think we should have a separate draft for options. We have a list of options that we need for DHCPv6. A preliminary list is as follows: =20 15 Domain Name NOT Present in DHCPv6 Draft 43 Vendor Specific NOT Present in DHCPv6 Draft 60 Class Identifier NOT Present in DHCPv6 Draft 77 User-Class NOT Present in DHCPv6 Draft 81 Client FQDN NOT Present in DHCPv6 Draft CSR Classless routes - option TBD =20 thx =20 -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]=20 Sent: Wednesday, July 18, 2001 7:49 AM To: DHCPv6 discussion list Subject: RE: Circuit ID and Remote ID options =20 I think this should be a separate specification. Easier to review/edit and=20 makes the DHCPv6 specification look less daunting. It also isn't a REQUIRED=20 part of the protocol.=20 Please note that giaddr is used in the text and should be changed to DHCPv6=20 terminology.=20 I'm also wondering whether it would be easier to just assign a DHCP Relay=20 Agent Information Option number (16-bit) and use the suboptions per RFC=20 3046. Though, as the giaddr reference points out, it may require some minor=20 text to explain how to adapt this RFC to IPv6.=20 - Bernie=20 -----Original Message-----=20 From: Ralph Droms [mailto:rdroms@cisco.com]=20 Sent: Wednesday, July 18, 2001 9:54 AM=20 To: DHCPv6 discussion list=20 Subject: Circuit ID and Remote ID options=20 =20 Ted has drafted text for the Circuit ID and Remote ID options, which are to=20 be used between relay agents and servers. Two questions: is the text OK and do we want to include the text in the base protocol spec?=20 I'm inclined not to include these two options in the base spec. Instead, I=20 suggest that they, along with other options we know we'll need real soon but are not referenced elsewhere in the base spec, be moved to separate=20 drafts for consideration in parallel with the base spec I-D.=20 - Ralph=20 18.13 Circuit ID Option=20 This option MAY be placed in Relay-forward messages by DHCP relay=20 agents which terminate switched or permanent circuits. It encodes=20 an agent-local identifier of the circuit on which a DHCP=20 client-to-server packet was received. It is intended for use by=20 relay agents in relaying DHCP responses back to the proper circuit.=20 Possible values encoded in this field include:=20 - Router interface number=20 - Switching Hub port number=20 - Remote Access Server port number=20 - Frame Relay DLCI=20 - ATM virtual circuit number=20 - Cable Data virtual circuit number=20 Servers MAY use the Circuit ID when making address allocation=20 decisions and in applying other parameter assignment policies. The=20 Circuit ID SHOULD be considered an opaque value, with policies=20 based on exact string match only; that is, the Circuit ID SHOULD=20 NOT be internally parsed by the server. Servers MUST return the=20 Circuit ID option in the Relay-reply message that is generated in=20 response to a Relay-forward message if this option appears in the=20 Relay-forward message.=20 Since the Circuit ID is local only to a particular relay agent, a=20 circuit ID should be qualified with the giaddr value that=20 identifies the relay agent.=20 0 1 2 3=20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | OPTION_CIRCUIT_ID | option_length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 . .=20 . circuit ID .=20 . .=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 =20 This corresponds to the DHCPv4 Circuit ID subpoption as described=20 in [24].=20 18.14 Remote ID Option=20 This option MAY be sent in Relay-forward messages by DHCP relay=20 agents which terminate switched or permanent circuits and have=20 mechanisms to identify the remote host end of the circuit. The=20 Remote ID field may be used to encode, for instance:=20 -- a "caller ID" telephone number for dial-up connection=20 -- a "user name" prompted for by a Remote Access Server=20 -- a remote caller ATM address=20 -- a "modem ID" of a cable data modem=20 -- the remote IP address of a point-to-point link=20 -- a remote X.25 address for X.25 connections=20 The remote ID MUST be globally unique.=20 DHCP servers MAY use this option to select parameters specific to=20 particular users, hosts, or subscriber modems. The option SHOULD=20 be considered an opaque value, with policies based on exact string=20 match only; that is, the option SHOULD NOT be internally parsed by=20 the server. Servers MUST return the Circuit ID option in the=20 Relay-reply message that is generated in response to a=20 Relay-forward message if this option appears in the Relay-forward=20 message.=20 The relay agent MAY use this field to select the circuit on which=20 to forward a DHCP reply message.=20 0 1 2 3=20 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=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 | OPTION_REMOTE_ID | option_length |=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 . .=20 . remote ID .=20 . .=20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20 This corresponds to the DHCPv4 Remote ID subpoption as described in=20 [24].=20 ------_=_NextPart_001_01C10FFA.1C9176D6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Circuit ID and Remote ID options

Yes – I think we should have = a separate draft for options. We have a list of options that we need for = DHCPv6. A preliminary list is as follows:

 

15 Domain = Name       NOT Present in DHCPv6 Draft

43 Vendor = Specific   NOT Present in DHCPv6 Draft

60 Class = Identifier  NOT Present in DHCPv6 Draft

77 = User-Class        NOT Present in DHCPv6 Draft

81 Client = FQDN       NOT Present in DHCPv6 Draft

CSR Classless routes – option = TBD

 

thx

 

-----Original = Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Wednesday, July 18, = 2001 7:49 AM
To: DHCPv6 discussion = list
Subject: RE: Circuit ID = and Remote ID options

 

I think this should be a separate = specification. Easier to review/edit and
makes the DHCPv6 = specification look less daunting. It also isn't a REQUIRED
part of the = protocol.

Please note that giaddr is used in the text = and should be changed to DHCPv6
terminology.

I'm also wondering whether it would be easier = to just assign a DHCP Relay
Agent Information Option = number (16-bit) and use the suboptions per RFC
3046. Though, as the = giaddr reference points out, it may require some minor
text to explain how to = adapt this RFC to IPv6.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, July = 18, 2001 9:54 AM
To: DHCPv6 discussion = list
Subject: Circuit ID and = Remote ID options

 

Ted has drafted text for the Circuit ID and = Remote ID options, which are to
be used between relay = agents and servers.  Two questions: is the text OK
and do we want to = include the text in the base protocol spec?

I'm inclined not to include these two options = in the base spec.  Instead, I
suggest that they, along = with other options we know we'll need real soon
but are not referenced = elsewhere in the base spec, be moved to separate
drafts for consideration = in parallel with the base spec I-D.

- Ralph

18.13 Circuit ID Option

    This option MAY be placed = in Relay-forward messages by DHCP relay
    = agents which terminate switched or permanent circuits.  It encodes =
    an = agent-local identifier of the circuit on which a DHCP
    = client-to-server packet was received.  It is intended for use by
    relay = agents in relaying DHCP responses back to the proper circuit.
    = Possible values encoded in this field include:

        - = Router interface number
        - Switching Hub port number
        - Remote Access Server port number
        - Frame Relay DLCI
        - ATM virtual circuit number
        - Cable Data virtual circuit number

    Servers MAY use the = Circuit ID when making address allocation
    = decisions and in applying other parameter assignment policies.  The =
    = Circuit ID SHOULD be considered an opaque value, with policies
    based = on exact string match only; that is, the Circuit ID SHOULD
    NOT = be internally parsed by the server.   Servers MUST return = the
    = Circuit ID option in the Relay-reply message that is generated in =
    = response to a Relay-forward message if this option appears in the
    = Relay-forward message.

    Since the Circuit ID is = local only to a particular relay agent, a
    = circuit ID should be qualified with the giaddr value that
    = identifies the relay agent.

     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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>
    |      OPTION_CIRCUIT_ID        |         option_length         = |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>
    .            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  .
    .            =             &= nbsp; circuit ID            = ;            =    .
    .            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  .
    = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

 

    This corresponds to the = DHCPv4 Circuit ID subpoption as described
    in = [24].

18.14 Remote ID Option

    This option MAY be sent in Relay-forward messages by DHCP relay
    = agents which terminate switched or permanent circuits and have
    = mechanisms to identify the remote host end of the circuit.  The =
    = Remote ID field may be used to encode, for instance:

        -- = a "caller ID" telephone number for dial-up = connection
        -- a "user name" prompted for by a Remote Access = Server
        -- a remote caller ATM address
        -- a "modem ID" of a cable data modem
        -- the remote IP address of a point-to-point link
        -- a remote X.25 address for X.25 connections

    The remote ID MUST be = globally unique.

    DHCP servers MAY use this = option to select parameters specific to
    = particular users, hosts, or subscriber modems.  The option = SHOULD
    be = considered an opaque value, with policies based on exact string
    match = only; that is, the option SHOULD NOT be internally parsed by
    the server.  Servers MUST return the Circuit ID option in = the
    = Relay-reply message that is generated in response to a
    = Relay-forward message if this option appears in the Relay-forward
    = message.

    The relay agent MAY use = this field to select the circuit on which
    to = forward a DHCP reply 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
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>
    |       OPTION_REMOTE_ID        |         option_length         = |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>
    .            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  .
    .            =             &= nbsp;  remote = ID            = ;            =    .
    .            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  .
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<= /font>

    This corresponds to the = DHCPv4 Remote ID subpoption as described in
    = [24].

=00 ------_=_NextPart_001_01C10FFA.1C9176D6-- From owner-dhcp-v4@bucknell.edu Wed Jul 18 23:20:39 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18593 for ; Wed, 18 Jul 2001 23:20:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J3IRL13195; Wed, 18 Jul 2001 23:18:27 -0400 (EDT) Received: from web14803.mail.yahoo.com (web14803.mail.yahoo.com [216.136.224.219]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J3IFL01835 for ; Wed, 18 Jul 2001 23:18:15 -0400 (EDT) Message-ID: <20010719031741.56898.qmail@web14803.mail.yahoo.com> Received: from [200.231.27.1] by web14803.mail.yahoo.com via HTTP; Wed, 18 Jul 2001 20:17:41 PDT Date: Wed, 18 Jul 2001 20:17:41 -0700 (PDT) From: Nikolay Popov Subject: Need multi-thread DHCP client/server/relay To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: nvpopov@yahoo.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello, I need to write a multi-thread DHCP client/server/relay for VxWorks. And I don't want to use VxWorks DHCP library. Is there any avliable C/C++ sources ? Thank you. __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail http://personal.mail.yahoo.com/ From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:32:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05064; Thu, 19 Jul 2001 00:32:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4WcL11936; Thu, 19 Jul 2001 00:32:38 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4WVL31375 for ; Thu, 19 Jul 2001 00:32:32 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26705; Thu, 19 Jul 2001 00:32:31 -0400 Date: Thu, 19 Jul 2001 00:32:31 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: Circuit ID and Remote ID options In-Reply-To: <200107182049.f6IKnew00580@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Just to note I like the circuit and route id stuff. I think it will be used immediately by implementors. I don't see harm here? Unless its controversial and will hold us up or we need gobs of text and such. But I am not hearing folks against it? /jim On Wed, 18 Jul 2001, Ted Lemon wrote: > > > I think this should be a separate specification. Easier to review/edit and > > makes the DHCPv6 specification look less daunting. It also isn't a REQUIRED > > part of the protocol. > > I was under the impression that we were trying to specify options that > we know are needed in the main draft. If that is not the case, then > it's fine with me if we put them in a seperate draft. > > > Please note that giaddr is used in the text and should be changed to DHCPv6 > > terminology. > > Oops! > > > I'm also wondering whether it would be easier to just assign a DHCP Relay > > Agent Information Option number (16-bit) and use the suboptions per RFC > > 3046. Though, as the giaddr reference points out, it may require some minor > > text to explain how to adapt this RFC to IPv6. > > This wouldn't make a whole lot of sense, frankly - the relay mechanism > in DHCPv6 is completely different. There is no need for a suboption > encapsulation - the relay agent is already encapsulating the client's > packet, so the whole kludge we had to do for DHCPv4 is unnecessary. > RFC3046 mostly describes the kludge, which we don't want people to > even think about in DHCPv6. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:33:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05167; Thu, 19 Jul 2001 00:32:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4XVL06613; Thu, 19 Jul 2001 00:33:31 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4XTL06714 for ; Thu, 19 Jul 2001 00:33:29 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA22492; Thu, 19 Jul 2001 00:33:28 -0400 Date: Thu, 19 Jul 2001 00:33:28 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <200107182051.f6IKpXw00593@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN if the server checks the prefix of the renew it can know? /jim On Wed, 18 Jul 2001, Ted Lemon wrote: > > > [Should we include Renew in the message list and add to 14.4.3?] > > The renew message can be unicast (IIRC) so the server can't make a > determination as to the validity of the prefix. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:36:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA05784; Thu, 19 Jul 2001 00:36:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4ahL16368; Thu, 19 Jul 2001 00:36:43 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4adL31836 for ; Thu, 19 Jul 2001 00:36:39 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA15086; Thu, 19 Jul 2001 00:36:38 -0400 Date: Thu, 19 Jul 2001 00:36:38 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Rules for message transmission and retransmission In-Reply-To: <66F66129A77AD411B76200508B65AC697B32C9@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hmmmm I would never advise a user to do reconfigure-init thru relay. I believe all reconfigure-inits MUST come from servers? /jim On Wed, 18 Jul 2001, Bernie Volz (EUD) wrote: > Regarding the transmission rules, I wasn't attempting to change them. Sorry > for my error - I missed the case where the Reconfigure-Init is sent via the > Relay. It should be added. If that revised text is desired, let me know. > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Wednesday, July 18, 2001 4:43 PM > To: DHCPv6 discussion list > Subject: Re: Rules for message transmission and retransmission > > > > > One statement that we might want to modify slightly is "In any case, timeout > > processing MUST be accurate to at least 500 milliseconds." As few operating > > systems are truely real-time (this is probably more of a semantics issue), > > it may not be possible to honor this requirement. I know what you want, but > > am not sure how to say it better so perhaps it is a non-issue. > > Oops, I hadn't intended to place a real-time requirement on the > client. What I intended here is just that the client application > should store timeouts with at least 500ms granularity, so as to honor > some of the defaults defined in section 7. > > > The client MAY transmit messages to a server directly if it has an address > > of sufficient scope to communicate with the server and the server has > > previously communicated to the client that it is allowed to do so via > > the Server unicast option (Section 18.10). Otherwise, the client MUST > > transmit all of its messages to the All DHCP Agents multicast address. > > Actually, we can't do this - certain client messages MUST be > transmitted through the relay, and there is already language in the > draft stating this requirement (IIRC!). > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:41:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06424; Thu, 19 Jul 2001 00:41:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4fvL08818; Thu, 19 Jul 2001 00:41:57 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4ffL16114 for ; Thu, 19 Jul 2001 00:41:42 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27249; Thu, 19 Jul 2001 00:41:40 -0400 Date: Thu, 19 Jul 2001 00:41:40 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses In-Reply-To: <66F66129A77AD411B76200508B65AC697B32CC@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The client does not request addresses per se in dhcpv6 now directly. It asks for them. So the server has control over the T bit via policy. /jim On Wed, 18 Jul 2001, Bernie Volz (EUD) wrote: > Vijay: > > Removing "addr status" in the IA option without also removing the T bit > won't help save bytes since the T bit will require the byte anyway. We > might change "addr status" to "unused - MBZ" though if we're not using it. > > Regarding a new option to handle Temporary Addresses, I think this has > merit simply because there has been no way for a client to communicate > what kind of addresses it wants. Having this option provides that mechanism. > Alternatives, such as allowing 'num-addrs' and thus some address information > (T bit) to be specified by the client in a Request were discussed at one > point but did not make it into the -19 draft and I'm not sure if it would be > in the -20. > > Perhaps Ralph and Jim will care to provide some indication of how this will be > resolved in the -20 draft - to give the client some ability to communicate to > the server what it needs. OR, perhaps the answer is simply "no, we're not > going to support it - it is up to the server to figure it out." > > There are some issues with a new option - such as the IAID spaces must not > overlap, and then what happens if the wrong option is used with an IAID in > a Renew (or Release, ...). So, it gets messy and is probably not the best > approach. > > Your point about graceful renumbering doesn't make sense ... IPv6 (and > DHCPV6) already provide for this. I don't think we want addresses to between > IA's so I think this concept is a bad one. Just like stateless addresses where > lifetimes can be extended, so can they with DHCPv6 (that is either or both > the preferred and valid). > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Wednesday, July 18, 2001 6:17 PM > To: DHCPv6 discussion list > Subject: RE: Simplify release and decline of addresses > > > Hi, > Find my comments inline. > ~Vijay > > > -----Original Message----- > > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > > Behalf Of Ralph Droms > > Sent: Wednesday, July 18, 2001 7:13 PM > > To: DHCPv6 discussion list > > Subject: Simplify release and decline of addresses > > > > > > Ted suggests a simplification: requiring that all the > > addresses in an IA be > > released or declined, rather than just some of those > > addresses. Ted also > > wrote text describing the server behavior in response to a > > Decline message > > (which is missing from the -19 rev). > > > > - Ralph > > > > 14.4.5. Receipt of Release messages > > > > Upon the receipt of a valid Release message, the server > > examines the > > IAs and the addresses in the IAs for validity. If the IAs in the > > message are in a binding for the client and the addresses > > in the IAs > > have been assigned by the server to those IA, the server deletes > > the addresses from the IAs and makes the addresses available for > > assignment to other clients. > > > > [IMHO, this is too complicated. I think the client should always > > release all addresses in an IA - that is, it should just send an empty > > IA as described below. Otherwise you get into complexities about how > > to back out of an erroneous transaction that I think can't be solved.] > > Yes. I agree that, the release/decline of addresses as whole IA will > simplify the more. So, here,the status field returned will be the same > for all the addresses of the IA and it can be very well reflected in IA > status. So, do we really need the "addr status" field? Whatever the > error status defined can be returned in IA status itself. So, i feel > that, we can remove the "addr status" field in IA. It can save many > bytes, if the addresses in th IA are very large in number. > > Another suggestion is, because of handling Temporary address only, we > have introduced the "T" bit in IA option. Why can't we define a new > option for temporary address IA (TMP_IA). Using this TMP_IA, the client > can ask for one or more temporary addresses. > > The main reason behind is, > > * The time values T1 and T2 are defined for specifying the time at which > the client has to contact the server. But, for the temporary addresses, > renewal and rebind is not possible. So, T1 and T2 are not necessary. > So, we can remove these fields. > > * Normally, if the clients are requesting for the normal addresses, they > will not be needing temporary addresses. The clients requesting for > both will be rare. So, why do we need to put a bit in IA and giving > more burden to IA option. > > So, the TMP_IA option looks like this. > > 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 TMP_IA | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IAID (4 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IA status | num-addrs | prefix length | IPv6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | | > | addresses | > | (16 octets) +-+-+-+-+-+-+ > | | preferred | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | lifetime | valid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | lifetime |IPv6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | | > | addresses | > | (16 octets) +-+-+-+-+-+-+ > | | preferred | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | lifetime | valid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I'm not sure whether there will be an allignment problem. But, we can > reduce unnecessary bytes using this option. > > * One more point to be noted is, a fair implementation of DHCPv6 should > support "graceful renumbering". It should provide some grace period to > the old prefixes. The deprecated IPv6 addresses (addresses of old > prefixes) almost look like the temporary address with preferred life > time as 0 and valid life time as 1-2 days. This option will be more > useful for handling those deprecated addresses, since those addresses > are not supposed to be renewed/rebinded. > > > > > 14.4.5-1/2. Receipt of Decline messages (To be inserted after existing > > section 14.4.5 in -19 rev) > > > > Upon the receipt of a valid Decline message, the server > > examines the > > IAs and the addresses in the IAs for validity. If any IA in the > > message is not an IA that has been assigned by the server to that > > client, or if any addresses are mentioned in an IA that were not > > assigned by the server to the client, the server MUST NOT further > > process the message, but should send a Reply message indicating a > > NoBinding status. > > > > For each IA in the message, if there are any addresses > > mentioned in > > that IA, the server SHOULD mark each of these addresses as in > > conflict and SHOULD NOT make these addresses available for > > allocation to other clients. Any addresses that the server has > > allocated to that IA but that are not mentioned in the message > > SHOULD be made available for assignment to other clients. > > > > [As above, I would argue that the client should simply send empty IAs, > > and let all the addresses be declined. This has the disadvantage > > that you can lose addresses that were not in conflict, but it makes > > the whole transaction a lot simpler, and I think simplicity is a real > > virtue in this case.] > > > > If an IA is mentioned in the Decline message without any > > accompanying addresses, the server SHOULD mark all the > > addresses in > > the IA as being in conflict, and SHOULD NOT make these addresses > > available for immediate assignment to other clients. > > > > Server implementors SHOULD implement a strategy for reclaiming > > these IP addresses if there are no addresses available for > > allocation. Server implementors MAY also implement a strategy to > > detect a client that is repeatedly allocating and then declining > > addresses. When such a client is detected, the server SHOULD > > refuse to allocate further addresses to that client for > > DECLINE_COOLOFF (see section 7.5) seconds. > > > > The server then generates a Reply message. If all of the IAs were > > valid, the server sets the "status" field to "Success". If any of > > the IAs were invalid, the server sets the "status" field to > > "NoBinding" (section 7.4). > > > > -- > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > ____Ph:_2251554_1424_____ > ___Pager:_9624_371137____ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:45:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06860; Thu, 19 Jul 2001 00:45:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4jfL11975; Thu, 19 Jul 2001 00:45:41 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4jeL04143 for ; Thu, 19 Jul 2001 00:45:40 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26156; Thu, 19 Jul 2001 00:45:39 -0400 Date: Thu, 19 Jul 2001 00:45:39 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <66F66129A77AD411B76200508B65AC697B32CD@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In the case of unicast the server first of all knows immediately it was not sent thru the relay by the options. it then know it was unicast. yes the server must keep the ipv6 src address of the client for the prefix check. if the client got to the server the server can get to the client. /jim On Wed, 18 Jul 2001, Bernie Volz (EUD) wrote: > OK. I understand your point. > > BTW, I was originally thinking that only the Reply to a Confirm message > would do this prefix checking and hence return a NoPrefixMatch status. > > But, even that would not have been safe. Note that text for the "Server > Unicast Option": > > "This option is used by a server to send to a client to inform the > client it can send a Request, Renew, Confirm, Release, and Decline > by unicasting directly to the server instead of the All DHCPv6 Agents > multicast adress as an optimization." > > I think we need to change this OR we need to add a statement to the prefix > checking that prohibits it if the server can't tell where the client is. > > Now, this raises the nasty issue of if the client unicasts a message, how > does the server reply to it (I already raised this issue). One solution is > to use the IPv6 Source Address - but that has problems since then why not > always use it? Another is for the server to save information on how to reach > the client (which it might need to do anyway to send it Reconfigure-Inits?) > via a Relay (or directly if on-link). But this is messy and what if the > client has moved (I guess you could argue then it might not need to be > Reconfigured)? > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Wednesday, July 18, 2001 6:51 PM > To: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > > IIRC = If I Recall Correctly > > > What difference does that make? A Release or Decline can be unicast as well > > (if the client has another address - in a different IA - than what it is > > releasing and the server has told the client it can unicast). > > The server doesn't need to make a determination as to what link the > client is on in the case of Release. Decline probably does need to > go through the relay. > > > Why does *HOW* the packet was sent make any difference? Remember, we're > > dealing with MANY addresses so an individual message's IAs have nothing to > > do with other IAs (and hence addresses) that client has. > > If the packet goes through a relay, the relay can say on which link > the packet was received. If it is unicast through a router, that is > not the case. In the case where it is unicast through a router, > therefore, it doesn't make sense to check the prefix - we can only > assume that it is correct. In the case where it is not correct, the > packet probably wouldn't have gotten to us, and even if it did somehow > get to us, we couldn't reply, because our reply will go to the link > where the prefix *is* valid. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:47:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07162; Thu, 19 Jul 2001 00:47:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4mML01375; Thu, 19 Jul 2001 00:48:22 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4m7L06889 for ; Thu, 19 Jul 2001 00:48:07 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA24933; Thu, 19 Jul 2001 00:48:07 -0400 Date: Thu, 19 Jul 2001 00:48:07 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <200107182308.f6IN8Zw00843@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I think this is an option we can do later. But I think we are asking to much of the relay. The entire design goal has always been to keep the relay as stateless as possible. If the relay knows which prefixes are good for a client and has to parse the addresses in a client packet I think I am against that as one who has worked on building a router this is a bit intense. In fact now that I think about it I think this is simply not a good idea. /jim On Wed, 18 Jul 2001, Ted Lemon wrote: > > > The format of "Error Code" option is not specified in the draft. It is > > needed to be included. > > I think it goes into the IA option, but you're right - it needs to be > clarified. > > > It will be better, if this functionality can be incorporated in the > > agent,since, it is the only thing which knows well about the prefix in which > > the client message is received. And the advantage is, if this checking is > > done, this packet can be prevented from forwarding it to the multiple > > servers and save multiple processing time. The agent itself can send the > > NoPrefixMatch status directly to the client. > > Ooh, good point! I think it would be good if the agent could do > this, although I have to admit that I am concerned that some people > who implement relay agents may not want to have to delve into the IA > to validate a packet. I'm in favor of doing as you suggest, but I > suggest that we defer to the working group to see if any router > vendors have a problem with this. > > Also, the timing is a bit tight on making this change, and I wouldn't > blame the authors if they said "no, sorry, do this in a new draft." I > think it's okay to make this optional, so doing it in a seperate draft > should be fine. > > > If the client is receiving the error status as NoPrefixMatch error, what > > may be the reason other than client's plugging in to different subnet. I > > agree that, some roghe server can send this status, but, it can be prevented > > by authentication. > > The client may be mobile, and may be able to reach more than one > mobile access point. The two access points may want to think of > themselves as seperate links, even though their physical link-layers > overlap. I don't know how likely this is with existing technology, > but it's certainly been discussed with respect to 3G phones. I think > it's important to leave the language open for this case. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:49:43 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07393; Thu, 19 Jul 2001 00:49:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4oGL05778; Thu, 19 Jul 2001 00:50:16 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4o4L03461 for ; Thu, 19 Jul 2001 00:50:04 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA25475; Thu, 19 Jul 2001 00:50:03 -0400 Date: Thu, 19 Jul 2001 00:50:03 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <66F66129A77AD411B76200508B65AC697B32CE@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN but since the discussion brought up by ted. I would now check the prefix for all clients on any msg-type. I think we have defined something that will need to be inherent in dhcpv6 implementations now. whether forwarded by relay or direct unicast from the client. I also think its a good idea esp for mobile nodes. /jim On Wed, 18 Jul 2001, Bernie Volz (EUD) wrote: > One more comment ... in some cases (agreed not all) a server *CAN* determine > that a prefix is invalid in its domain regardless of where the client actually > is. > > For example, if a server receives a Confirm for a global prefix it has no > knowledge of, why does it care where it came from? If it can send a Reply > back to the client, it can tell it - hey, you're using invalid prefixes. > > If relays are configured incorrectly and forwarding packets to where they > shouldn't be going, that's not the servers fault. > > Again, the entire point of the NoPrefixMatch is to tell the client quickly > that it may have moved. So, one bad prefix in a list of addresses (regardless > of whether that server even has any knowledge of that client or that IA) is > sufficient to communicate that to the client quickly and effectively. > > Just returning NoBinding or another error doesn't help the client at all. > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Wednesday, July 18, 2001 6:51 PM > To: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > > IIRC = If I Recall Correctly > > > What difference does that make? A Release or Decline can be unicast as well > > (if the client has another address - in a different IA - than what it is > > releasing and the server has told the client it can unicast). > > The server doesn't need to make a determination as to what link the > client is on in the case of Release. Decline probably does need to > go through the relay. > > > Why does *HOW* the packet was sent make any difference? Remember, we're > > dealing with MANY addresses so an individual message's IAs have nothing to > > do with other IAs (and hence addresses) that client has. > > If the packet goes through a relay, the relay can say on which link > the packet was received. If it is unicast through a router, that is > not the case. In the case where it is unicast through a router, > therefore, it doesn't make sense to check the prefix - we can only > assume that it is correct. In the case where it is not correct, the > packet probably wouldn't have gotten to us, and even if it did somehow > get to us, we couldn't reply, because our reply will go to the link > where the prefix *is* valid. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:53:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA07858; Thu, 19 Jul 2001 00:53:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4s9L26897; Thu, 19 Jul 2001 00:54:10 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4s3L30147 for ; Thu, 19 Jul 2001 00:54:03 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27086; Thu, 19 Jul 2001 00:54:02 -0400 Date: Thu, 19 Jul 2001 00:54:02 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <66F66129A77AD411B76200508B65AC697B32CF@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN reading mail sequentially to catch up (did something besides ipv6 for an evening I feel guilty though) and that is where I was going. I would say stateless instead of dumb though :----) /jim On Wed, 18 Jul 2001, Bernie Volz (EUD) wrote: > While moving this functionality to the Relays is certainly very interesting: > - Servers will need to do it anyway (what if no relays) > - Servers have more complete network knowledge. While a router may be a relay, > a relay does not have to be a router. Sure, the relay could look at the Router > Advertisements (or the hosts routing table) to see what prefixes are currently > valid. > - I think most vendors would rather have relays be relatively dumb? > > And, (IIRC) I don't believe there is anything in the spec prohibiting it at > this point? > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Wednesday, July 18, 2001 7:09 PM > To: DHCPv6 discussion list > Cc: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > > > The format of "Error Code" option is not specified in the draft. It is > > needed to be included. > > I think it goes into the IA option, but you're right - it needs to be > clarified. > > > It will be better, if this functionality can be incorporated in the > > agent,since, it is the only thing which knows well about the prefix in which > > the client message is received. And the advantage is, if this checking is > > done, this packet can be prevented from forwarding it to the multiple > > servers and save multiple processing time. The agent itself can send the > > NoPrefixMatch status directly to the client. > > Ooh, good point! I think it would be good if the agent could do > this, although I have to admit that I am concerned that some people > who implement relay agents may not want to have to delve into the IA > to validate a packet. I'm in favor of doing as you suggest, but I > suggest that we defer to the working group to see if any router > vendors have a problem with this. > > Also, the timing is a bit tight on making this change, and I wouldn't > blame the authors if they said "no, sorry, do this in a new draft." I > think it's okay to make this optional, so doing it in a seperate draft > should be fine. > > > If the client is receiving the error status as NoPrefixMatch error, what > > may be the reason other than client's plugging in to different subnet. I > > agree that, some roghe server can send this status, but, it can be prevented > > by authentication. > > The client may be mobile, and may be able to reach more than one > mobile access point. The two access points may want to think of > themselves as seperate links, even though their physical link-layers > overlap. I don't know how likely this is with existing technology, > but it's certainly been discussed with respect to 3G phones. I think > it's important to leave the language open for this case. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:56:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08142; Thu, 19 Jul 2001 00:56:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4uYL26470; Thu, 19 Jul 2001 00:56:34 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4uSL12494 for ; Thu, 19 Jul 2001 00:56:28 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26855; Thu, 19 Jul 2001 00:56:28 -0400 Date: Thu, 19 Jul 2001 00:56:27 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <200107182323.f6INNvw00886@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN that is why we say that a client must have sufficient scope often in the spec and also in some cases state the client should use a global address. A client that tries sending site to global scope will get bounced by the router in ipv6 too it won't be allowed to get to the server fyi. This is the ipv6 scoping rules for routing. /jim On Wed, 18 Jul 2001, Ted Lemon wrote: > > > For example, if a server receives a Confirm for a global prefix it has no > > knowledge of, why does it care where it came from? If it can send a Reply > > back to the client, it can tell it - hey, you're using invalid prefixes. > > Sure. But it can't get such a unicast message unless the client > already has an address with a valid prefix (by valid, I mean that the > server can successfully send a packet to the client, not just that a > site-local prefix looks valid by coincidence). So this case isn't one > that we need to deal with, as far as I can see. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:57:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08365; Thu, 19 Jul 2001 00:57:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4wFL03748; Thu, 19 Jul 2001 00:58:15 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4w3L29810 for ; Thu, 19 Jul 2001 00:58:03 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27178; Thu, 19 Jul 2001 00:58:02 -0400 Date: Thu, 19 Jul 2001 00:58:02 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <66F66129A77AD411B76200508B65AC697B32D2@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN in the case of a relay this will work yes. but not for unicast. in that case the server will get the packet and be e2e with the relay not the client. all should work that way and our new prefix error code if it applies. /jim On Wed, 18 Jul 2001, Bernie Volz (EUD) wrote: > Why? > > The Confirm is multicast by the client, picked up a relay and sent to a server. > > The server can return the Reply the same way. > > Or, what about the case where the client and server are on the same link? > > In both these cases all the client needs is a valid link local address. Nothing > else to communicate between client/server. > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Wednesday, July 18, 2001 7:24 PM > To: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > > > For example, if a server receives a Confirm for a global prefix it has no > > knowledge of, why does it care where it came from? If it can send a Reply > > back to the client, it can tell it - hey, you're using invalid prefixes. > > Sure. But it can't get such a unicast message unless the client > already has an address with a valid prefix (by valid, I mean that the > server can successfully send a packet to the client, not just that a > site-local prefix looks valid by coincidence). So this case isn't one > that we need to deal with, as far as I can see. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 00:58:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA08475; Thu, 19 Jul 2001 00:58:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4x9L18311; Thu, 19 Jul 2001 00:59:09 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J4wwL01136 for ; Thu, 19 Jul 2001 00:58:58 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26979; Thu, 19 Jul 2001 00:58:57 -0400 Date: Thu, 19 Jul 2001 00:58:57 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <200107182335.f6INZtw00944@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN yep I agree? are we all in violent agreement !!!!! /jim On Wed, 18 Jul 2001, Ted Lemon wrote: > > > The Confirm is multicast by the client, picked up a relay and sent > > to a server. > > Right, and that's why the language you wrote applies to the Confirm > message! > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 01:07:39 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10346; Thu, 19 Jul 2001 01:07:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J581L10093; Thu, 19 Jul 2001 01:08:01 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J57hL03713 for ; Thu, 19 Jul 2001 01:07:44 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AB27184; Thu, 19 Jul 2001 01:07:43 -0400 Date: Thu, 19 Jul 2001 01:07:43 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Cc: Drew Baron Subject: RE: Circuit ID and Remote ID options In-Reply-To: <2E33960095B58E40A4D3345AB9F65EC10191E0DC@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN this is good list. the ones we have now must be there too. /jim On Wed, 18 Jul 2001, Thirumalesh Bhat wrote: > Yes - I think we should have a separate draft for options. We have a > list of options that we need for DHCPv6. A preliminary list is as > follows: > > > > 15 Domain Name NOT Present in DHCPv6 Draft > > 43 Vendor Specific NOT Present in DHCPv6 Draft > > 60 Class Identifier NOT Present in DHCPv6 Draft > > 77 User-Class NOT Present in DHCPv6 Draft > > 81 Client FQDN NOT Present in DHCPv6 Draft > > CSR Classless routes - option TBD > > > > thx > > > > -----Original Message----- > From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > Sent: Wednesday, July 18, 2001 7:49 AM > To: DHCPv6 discussion list > Subject: RE: Circuit ID and Remote ID options > > > > I think this should be a separate specification. Easier to review/edit > and > makes the DHCPv6 specification look less daunting. It also isn't a > REQUIRED > part of the protocol. > > Please note that giaddr is used in the text and should be changed to > DHCPv6 > terminology. > > I'm also wondering whether it would be easier to just assign a DHCP > Relay > Agent Information Option number (16-bit) and use the suboptions per RFC > 3046. Though, as the giaddr reference points out, it may require some > minor > text to explain how to adapt this RFC to IPv6. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Wednesday, July 18, 2001 9:54 AM > To: DHCPv6 discussion list > Subject: Circuit ID and Remote ID options > > > > Ted has drafted text for the Circuit ID and Remote ID options, which are > to > be used between relay agents and servers. Two questions: is the text OK > > and do we want to include the text in the base protocol spec? > > I'm inclined not to include these two options in the base spec. > Instead, I > suggest that they, along with other options we know we'll need real soon > > but are not referenced elsewhere in the base spec, be moved to separate > drafts for consideration in parallel with the base spec I-D. > > - Ralph > > 18.13 Circuit ID Option > > This option MAY be placed in Relay-forward messages by DHCP relay > agents which terminate switched or permanent circuits. It encodes > an agent-local identifier of the circuit on which a DHCP > client-to-server packet was received. It is intended for use by > relay agents in relaying DHCP responses back to the proper circuit. > Possible values encoded in this field include: > > - Router interface number > - Switching Hub port number > - Remote Access Server port number > - Frame Relay DLCI > - ATM virtual circuit number > - Cable Data virtual circuit number > > Servers MAY use the Circuit ID when making address allocation > decisions and in applying other parameter assignment policies. The > Circuit ID SHOULD be considered an opaque value, with policies > based on exact string match only; that is, the Circuit ID SHOULD > NOT be internally parsed by the server. Servers MUST return the > Circuit ID option in the Relay-reply message that is generated in > response to a Relay-forward message if this option appears in the > Relay-forward message. > > Since the Circuit ID is local only to a particular relay agent, a > circuit ID should be qualified with the giaddr value that > identifies the relay agent. > > 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_CIRCUIT_ID | option_length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . circuit ID . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > This corresponds to the DHCPv4 Circuit ID subpoption as described > in [24]. > > 18.14 Remote ID Option > > This option MAY be sent in Relay-forward messages by DHCP relay > agents which terminate switched or permanent circuits and have > mechanisms to identify the remote host end of the circuit. The > Remote ID field may be used to encode, for instance: > > -- a "caller ID" telephone number for dial-up connection > -- a "user name" prompted for by a Remote Access Server > -- a remote caller ATM address > -- a "modem ID" of a cable data modem > -- the remote IP address of a point-to-point link > -- a remote X.25 address for X.25 connections > > The remote ID MUST be globally unique. > > DHCP servers MAY use this option to select parameters specific to > particular users, hosts, or subscriber modems. The option SHOULD > be considered an opaque value, with policies based on exact string > match only; that is, the option SHOULD NOT be internally parsed by > the server. Servers MUST return the Circuit ID option in the > Relay-reply message that is generated in response to a > Relay-forward message if this option appears in the Relay-forward > message. > > The relay agent MAY use this field to select the circuit on which > to forward a DHCP reply 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_REMOTE_ID | option_length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . remote ID . > . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > This corresponds to the DHCPv4 Remote ID subpoption as described in > [24]. > > From owner-dhcp-v6@bucknell.edu Thu Jul 19 01:07:40 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA10365; Thu, 19 Jul 2001 01:07:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J58CL05687; Thu, 19 Jul 2001 01:08:12 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J583L18476 for ; Thu, 19 Jul 2001 01:08:03 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26309; Thu, 19 Jul 2001 01:06:35 -0400 Date: Thu, 19 Jul 2001 01:06:34 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: RE: DHCPv6 -19 Draft Comments In-Reply-To: <001501c10ff4$b8731070$2f290a0f@india.hp.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN yes ralph and I need to parse this... geeeezzz I am glad for all this great discussion but we are up against nasty deadline. /jim On Thu, 19 Jul 2001, Vijay Bhaskar A K wrote: > DHCPv6 -19 Draft Comments > -----Original Message----- > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > Behalf Of Bernie Volz (EUD) > Sent: Monday, July 16, 2001 11:33 PM > To: DHCPv6 discussion list > Subject: DHCPv6 -19 Draft Comments > > > Ralph, et al: > > In some further internal discussions and reviews, here are some other > issues to address in the revision to the DHCPv6 -19 draft: > > 1. In Section 14.3.1 (Creation and sending of Request messages), there is > no mention of using any of the "information" supplied by a server in the > Advertise message (in response to a Solicit). In DHCPv4, the client sent > information received in the Offer. We probably should be explicit about this > and perhaps even suggest that the information received by a client in an > Advertise is basically for information purposes only to help it determine > whether this server will offer it what it needs. Perhaps the addresses > assigned in the Advertise should even just be prefixes (interface portion > all 0's)? > > [Vijay Bhaskar A K] ***** > > I think, sending the prefix instead of real addresses in the SOLICIT > message is a nice idea. Becaues, for the IP address, we need some knob for > the expiration of the "offered" addresses and at the same time, the client > will be able to select the server who is giving address of its scope. It can > find out that, whether the server is capable of giving the number of address > it has asked. I feel that, we have to specifically say that, the server MUST > send the IA option filled with prefixes, if it has that free pool of those > many addresses. Otherwise, what will happen, if the server's preference > value is 255 and it don't have the free pool of addresses to be assigned. > > If instead we want the server to assign "real" addresses, should something > be said about how long those should be valid and whether the server should > attempt to assign those same addresses to the client in a subsequent > Request/Reply exchange for the IA? Perhaps we could punt and say this is a > server implementation issue (whether it assigns real addresses and whether > those are held for some (short) time for the client)? > > NOTE: If real addresses are returned, perhaps a client might even initiate > DAD during the Request/Reply in which case it can do these two items in > parallel (though this would be somewhat tricky since it would not want to > Decline the addresses before receiving the Reply). > > Also, while checking the draft regarding this issue, I noticed: > - Section 13.4.2 (Creation and sending of Advertise messages) does not > even say anything about the ORO option that a client might have specified. > Shouldn't we indicate that the Advertise message SHOULD include options for > all OROs that were included in the Solicit if the server is willing/capable > of offering a value for that option? > > - Section 14.3.1 (Creation and sending of Request messages) the first > sentence says "If a client has no valid IPv6 addresses of sufficient scope > to communicate with a DHCP server, ..." Huh? Even if it *DOES* have an > address of sufficient scope, we don't want the client sending messages > directly to the server. This must be some old text that should be dropped. > > 2. In Section 14.3.1, we should perhaps explicitly indicate that the > client should add an ORO option (it now says "The client adds any > appropriate options" ... but in many cases that just means an ORO option > with appropriate options specified in that option. > > 3. During the WG / Design Team (I forget which, if not both) we did > discuss designing a "quick" handshake for allowing a client to assign an > address. I would assume we'd define a new option that the client could use > to communicate to the server that it is doing this. Would we use > Solicit/Advertise or Request/Reply for this (in many ways, Request/Reply > seems like a better mechanism - the Request could simply leave the "server > address" field as all 0's and that could even be the flag to the server). > Perhaps we decided to defer this for now and do it later? > > 4. At another time we also discussed using the server to just advertise > prefixes and allowing the client to generate the addresses? What about > adding a "P" bit (next to the "T"-temporary bit) to indicate that this is a > prefix from which the client should generate an address (or simply allowing > it to do so if the link-identifier field is all 0's). > > Willl there be lease for these kind of addresses or these are same as the > address formed by the stateful autoconf with infinite leases? > > Bernie Volz > Chief Technical Officer - DNS & DHCP Development Unit > Ericsson, Inc. > Tel: +1-508-875-3162 > Fax: +1-508-875-3018 > Mobile: +1-617-513-9060 > mailto:bernie.volz@ericsson.com > > > > From owner-dhcp-v6@bucknell.edu Thu Jul 19 01:34:17 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18484; Thu, 19 Jul 2001 01:34:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J5YVL17404; Thu, 19 Jul 2001 01:34:31 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6J5YKL16857 for ; Thu, 19 Jul 2001 01:34:20 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6J5U3f15623 for ; Wed, 18 Jul 2001 22:30:07 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6J5TWw01283 for ; Wed, 18 Jul 2001 22:29:32 -0700 (MST) Message-Id: <200107190529.f6J5TWw01283@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Circuit ID and Remote ID options In-Reply-To: Message from Jim Bound of "Thu, 19 Jul 2001 00:32:31 -0400." Date: Wed, 18 Jul 2001 22:29:32 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Just to note I like the circuit and route id stuff. I think it will be > used immediately by implementors. I don't see harm here? Unless its > controversial and will hold us up or we need gobs of text and such. But I > am not hearing folks against it? Works for me, obviously. :') I also think it will get immediate use, so putting it in the base draft, with the fixes that Bernie suggested is a win. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 19 01:34:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18623; Thu, 19 Jul 2001 01:34:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J5Z7L19132; Thu, 19 Jul 2001 01:35:07 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6J5YuL10196 for ; Thu, 19 Jul 2001 01:34:56 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6J5Uhf15627 for ; Wed, 18 Jul 2001 22:30:43 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6J5UCw01296 for ; Wed, 18 Jul 2001 22:30:12 -0700 (MST) Message-Id: <200107190530.f6J5UCw01296@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from Jim Bound of "Thu, 19 Jul 2001 00:33:28 -0400." Date: Wed, 18 Jul 2001 22:30:12 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > if the server checks the prefix of the renew it can know? You mean the IP source address? True enough. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 19 05:55:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12857; Thu, 19 Jul 2001 05:55:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6J9sPL24690; Thu, 19 Jul 2001 05:54:25 -0400 (EDT) Received: from palrel1.hp.com (palrel1.hp.com [156.153.255.242]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6J9sDL06720 for ; Thu, 19 Jul 2001 05:54:15 -0400 (EDT) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel1.hp.com (Postfix) with ESMTP id 24333225D for ; Thu, 19 Jul 2001 02:54:11 -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 PAA01776 for ; Thu, 19 Jul 2001 15:21:07 +0530 (IST) Reply-To: From: "Vijay Bhaskar A K" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 19 Jul 2001 15:23:58 +0530 Message-ID: <005701c11038$bb8d57e0$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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit No, the relay need not to be stateful. It can just compare the prefix of Source IP address of the client packet and has to compare with the prefix of its interface in which it is received. It don't need to parse the packet. It has to just see the sender's address, that's all. But, this prevent the more and more processing that going to be happened on the servers. I think, including this functionality in the relay won't be a big problem. ~Vijay > -----Original Message----- > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > Behalf Of Jim Bound > Sent: Thursday, July 19, 2001 10:18 AM > To: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > I think this is an option we can do later. But I think we > are asking to > much of the relay. The entire design goal has always been to keep the > relay as stateless as possible. If the relay knows which prefixes are > good for a client and has to parse the addresses in a client packet I > think I am against that as one who has worked on building a > router this is > a bit intense. In fact now that I think about it I think > this is simply > not a good idea. > > > /jim > > > On Wed, 18 Jul 2001, Ted Lemon wrote: > > > > > > The format of "Error Code" option is not specified in > the draft. It is > > > needed to be included. > > > > I think it goes into the IA option, but you're right - it > needs to be > > clarified. > > > > > It will be better, if this functionality can be > incorporated in the > > > agent,since, it is the only thing which knows well about > the prefix in which > > > the client message is received. And the advantage is, if > this checking is > > > done, this packet can be prevented from forwarding it to > the multiple > > > servers and save multiple processing time. The agent > itself can send the > > > NoPrefixMatch status directly to the client. > > > > Ooh, good point! I think it would be good if the agent could do > > this, although I have to admit that I am concerned that some people > > who implement relay agents may not want to have to delve into the IA > > to validate a packet. I'm in favor of doing as you suggest, but I > > suggest that we defer to the working group to see if any router > > vendors have a problem with this. > > > > Also, the timing is a bit tight on making this change, and > I wouldn't > > blame the authors if they said "no, sorry, do this in a new > draft." I > > think it's okay to make this optional, so doing it in a > seperate draft > > should be fine. > > > > > If the client is receiving the error status as > NoPrefixMatch error, what > > > may be the reason other than client's plugging in to > different subnet. I > > > agree that, some roghe server can send this status, but, > it can be prevented > > > by authentication. > > > > The client may be mobile, and may be able to reach more than one > > mobile access point. The two access points may want to think of > > themselves as seperate links, even though their physical link-layers > > overlap. I don't know how likely this is with existing technology, > > but it's certainly been discussed with respect to 3G > phones. I think > > it's important to leave the language open for this case. > > > > _MelloN_ > > > > From owner-dhcp-v6@bucknell.edu Thu Jul 19 09:32:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29562; Thu, 19 Jul 2001 09:32:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JDWUL07038; Thu, 19 Jul 2001 09:32:30 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JDWML23581 for ; Thu, 19 Jul 2001 09:32:22 -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 f6JDWLp03994 for ; Thu, 19 Jul 2001 08:32:21 -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 f6JDWLX13687 for ; Thu, 19 Jul 2001 08:32:21 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 19 08:32:20 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPJAGJJ>; Thu, 19 Jul 2001 08:32:19 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32D7@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 19 Jul 2001 08:32:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11057.3B9D2C80" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11057.3B9D2C80 Content-Type: text/plain; charset="iso-8859-1" This probably won't add much since in the case of a Confirm, the client will likely be using its link-local address since that is the only one it can reliable use (well, except for others that it has obtained via stateless on the link). Thus, by definition, the client's Source IP address will be *valid*. If the client is unicasting a message to the server (hence it is likely using an address of greater scope than the link-local unless the server is on the link), the relay won't see it but the routers will and they would drop packets with invalid source addresses if they do egress filtering. In order for the relay to add valid, it would need to parse the client's message, find the addresses in the IAs, and check their prefixes. Hence, it is a bit of work. I don't think the relay requires any state to do this since it just needs to know the prefixes valid on that interface (which it should know either because it is the router OR because it can listen to Router Advertisements and learn them) and to parse the message. No state needs to be retained *BETWEEN* client messages. However, while there is some merit in allowing this, again, a server *MUST* also do it because it may be on-link with the client (hence no relay) or perhaps some relays will not chose to implement this. So, if we wanted to explicitly allow this relay behavoir, we could say that Relays *MAY* do this. In any case, servers *MUST* do it. I'm also wondering if there are cases where a DHCPv6 server might give out addressses that a relay has no knowledge of. For example, is there any prohibition against giving out IPv4 (mapped) addresses? [Perhaps these prefixes would also be advertised via Router Advertisements and thus we are OK.] - Bernie -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Thursday, July 19, 2001 5:54 AM To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] No, the relay need not to be stateful. It can just compare the prefix of Source IP address of the client packet and has to compare with the prefix of its interface in which it is received. It don't need to parse the packet. It has to just see the sender's address, that's all. But, this prevent the more and more processing that going to be happened on the servers. I think, including this functionality in the relay won't be a big problem. ~Vijay > -----Original Message----- > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > Behalf Of Jim Bound > Sent: Thursday, July 19, 2001 10:18 AM > To: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > I think this is an option we can do later. But I think we > are asking to > much of the relay. The entire design goal has always been to keep the > relay as stateless as possible. If the relay knows which prefixes are > good for a client and has to parse the addresses in a client packet I > think I am against that as one who has worked on building a > router this is > a bit intense. In fact now that I think about it I think > this is simply > not a good idea. > > > /jim > > > On Wed, 18 Jul 2001, Ted Lemon wrote: > > > > > > The format of "Error Code" option is not specified in > the draft. It is > > > needed to be included. > > > > I think it goes into the IA option, but you're right - it > needs to be > > clarified. > > > > > It will be better, if this functionality can be > incorporated in the > > > agent,since, it is the only thing which knows well about > the prefix in which > > > the client message is received. And the advantage is, if > this checking is > > > done, this packet can be prevented from forwarding it to > the multiple > > > servers and save multiple processing time. The agent > itself can send the > > > NoPrefixMatch status directly to the client. > > > > Ooh, good point! I think it would be good if the agent could do > > this, although I have to admit that I am concerned that some people > > who implement relay agents may not want to have to delve into the IA > > to validate a packet. I'm in favor of doing as you suggest, but I > > suggest that we defer to the working group to see if any router > > vendors have a problem with this. > > > > Also, the timing is a bit tight on making this change, and > I wouldn't > > blame the authors if they said "no, sorry, do this in a new > draft." I > > think it's okay to make this optional, so doing it in a > seperate draft > > should be fine. > > > > > If the client is receiving the error status as > NoPrefixMatch error, what > > > may be the reason other than client's plugging in to > different subnet. I > > > agree that, some roghe server can send this status, but, > it can be prevented > > > by authentication. > > > > The client may be mobile, and may be able to reach more than one > > mobile access point. The two access points may want to think of > > themselves as seperate links, even though their physical link-layers > > overlap. I don't know how likely this is with existing technology, > > but it's certainly been discussed with respect to 3G > phones. I think > > it's important to leave the language open for this case. > > > > _MelloN_ > > > > ------_=_NextPart_001_01C11057.3B9D2C80 Content-Type: text/html; charset="iso-8859-1" RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

This probably won't add much since in the case of a Confirm, the client
will likely be using its link-local address since that is the only one
it can reliable use (well, except for others that it has obtained via
stateless on the link). Thus, by definition, the client's Source IP
address will be *valid*.

If the client is unicasting a message to the server (hence it is likely
using an address of greater scope than the link-local unless the server
is on the link), the relay won't see it but the routers will and they
would drop packets with invalid source addresses if they do egress
filtering.

In order for the relay to add valid, it would need to parse the client's
message, find the addresses in the IAs, and check their prefixes. Hence,
it is a bit of work.

I don't think the relay requires any state to do this since it just needs
to know the prefixes valid on that interface (which it should know either
because it is the router OR because it can listen to Router Advertisements
and learn them) and to parse the message. No state needs to be retained
*BETWEEN* client messages.

However, while there is some merit in allowing this, again, a server *MUST*
also do it because it may be on-link with the client (hence no relay) or
perhaps some relays will not chose to implement this.

So, if we wanted to explicitly allow this relay behavoir, we could say
that Relays *MAY* do this. In any case, servers *MUST* do it.

I'm also wondering if there are cases where a DHCPv6 server might give out
addressses that a relay has no knowledge of. For example, is there any
prohibition against giving out IPv4 (mapped) addresses? [Perhaps these
prefixes would also be advertised via Router Advertisements and thus we
are OK.]

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, July 19, 2001 5:54 AM
To: DHCPv6 discussion list
Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]


No, the relay need not to be stateful. It can just compare the
prefix of Source IP address of the client packet and has to compare
with the prefix of its interface in which it is received. It don't need
to parse the packet. It has to just see the sender's address, that's all.
But, this prevent the more and more processing that going to be
happened on the servers. I think, including this functionality in the relay
won't be a big problem.
~Vijay

> -----Original Message-----
> From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On
> Behalf Of Jim Bound
> Sent: Thursday, July 19, 2001 10:18 AM
> To: DHCPv6 discussion list
> Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]
>
>
> I think this is an option we can do later.  But I think we
> are asking to
> much of the relay.  The entire design goal has always been to keep the
> relay as stateless as possible.  If the relay knows which prefixes are
> good for a client and has to parse the addresses in a client packet I
> think I am against that as one who has worked on building a
> router this is
> a bit intense.  In fact now that I think about it I think
> this is simply
> not a good idea.
>
>
> /jim
>
>
> On Wed, 18 Jul 2001, Ted Lemon wrote:
>
> >
> > >   The format of "Error Code" option is not specified in
> the draft. It is
> > > needed to be included.
> >
> > I think it goes into the IA option, but you're right - it
> needs to be
> > clarified.
> >
> > >   It will be better, if this functionality can be
> incorporated in the
> > > agent,since, it is the only thing which knows well about
> the prefix in which
> > > the client message is received. And the advantage is, if
> this checking is
> > > done, this packet can be prevented from forwarding it to
> the multiple
> > > servers and save multiple processing time. The agent
> itself can send the
> > > NoPrefixMatch status directly to the client.
> >
> > Ooh, good point!   I think it would be good if the agent could do
> > this, although I have to admit that I am concerned that some people
> > who implement relay agents may not want to have to delve into the IA
> > to validate a packet.   I'm in favor of doing as you suggest, but I
> > suggest that we defer to the working group to see if any router
> > vendors have a problem with this.
> >
> > Also, the timing is a bit tight on making this change, and
> I wouldn't
> > blame the authors if they said "no, sorry, do this in a new
> draft."  I
> > think it's okay to make this optional, so doing it in a
> seperate draft
> > should be fine.
> >
> > >   If the client is receiving the error status as
> NoPrefixMatch error, what
> > > may be the reason other than client's plugging in to
> different subnet. I
> > > agree that, some roghe server can send this status, but,
> it can be prevented
> > > by authentication.
> >
> > The client may be mobile, and may be able to reach more than one
> > mobile access point.  The two access points may want to think of
> > themselves as seperate links, even though their physical link-layers
> > overlap.  I don't know how likely this is with existing technology,
> > but it's certainly been discussed with respect to 3G
> phones.  I think
> > it's important to leave the language open for this case.
> >
> >                            _MelloN_
> >
>
>

------_=_NextPart_001_01C11057.3B9D2C80-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 11:55:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00106; Thu, 19 Jul 2001 11:55:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JFt8L13088; Thu, 19 Jul 2001 11:55:08 -0400 (EDT) Received: from mail-gw01.gap.com ([206.16.32.97]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JFsxL16436 for ; Thu, 19 Jul 2001 11:54:59 -0400 (EDT) Received: from mailhub01.gap.com (mailhub01.gap.com [9.32.202.151]) by mail-gw01.gap.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA05872 for ; Thu, 19 Jul 2001 08:54:18 -0700 (PDT) From: Relfe_Tan@gap.com Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43]) by mailhub01.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id IAA00250 for ; Thu, 19 Jul 2001 08:54:51 -0700 (PDT) Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A8E.0056FBFF ; Thu, 19 Jul 2001 08:50:06 -0700 X-Lotus-FromDomain: GAPINC To: DHCPv6 discussion list Message-ID: <88256A8E.0056FB42.00@smtpmta01.gap.com> Date: Thu, 19 Jul 2001 08:52:43 -0700 Subject: RE: Simplify release and decline of addresses Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN been trying to unsubscribe.. "Jim Bound" on 07/18/2001 09:41:40 PM Please respond to dhcp-v6@bucknell.edu To: "DHCPv6 discussion list" cc: (bcc: Relfe Tan/SB/GAPINC) Subject: RE: Simplify release and decline of addresses The client does not request addresses per se in dhcpv6 now directly. It asks for them. So the server has control over the T bit via policy. /jim On Wed, 18 Jul 2001, Bernie Volz (EUD) wrote: > Vijay: > > Removing "addr status" in the IA option without also removing the T bit > won't help save bytes since the T bit will require the byte anyway. We > might change "addr status" to "unused - MBZ" though if we're not using it. > > Regarding a new option to handle Temporary Addresses, I think this has > merit simply because there has been no way for a client to communicate > what kind of addresses it wants. Having this option provides that mechanism. > Alternatives, such as allowing 'num-addrs' and thus some address information > (T bit) to be specified by the client in a Request were discussed at one > point but did not make it into the -19 draft and I'm not sure if it would be > in the -20. > > Perhaps Ralph and Jim will care to provide some indication of how this will be > resolved in the -20 draft - to give the client some ability to communicate to > the server what it needs. OR, perhaps the answer is simply "no, we're not > going to support it - it is up to the server to figure it out." > > There are some issues with a new option - such as the IAID spaces must not > overlap, and then what happens if the wrong option is used with an IAID in > a Renew (or Release, ...). So, it gets messy and is probably not the best > approach. > > Your point about graceful renumbering doesn't make sense ... IPv6 (and > DHCPV6) already provide for this. I don't think we want addresses to between > IA's so I think this concept is a bad one. Just like stateless addresses where > lifetimes can be extended, so can they with DHCPv6 (that is either or both > the preferred and valid). > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Wednesday, July 18, 2001 6:17 PM > To: DHCPv6 discussion list > Subject: RE: Simplify release and decline of addresses > > > Hi, > Find my comments inline. > ~Vijay > > > -----Original Message----- > > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > > Behalf Of Ralph Droms > > Sent: Wednesday, July 18, 2001 7:13 PM > > To: DHCPv6 discussion list > > Subject: Simplify release and decline of addresses > > > > > > Ted suggests a simplification: requiring that all the > > addresses in an IA be > > released or declined, rather than just some of those > > addresses. Ted also > > wrote text describing the server behavior in response to a > > Decline message > > (which is missing from the -19 rev). > > > > - Ralph > > > > 14.4.5. Receipt of Release messages > > > > Upon the receipt of a valid Release message, the server > > examines the > > IAs and the addresses in the IAs for validity. If the IAs in the > > message are in a binding for the client and the addresses > > in the IAs > > have been assigned by the server to those IA, the server deletes > > the addresses from the IAs and makes the addresses available for > > assignment to other clients. > > > > [IMHO, this is too complicated. I think the client should always > > release all addresses in an IA - that is, it should just send an empty > > IA as described below. Otherwise you get into complexities about how > > to back out of an erroneous transaction that I think can't be solved.] > > Yes. I agree that, the release/decline of addresses as whole IA will > simplify the more. So, here,the status field returned will be the same > for all the addresses of the IA and it can be very well reflected in IA > status. So, do we really need the "addr status" field? Whatever the > error status defined can be returned in IA status itself. So, i feel > that, we can remove the "addr status" field in IA. It can save many > bytes, if the addresses in th IA are very large in number. > > Another suggestion is, because of handling Temporary address only, we > have introduced the "T" bit in IA option. Why can't we define a new > option for temporary address IA (TMP_IA). Using this TMP_IA, the client > can ask for one or more temporary addresses. > > The main reason behind is, > > * The time values T1 and T2 are defined for specifying the time at which > the client has to contact the server. But, for the temporary addresses, > renewal and rebind is not possible. So, T1 and T2 are not necessary. > So, we can remove these fields. > > * Normally, if the clients are requesting for the normal addresses, they > will not be needing temporary addresses. The clients requesting for > both will be rare. So, why do we need to put a bit in IA and giving > more burden to IA option. > > So, the TMP_IA option looks like this. > > 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 TMP_IA | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IAID (4 octets) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | IA status | num-addrs | prefix length | IPv6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | | > | addresses | > | (16 octets) +-+-+-+-+-+-+ > | | preferred | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | lifetime | valid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | lifetime |IPv6 | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > | | > | addresses | > | (16 octets) +-+-+-+-+-+-+ > | | preferred | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | lifetime | valid | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | lifetime | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > I'm not sure whether there will be an allignment problem. But, we can > reduce unnecessary bytes using this option. > > * One more point to be noted is, a fair implementation of DHCPv6 should > support "graceful renumbering". It should provide some grace period to > the old prefixes. The deprecated IPv6 addresses (addresses of old > prefixes) almost look like the temporary address with preferred life > time as 0 and valid life time as 1-2 days. This option will be more > useful for handling those deprecated addresses, since those addresses > are not supposed to be renewed/rebinded. > > > > > 14.4.5-1/2. Receipt of Decline messages (To be inserted after existing > > section 14.4.5 in -19 rev) > > > > Upon the receipt of a valid Decline message, the server > > examines the > > IAs and the addresses in the IAs for validity. If any IA in the > > message is not an IA that has been assigned by the server to that > > client, or if any addresses are mentioned in an IA that were not > > assigned by the server to the client, the server MUST NOT further > > process the message, but should send a Reply message indicating a > > NoBinding status. > > > > For each IA in the message, if there are any addresses > > mentioned in > > that IA, the server SHOULD mark each of these addresses as in > > conflict and SHOULD NOT make these addresses available for > > allocation to other clients. Any addresses that the server has > > allocated to that IA but that are not mentioned in the message > > SHOULD be made available for assignment to other clients. > > > > [As above, I would argue that the client should simply send empty IAs, > > and let all the addresses be declined. This has the disadvantage > > that you can lose addresses that were not in conflict, but it makes > > the whole transaction a lot simpler, and I think simplicity is a real > > virtue in this case.] > > > > If an IA is mentioned in the Decline message without any > > accompanying addresses, the server SHOULD mark all the > > addresses in > > the IA as being in conflict, and SHOULD NOT make these addresses > > available for immediate assignment to other clients. > > > > Server implementors SHOULD implement a strategy for reclaiming > > these IP addresses if there are no addresses available for > > allocation. Server implementors MAY also implement a strategy to > > detect a client that is repeatedly allocating and then declining > > addresses. When such a client is detected, the server SHOULD > > refuse to allocate further addresses to that client for > > DECLINE_COOLOFF (see section 7.5) seconds. > > > > The server then generates a Reply message. If all of the IAs were > > valid, the server sets the "status" field to "Success". If any of > > the IAs were invalid, the server sets the "status" field to > > "NoBinding" (section 7.4). > > > > -- > ____Vijay_Bhaskar_A_K____ > ______Inet_Services______ > ________HP_ISO___________ > ____Ph:_2251554_1424_____ > ___Pager:_9624_371137____ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 11:55:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00116; Thu, 19 Jul 2001 11:55:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JFtrL03242; Thu, 19 Jul 2001 11:55:53 -0400 (EDT) Received: from mail-gw01.gap.com ([206.16.32.97]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JFtiL02627 for ; Thu, 19 Jul 2001 11:55:44 -0400 (EDT) Received: from mailhub01.gap.com (mailhub01.gap.com [9.32.202.151]) by mail-gw01.gap.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA06217 for ; Thu, 19 Jul 2001 08:55:03 -0700 (PDT) From: Relfe_Tan@gap.com Received: from smtpmta01.gap.com (smtpmta01.gap.com [9.30.201.43]) by mailhub01.gap.com (Pro-8.9.3/Pro-8.9.3) with SMTP id IAA00402 for ; Thu, 19 Jul 2001 08:55:36 -0700 (PDT) Received: by smtpmta01.gap.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 88256A8E.00570C68 ; Thu, 19 Jul 2001 08:50:48 -0700 X-Lotus-FromDomain: GAPINC To: DHCPv6 discussion list Message-ID: <88256A8E.00570B35.00@smtpmta01.gap.com> Date: Thu, 19 Jul 2001 08:53:22 -0700 Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN been trying to unsubscribe.. "Jim Bound" on 07/18/2001 09:58:57 PM Please respond to dhcp-v6@bucknell.edu To: "DHCPv6 discussion list" cc: (bcc: Relfe Tan/SB/GAPINC) Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] yep I agree? are we all in violent agreement !!!!! /jim On Wed, 18 Jul 2001, Ted Lemon wrote: > > > The Confirm is multicast by the client, picked up a relay and sent > > to a server. > > Right, and that's why the language you wrote applies to the Confirm > message! > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 12:34:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07615; Thu, 19 Jul 2001 12:34:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JGZAL15285; Thu, 19 Jul 2001 12:35:10 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JGYsL13129 for ; Thu, 19 Jul 2001 12:34:54 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA11340; Thu, 19 Jul 2001 12:34:52 -0400 Date: Thu, 19 Jul 2001 12:34:52 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <200107190530.f6J5UCw01296@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN yep... /jim On Wed, 18 Jul 2001, Ted Lemon wrote: > > > if the server checks the prefix of the renew it can know? > > You mean the IP source address? True enough. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 12:41:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08523; Thu, 19 Jul 2001 12:41:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JGfQL21245; Thu, 19 Jul 2001 12:41:26 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JGfLL24045 for ; Thu, 19 Jul 2001 12:41:21 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA11047; Thu, 19 Jul 2001 12:39:57 -0400 Date: Thu, 19 Jul 2001 12:39:57 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <005701c11038$bb8d57e0$2f290a0f@india.hp.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN true. but the relay cannot see the addresses inside the IA option. thats the addresses that will have to be nak'd not the source address. /jim On Thu, 19 Jul 2001, Vijay Bhaskar A K wrote: > No, the relay need not to be stateful. It can just compare the > prefix of Source IP address of the client packet and has to compare > with the prefix of its interface in which it is received. It don't need > to parse the packet. It has to just see the sender's address, that's all. > But, this prevent the more and more processing that going to be > happened on the servers. I think, including this functionality in the relay > won't be a big problem. > ~Vijay > > > -----Original Message----- > > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > > Behalf Of Jim Bound > > Sent: Thursday, July 19, 2001 10:18 AM > > To: DHCPv6 discussion list > > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > > > > I think this is an option we can do later. But I think we > > are asking to > > much of the relay. The entire design goal has always been to keep the > > relay as stateless as possible. If the relay knows which prefixes are > > good for a client and has to parse the addresses in a client packet I > > think I am against that as one who has worked on building a > > router this is > > a bit intense. In fact now that I think about it I think > > this is simply > > not a good idea. > > > > > > /jim > > > > > > On Wed, 18 Jul 2001, Ted Lemon wrote: > > > > > > > > > The format of "Error Code" option is not specified in > > the draft. It is > > > > needed to be included. > > > > > > I think it goes into the IA option, but you're right - it > > needs to be > > > clarified. > > > > > > > It will be better, if this functionality can be > > incorporated in the > > > > agent,since, it is the only thing which knows well about > > the prefix in which > > > > the client message is received. And the advantage is, if > > this checking is > > > > done, this packet can be prevented from forwarding it to > > the multiple > > > > servers and save multiple processing time. The agent > > itself can send the > > > > NoPrefixMatch status directly to the client. > > > > > > Ooh, good point! I think it would be good if the agent could do > > > this, although I have to admit that I am concerned that some people > > > who implement relay agents may not want to have to delve into the IA > > > to validate a packet. I'm in favor of doing as you suggest, but I > > > suggest that we defer to the working group to see if any router > > > vendors have a problem with this. > > > > > > Also, the timing is a bit tight on making this change, and > > I wouldn't > > > blame the authors if they said "no, sorry, do this in a new > > draft." I > > > think it's okay to make this optional, so doing it in a > > seperate draft > > > should be fine. > > > > > > > If the client is receiving the error status as > > NoPrefixMatch error, what > > > > may be the reason other than client's plugging in to > > different subnet. I > > > > agree that, some roghe server can send this status, but, > > it can be prevented > > > > by authentication. > > > > > > The client may be mobile, and may be able to reach more than one > > > mobile access point. The two access points may want to think of > > > themselves as seperate links, even though their physical link-layers > > > overlap. I don't know how likely this is with existing technology, > > > but it's certainly been discussed with respect to 3G > > phones. I think > > > it's important to leave the language open for this case. > > > > > > _MelloN_ > > > > > > > > From owner-dhcp-v6@bucknell.edu Thu Jul 19 12:46:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09222; Thu, 19 Jul 2001 12:46:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JGksL14919; Thu, 19 Jul 2001 12:46:54 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JGkpL26121 for ; Thu, 19 Jul 2001 12:46:52 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA11460; Thu, 19 Jul 2001 12:46:51 -0400 Date: Thu, 19 Jul 2001 12:46:51 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <66F66129A77AD411B76200508B65AC697B32D7@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The state would be if teh relay wanted to make a decison whats inside the IA. I don't think we should say anything or make assumptions about relays listening to RAs on IPv6 link in DHCPv6 or make assumptions from that. That is not territory we should tread. Or state using DAD etc.. The reason is that we should not make assumptions on that IPv6 evolution in IPv6 in the dhcpv6 spec. Also routers will not send RAs with v6mapped. /jim On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote: > This probably won't add much since in the case of a Confirm, the client > will likely be using its link-local address since that is the only one > it can reliable use (well, except for others that it has obtained via > stateless on the link). Thus, by definition, the client's Source IP > address will be *valid*. > > If the client is unicasting a message to the server (hence it is likely > using an address of greater scope than the link-local unless the server > is on the link), the relay won't see it but the routers will and they > would drop packets with invalid source addresses if they do egress > filtering. > > In order for the relay to add valid, it would need to parse the client's > message, find the addresses in the IAs, and check their prefixes. Hence, > it is a bit of work. > > I don't think the relay requires any state to do this since it just needs > to know the prefixes valid on that interface (which it should know either > because it is the router OR because it can listen to Router Advertisements > and learn them) and to parse the message. No state needs to be retained > *BETWEEN* client messages. > > However, while there is some merit in allowing this, again, a server *MUST* > also do it because it may be on-link with the client (hence no relay) or > perhaps some relays will not chose to implement this. > > So, if we wanted to explicitly allow this relay behavoir, we could say > that Relays *MAY* do this. In any case, servers *MUST* do it. > > I'm also wondering if there are cases where a DHCPv6 server might give out > addressses that a relay has no knowledge of. For example, is there any > prohibition against giving out IPv4 (mapped) addresses? [Perhaps these > prefixes would also be advertised via Router Advertisements and thus we > are OK.] > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] > Sent: Thursday, July 19, 2001 5:54 AM > To: DHCPv6 discussion list > Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > No, the relay need not to be stateful. It can just compare the > prefix of Source IP address of the client packet and has to compare > with the prefix of its interface in which it is received. It don't need > to parse the packet. It has to just see the sender's address, that's all. > But, this prevent the more and more processing that going to be > happened on the servers. I think, including this functionality in the relay > won't be a big problem. > ~Vijay > > > -----Original Message----- > > From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On > > Behalf Of Jim Bound > > Sent: Thursday, July 19, 2001 10:18 AM > > To: DHCPv6 discussion list > > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > > > > I think this is an option we can do later. But I think we > > are asking to > > much of the relay. The entire design goal has always been to keep the > > relay as stateless as possible. If the relay knows which prefixes are > > good for a client and has to parse the addresses in a client packet I > > think I am against that as one who has worked on building a > > router this is > > a bit intense. In fact now that I think about it I think > > this is simply > > not a good idea. > > > > > > /jim > > > > > > On Wed, 18 Jul 2001, Ted Lemon wrote: > > > > > > > > > The format of "Error Code" option is not specified in > > the draft. It is > > > > needed to be included. > > > > > > I think it goes into the IA option, but you're right - it > > needs to be > > > clarified. > > > > > > > It will be better, if this functionality can be > > incorporated in the > > > > agent,since, it is the only thing which knows well about > > the prefix in which > > > > the client message is received. And the advantage is, if > > this checking is > > > > done, this packet can be prevented from forwarding it to > > the multiple > > > > servers and save multiple processing time. The agent > > itself can send the > > > > NoPrefixMatch status directly to the client. > > > > > > Ooh, good point! I think it would be good if the agent could do > > > this, although I have to admit that I am concerned that some people > > > who implement relay agents may not want to have to delve into the IA > > > to validate a packet. I'm in favor of doing as you suggest, but I > > > suggest that we defer to the working group to see if any router > > > vendors have a problem with this. > > > > > > Also, the timing is a bit tight on making this change, and > > I wouldn't > > > blame the authors if they said "no, sorry, do this in a new > > draft." I > > > think it's okay to make this optional, so doing it in a > > seperate draft > > > should be fine. > > > > > > > If the client is receiving the error status as > > NoPrefixMatch error, what > > > > may be the reason other than client's plugging in to > > different subnet. I > > > > agree that, some roghe server can send this status, but, > > it can be prevented > > > > by authentication. > > > > > > The client may be mobile, and may be able to reach more than one > > > mobile access point. The two access points may want to think of > > > themselves as seperate links, even though their physical link-layers > > > overlap. I don't know how likely this is with existing technology, > > > but it's certainly been discussed with respect to 3G > > phones. I think > > > it's important to leave the language open for this case. > > > > > > _MelloN_ > > > > > > > > From owner-dhcp-v6@bucknell.edu Thu Jul 19 13:40:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20593; Thu, 19 Jul 2001 13:40:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JHebL19713; Thu, 19 Jul 2001 13:40:38 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JHeZL03640 for ; Thu, 19 Jul 2001 13:40:35 -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 f6JHeYp23256 for ; Thu, 19 Jul 2001 12:40: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 f6JHeYW08825 for ; Thu, 19 Jul 2001 12:40:34 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 19 12:40:33 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPJAYP3>; Thu, 19 Jul 2001 12:40:33 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32DD@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 19 Jul 2001 12:40:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11079.E8F3E5F0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11079.E8F3E5F0 Content-Type: text/plain; charset="iso-8859-1" I meant the prefix of each address in the IA(s) in the client's message. Not the IP source address of the client's message - that is meaningless in terms of where the client is unless it is a link local address (since then the server knows it is on the received interface). Depending on what checking routers will do, the IP source address of a packet can easily be wrong (or let us say invalid for the link the packet came from). I don't recall what the requirements on routers are in IPv6 with regard to source address checking, so perhaps this can't happen in IPv6. But most IPv4 routers don't check source addresses (except when exit filters are added). If we allow client unicast (per option 18.10) there are three possibilities for how messages are delivered to the server: 1. On-link - the client is on the same link as the server, source address will be link-local. 2. Relayed - the client's message will be in a Relay-forward and the source address will be the relay's, not the client's. 3. Unicast - the client unicasts the message and therefore must use a source address of suitable scope. (See above regarding how reliable this information may be.) - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Thursday, July 19, 2001 12:35 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] yep... /jim On Wed, 18 Jul 2001, Ted Lemon wrote: > > > if the server checks the prefix of the renew it can know? > > You mean the IP source address? True enough. > > _MelloN_ > ------_=_NextPart_001_01C11079.E8F3E5F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

I meant the prefix of each address in the IA(s) in = the client's
message. Not the IP source address of the client's = message -
that is meaningless in terms of where the client is = unless
it is a link local address (since then the server = knows it is
on the received interface).

Depending on what checking routers will do, the IP = source address
of a packet can easily be wrong (or let us say = invalid for the
link the packet came from). I don't recall what the = requirements
on routers are in IPv6 with regard to source address = checking, so
perhaps this can't happen in IPv6. But most IPv4 = routers don't
check source addresses (except when exit filters are = added).

If we allow client unicast (per option 18.10) there = are three
possibilities for how messages are delivered to the = server:
1. On-link - the client is on the same link as the = server, source
address will be link-local.
2. Relayed - the client's message will be in a = Relay-forward and
the source address will be the relay's, not the = client's.
3. Unicast - the client unicasts the message and = therefore must
use a source address of suitable scope. (See above = regarding how
reliable this information may be.)

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]=
Sent: Thursday, July 19, 2001 12:35 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft = Changes]


yep...


/jim


On Wed, 18 Jul 2001, Ted Lemon wrote:

>
> > if the server checks the prefix of the = renew it can know?
>
> You mean the IP source address?   = True enough.
>
>       =         =         =        _MelloN_
>

------_=_NextPart_001_01C11079.E8F3E5F0-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 14:08:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29068; Thu, 19 Jul 2001 14:08:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JI8dL07904; Thu, 19 Jul 2001 14:08:39 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JI8aL17963 for ; Thu, 19 Jul 2001 14:08:36 -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 f6JI8Zp09147 for ; Thu, 19 Jul 2001 13:08:35 -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 f6JI8ZW26034 for ; Thu, 19 Jul 2001 13:08:35 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Jul 19 13:08:34 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPJA583>; Thu, 19 Jul 2001 13:08:34 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32DF@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 19 Jul 2001 13:08:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1107D.D25DE5D0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C1107D.D25DE5D0 Content-Type: text/plain; charset="iso-8859-1" Oh ... one more point for consideration ... If a client has multiple links and has received the "Server Unicast Option" from the server, what's to prevent the client from sending the server a message out another interface (using a prefix that the server has perhaps no knowledge of). Or, the client might use a stateless autoconfigured address, again one the server has no knowledge of since there's no reason to give the server this information. Therefore when the server receives a message, it can NOT make ANY assumption about the client's location based on the source address of the packet (unless it is a link local). - Bernie -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Thursday, July 19, 2001 9:32 AM To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] This probably won't add much since in the case of a Confirm, the client will likely be using its link-local address since that is the only one it can reliable use (well, except for others that it has obtained via stateless on the link). Thus, by definition, the client's Source IP address will be *valid*. If the client is unicasting a message to the server (hence it is likely using an address of greater scope than the link-local unless the server is on the link), the relay won't see it but the routers will and they would drop packets with invalid source addresses if they do egress filtering. In order for the relay to add valid, it would need to parse the client's message, find the addresses in the IAs, and check their prefixes. Hence, it is a bit of work. I don't think the relay requires any state to do this since it just needs to know the prefixes valid on that interface (which it should know either because it is the router OR because it can listen to Router Advertisements and learn them) and to parse the message. No state needs to be retained *BETWEEN* client messages. However, while there is some merit in allowing this, again, a server *MUST* also do it because it may be on-link with the client (hence no relay) or perhaps some relays will not chose to implement this. So, if we wanted to explicitly allow this relay behavoir, we could say that Relays *MAY* do this. In any case, servers *MUST* do it. I'm also wondering if there are cases where a DHCPv6 server might give out addressses that a relay has no knowledge of. For example, is there any prohibition against giving out IPv4 (mapped) addresses? [Perhaps these prefixes would also be advertised via Router Advertisements and thus we are OK.] - Bernie -----Original Message----- From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com ] Sent: Thursday, July 19, 2001 5:54 AM To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] No, the relay need not to be stateful. It can just compare the prefix of Source IP address of the client packet and has to compare with the prefix of its interface in which it is received. It don't need to parse the packet. It has to just see the sender's address, that's all. But, this prevent the more and more processing that going to be happened on the servers. I think, including this functionality in the relay won't be a big problem. ~Vijay > -----Original Message----- > From: owner-dhcp-v6@bucknell.edu [ mailto:owner-dhcp-v6@bucknell.edu ]On > Behalf Of Jim Bound > Sent: Thursday, July 19, 2001 10:18 AM > To: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > I think this is an option we can do later. But I think we > are asking to > much of the relay. The entire design goal has always been to keep the > relay as stateless as possible. If the relay knows which prefixes are > good for a client and has to parse the addresses in a client packet I > think I am against that as one who has worked on building a > router this is > a bit intense. In fact now that I think about it I think > this is simply > not a good idea. > > > /jim > > > On Wed, 18 Jul 2001, Ted Lemon wrote: > > > > > > The format of "Error Code" option is not specified in > the draft. It is > > > needed to be included. > > > > I think it goes into the IA option, but you're right - it > needs to be > > clarified. > > > > > It will be better, if this functionality can be > incorporated in the > > > agent,since, it is the only thing which knows well about > the prefix in which > > > the client message is received. And the advantage is, if > this checking is > > > done, this packet can be prevented from forwarding it to > the multiple > > > servers and save multiple processing time. The agent > itself can send the > > > NoPrefixMatch status directly to the client. > > > > Ooh, good point! I think it would be good if the agent could do > > this, although I have to admit that I am concerned that some people > > who implement relay agents may not want to have to delve into the IA > > to validate a packet. I'm in favor of doing as you suggest, but I > > suggest that we defer to the working group to see if any router > > vendors have a problem with this. > > > > Also, the timing is a bit tight on making this change, and > I wouldn't > > blame the authors if they said "no, sorry, do this in a new > draft." I > > think it's okay to make this optional, so doing it in a > seperate draft > > should be fine. > > > > > If the client is receiving the error status as > NoPrefixMatch error, what > > > may be the reason other than client's plugging in to > different subnet. I > > > agree that, some roghe server can send this status, but, > it can be prevented > > > by authentication. > > > > The client may be mobile, and may be able to reach more than one > > mobile access point. The two access points may want to think of > > themselves as seperate links, even though their physical link-layers > > overlap. I don't know how likely this is with existing technology, > > but it's certainly been discussed with respect to 3G > phones. I think > > it's important to leave the language open for this case. > > > > _MelloN_ > > > > ------_=_NextPart_001_01C1107D.D25DE5D0 Content-Type: text/html; charset="iso-8859-1" RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]
Oh ... one more point for consideration ...
 
If a client has multiple links and has received the "Server Unicast Option" from the server,
what's to prevent the client from sending the server a message out another interface (using
a prefix that the server has perhaps no knowledge of).
 
Or, the client might use a stateless autoconfigured address, again one the server has no
knowledge of since there's no reason to give the server this information.
 
Therefore when the server receives a message, it can NOT make ANY assumption about
the client's location based on the source address of the packet (unless it is a link local).
 
- Bernie
-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Thursday, July 19, 2001 9:32 AM
To: DHCPv6 discussion list
Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

This probably won't add much since in the case of a Confirm, the client
will likely be using its link-local address since that is the only one
it can reliable use (well, except for others that it has obtained via
stateless on the link). Thus, by definition, the client's Source IP
address will be *valid*.

If the client is unicasting a message to the server (hence it is likely
using an address of greater scope than the link-local unless the server
is on the link), the relay won't see it but the routers will and they
would drop packets with invalid source addresses if they do egress
filtering.

In order for the relay to add valid, it would need to parse the client's
message, find the addresses in the IAs, and check their prefixes. Hence,
it is a bit of work.

I don't think the relay requires any state to do this since it just needs
to know the prefixes valid on that interface (which it should know either
because it is the router OR because it can listen to Router Advertisements
and learn them) and to parse the message. No state needs to be retained
*BETWEEN* client messages.

However, while there is some merit in allowing this, again, a server *MUST*
also do it because it may be on-link with the client (hence no relay) or
perhaps some relays will not chose to implement this.

So, if we wanted to explicitly allow this relay behavoir, we could say
that Relays *MAY* do this. In any case, servers *MUST* do it.

I'm also wondering if there are cases where a DHCPv6 server might give out
addressses that a relay has no knowledge of. For example, is there any
prohibition against giving out IPv4 (mapped) addresses? [Perhaps these
prefixes would also be advertised via Router Advertisements and thus we
are OK.]

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Thursday, July 19, 2001 5:54 AM
To: DHCPv6 discussion list
Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]


No, the relay need not to be stateful. It can just compare the
prefix of Source IP address of the client packet and has to compare
with the prefix of its interface in which it is received. It don't need
to parse the packet. It has to just see the sender's address, that's all.
But, this prevent the more and more processing that going to be
happened on the servers. I think, including this functionality in the relay
won't be a big problem.
~Vijay

> -----Original Message-----
> From: owner-dhcp-v6@bucknell.edu [mailto:owner-dhcp-v6@bucknell.edu]On
> Behalf Of Jim Bound
> Sent: Thursday, July 19, 2001 10:18 AM
> To: DHCPv6 discussion list
> Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]
>
>
> I think this is an option we can do later.  But I think we
> are asking to
> much of the relay.  The entire design goal has always been to keep the
> relay as stateless as possible.  If the relay knows which prefixes are
> good for a client and has to parse the addresses in a client packet I
> think I am against that as one who has worked on building a
> router this is
> a bit intense.  In fact now that I think about it I think
> this is simply
> not a good idea.
>
>
> /jim
>
>
> On Wed, 18 Jul 2001, Ted Lemon wrote:
>
> >
> > >   The format of "Error Code" option is not specified in
> the draft. It is
> > > needed to be included.
> >
> > I think it goes into the IA option, but you're right - it
> needs to be
> > clarified.
> >
> > >   It will be better, if this functionality can be
> incorporated in the
> > > agent,since, it is the only thing which knows well about
> the prefix in which
> > > the client message is received. And the advantage is, if
> this checking is
> > > done, this packet can be prevented from forwarding it to
> the multiple
> > > servers and save multiple processing time. The agent
> itself can send the
> > > NoPrefixMatch status directly to the client.
> >
> > Ooh, good point!   I think it would be good if the agent could do
> > this, although I have to admit that I am concerned that some people
> > who implement relay agents may not want to have to delve into the IA
> > to validate a packet.   I'm in favor of doing as you suggest, but I
> > suggest that we defer to the working group to see if any router
> > vendors have a problem with this.
> >
> > Also, the timing is a bit tight on making this change, and
> I wouldn't
> > blame the authors if they said "no, sorry, do this in a new
> draft."  I
> > think it's okay to make this optional, so doing it in a
> seperate draft
> > should be fine.
> >
> > >   If the client is receiving the error status as
> NoPrefixMatch error, what
> > > may be the reason other than client's plugging in to
> different subnet. I
> > > agree that, some roghe server can send this status, but,
> it can be prevented
> > > by authentication.
> >
> > The client may be mobile, and may be able to reach more than one
> > mobile access point.  The two access points may want to think of
> > themselves as seperate links, even though their physical link-layers
> > overlap.  I don't know how likely this is with existing technology,
> > but it's certainly been discussed with respect to 3G
> phones.  I think
> > it's important to leave the language open for this case.
> >
> >                            _MelloN_
> >
>
>

------_=_NextPart_001_01C1107D.D25DE5D0-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 14:52:20 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11871; Thu, 19 Jul 2001 14:52:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JIpdL29518; Thu, 19 Jul 2001 14:51:39 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JIpVL31885 for ; Thu, 19 Jul 2001 14:51:32 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6JIlDf16998; Thu, 19 Jul 2001 11:47:13 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6JIkZX00383; Thu, 19 Jul 2001 11:46:35 -0700 (MST) Message-Id: <200107191846.f6JIkZX00383@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from "Vijay Bhaskar A K" of "Thu, 19 Jul 2001 15:23:58 +0530." <005701c11038$bb8d57e0$2f290a0f@india.hp.com> Date: Thu, 19 Jul 2001 11:46:35 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > No, the relay need not to be stateful. It can just compare the > prefix of Source IP address of the client packet and has to compare > with the prefix of its interface in which it is received. It don't need > to parse the packet. It has to just see the sender's address, that's all. > But, this prevent the more and more processing that going to be > happened on the servers. I think, including this functionality in the relay > won't be a big problem. This is true; the only concern is that the relay may not have complete knowledge of the network configuration, and in that case it could cause some serious breakage. I like the idea of saving work by having the relay generate the Invalid Prefix result, but I think it should be approached with great caution. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 19 15:14:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18322; Thu, 19 Jul 2001 15:14:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JJBtL22962; Thu, 19 Jul 2001 15:11:55 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JJBfL13355 for ; Thu, 19 Jul 2001 15:11:41 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6JJ73f17041 for ; Thu, 19 Jul 2001 12:07:03 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6JJ6OX00469 for ; Thu, 19 Jul 2001 12:06:24 -0700 (MST) Message-Id: <200107191906.f6JJ6OX00469@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from Jim Bound of "Thu, 19 Jul 2001 12:39:57 -0400." Date: Thu, 19 Jul 2001 12:06:24 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > true. but the relay cannot see the addresses inside the IA option. > thats the addresses that will have to be nak'd not the source address. Hm, why not? You mean because of authentication? _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 19 15:39:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26964; Thu, 19 Jul 2001 15:39:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JJddL05805; Thu, 19 Jul 2001 15:39:39 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JJdWL04225 for ; Thu, 19 Jul 2001 15:39:32 -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 f6JJdVp26560 for ; Thu, 19 Jul 2001 14:39:31 -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 f6JJdVW15007 for ; Thu, 19 Jul 2001 14:39:31 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 19 14:39:31 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPK2ZG8>; Thu, 19 Jul 2001 14:39:31 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32E5@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: 15.2.1, Creation & Sending of Reconfigure-init messages Date: Thu, 19 Jul 2001 14:39:28 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1108A.86204E80" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C1108A.86204E80 Content-Type: text/plain; charset="iso-8859-1" I believe Section 15.2.1 of -19 needs some edits. It says: The server unicasts the Reconfigure-init message to one client. The server may unicast Reconfigure-init messages to more than one client concurrently; for example, to reliably reconfigure all known clients, the server will unicast a Reconfigure-init message to each client. Can we specify this a bit more tightly. What does "server unicasts" mean? Does that mean directly to the client? Well, consider that the server may not be able to do this. Why? 1) If the server did not assign any addresses to the client (just gave it configuration information), how does it know how to contact the client directly? All it may have is the client's link local address (and the relay's address if relayed). 2) If the server did assign addresses, it may be that those addresses are not of sufficient scope for the server to use to reach the client directly. Even if they are, which address should it use (this may be less of an issue but what if the preferred lifetimes have all elapsed and the client may have removed the address - or *MUST* a client retain the address until the valid lifetime expires?). Therefore, I would suggest that the text be revised to indicate HOW the server unicasts. I suggest the following text: The server unicasts to the client by using one of the following methods: 1) If the client is on one of the server's interfaces, the clients link local address is used. (The client's link local address must have been saved from a previous communication from the client.) 2) If the client has been assigned an address of sufficient scope for the server to use in communicating with it and that address is still preferred, this address MAY be used. 3) Otherwise, the Reconfigure-Init should be unicast to a relay agent (as a Relay-reply) and that relay will unicast it to the client's link local address. (The client's link local address and the relay's address must have been saved from a previous communication from the client; or a suiteable relay agent's address is known by some mechanism by the server.) BTW, there may be 4 (or more correctly, it should be 2.5) ... if the client has unicast a packet directly to the server (because of the Server Unicast Option, Section 18.10), the server could save that address and use it. However, if the server did not assign this address, it may have no information about the validity of that address and therefore I did not include it. > Bernie Volz > Chief Technical Officer - DNS & DHCP Development Unit > Ericsson, Inc. > Tel: +1-508-875-3162 > Fax: +1-508-875-3018 > Mobile: +1-617-513-9060 > mailto:bernie.volz@ericsson.com > > ------_=_NextPart_001_01C1108A.86204E80 Content-Type: text/html; charset="iso-8859-1" 15.2.1, Creation & Sending of Reconfigure-init messages

I believe Section 15.2.1 of -19 needs some edits.

It says:

   The server unicasts the Reconfigure-init message to one client.  The
   server may unicast Reconfigure-init messages to more than one client
   concurrently; for example, to reliably reconfigure all known clients,
   the server will unicast a Reconfigure-init message to each client.

Can we specify this a bit more tightly. What does "server unicasts"
mean? Does that mean directly to the client?

Well, consider that the server may not be able to do this. Why?
1) If the server did not assign any addresses to the client (just gave
it configuration information), how does it know how to contact the
client directly? All it may have is the client's link local address
(and the relay's address if relayed).
2) If the server did assign addresses, it may be that those addresses
are not of sufficient scope for the server to use to reach the client
directly. Even if they are, which address should it use (this may be
less of an issue but what if the preferred lifetimes have all elapsed
and the client may have removed the address - or *MUST* a client retain
the address until the valid lifetime expires?).

Therefore, I would suggest that the text be revised to indicate HOW
the server unicasts.

I suggest the following text:

  The server unicasts to the client by using one of the following
  methods:
  1) If the client is on one of the server's interfaces, the clients
  link local address is used. (The client's link local address must
  have been saved from a previous communication from the client.)
  2) If the client has been assigned an address of sufficient scope
  for the server to use in communicating with it and that address
  is still preferred, this address MAY be used.
  3) Otherwise, the Reconfigure-Init should be unicast to a relay
  agent (as a Relay-reply) and that relay will unicast it to the
  client's link local address. (The client's link local address and
  the relay's address must have been saved from a previous communication
  from the client; or a suiteable relay agent's address is known by
  some mechanism by the server.)

BTW, there may be 4 (or more correctly, it should be 2.5) ... if the
client has unicast a packet directly to the server (because of the
Server Unicast Option, Section 18.10), the server could save that
address and use it. However, if the server did not assign this address,
it may have no information about the validity of that address and
therefore I did not include it.

Bernie Volz
Chief Technical Officer - DNS & DHCP Development Unit
Ericsson, Inc.
Tel: +1-508-875-3162
Fax: +1-508-875-3018
Mobile: +1-617-513-9060
mailto:bernie.volz@ericsson.com


------_=_NextPart_001_01C1108A.86204E80-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 16:03:16 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA03748; Thu, 19 Jul 2001 16:03:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JK3PL09724; Thu, 19 Jul 2001 16:03:25 -0400 (EDT) Received: from rdroms-w2k.bucknell.edu (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JK3CL01163; Thu, 19 Jul 2001 16:03:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20010719155118.038ee3b8@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jul 2001 15:59:11 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] Cc: DHCPv6 discussion list In-Reply-To: <200107191846.f6JIkZX00383@grosse.bisbee.fugue.com> References: <005701c11038$bb8d57e0$2f290a0f@india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I agree with Ted - my intuition is that allowing the relay to do IA prefix checking is potentially dangerous. To me, it introduces the requirement that we push detailed knowledge of network configuration out across lots of devices, where misconfiguration can cause significant problems for DHCP clients. Even if we suppose that the relay can dive into other local information on the router, that information may not be complete enough to correctly make decisions about prefix validity. - Ralph At 11:46 AM 7/19/2001 -0700, Ted Lemon wrote: > > No, the relay need not to be stateful. It can just compare the > > prefix of Source IP address of the client packet and has to compare > > with the prefix of its interface in which it is received. It don't need > > to parse the packet. It has to just see the sender's address, that's all. > > But, this prevent the more and more processing that going to be > > happened on the servers. I think, including this functionality in the relay > > won't be a big problem. > >This is true; the only concern is that the relay may not have complete >knowledge of the network configuration, and in that case it could >cause some serious breakage. I like the idea of saving work by >having the relay generate the Invalid Prefix result, but I think it >should be approached with great caution. > > _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 19 16:21:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA07098; Thu, 19 Jul 2001 16:21:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JKKtL12258; Thu, 19 Jul 2001 16:20:55 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JKKdL19306 for ; Thu, 19 Jul 2001 16:20: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 f6JKKcp18423 for ; Thu, 19 Jul 2001 15:20:38 -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 f6JKKch14660 for ; Thu, 19 Jul 2001 15:20:38 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 19 15:20:35 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPK273N>; Thu, 19 Jul 2001 15:20:34 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32E6@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 19 Jul 2001 15:20:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11090.4448A0B0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11090.4448A0B0 Content-Type: text/plain; charset="iso-8859-1" I third this (agree with Ted and Ralph). -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Thursday, July 19, 2001 3:59 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] I agree with Ted - my intuition is that allowing the relay to do IA prefix checking is potentially dangerous. To me, it introduces the requirement that we push detailed knowledge of network configuration out across lots of devices, where misconfiguration can cause significant problems for DHCP clients. Even if we suppose that the relay can dive into other local information on the router, that information may not be complete enough to correctly make decisions about prefix validity. - Ralph At 11:46 AM 7/19/2001 -0700, Ted Lemon wrote: > > No, the relay need not to be stateful. It can just compare the > > prefix of Source IP address of the client packet and has to compare > > with the prefix of its interface in which it is received. It don't need > > to parse the packet. It has to just see the sender's address, that's all. > > But, this prevent the more and more processing that going to be > > happened on the servers. I think, including this functionality in the relay > > won't be a big problem. > >This is true; the only concern is that the relay may not have complete >knowledge of the network configuration, and in that case it could >cause some serious breakage. I like the idea of saving work by >having the relay generate the Invalid Prefix result, but I think it >should be approached with great caution. > > _MelloN_ ------_=_NextPart_001_01C11090.4448A0B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

I third this (agree with Ted and Ralph).

-----Original Message-----
From: Ralph Droms [mailto:droms@bucknell.edu]=
Sent: Thursday, July 19, 2001 3:59 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft = Changes]


I agree with Ted - my intuition is that allowing the = relay to do IA prefix
checking is potentially dangerous.  To me, it = introduces the requirement
that we push detailed knowledge of network = configuration out across lots of
devices, where misconfiguration can cause = significant problems for DHCP
clients.  Even if we suppose that the relay can = dive into other local
information on the router, that information may not = be complete enough to
correctly make decisions about prefix = validity.

- Ralph

At 11:46 AM 7/19/2001 -0700, Ted Lemon wrote:

> > No, the relay need not to be stateful. It = can just compare the
> > prefix of Source IP address of the client = packet and has to compare
> > with the prefix of its interface in which = it is received. It don't need
> > to parse the packet. It has to just see = the sender's address, that's all.
> > But, this prevent the more and more = processing that going to be
> > happened on the servers. I think, = including this functionality in the relay
> > won't be a big problem.
>
>This is true; the only concern is that the relay = may not have complete
>knowledge of the network configuration, and in = that case it could
>cause some serious breakage.   I like = the idea of saving work by
>having the relay generate the Invalid Prefix = result, but I think it
>should be approached with great caution.
>
>          = ;            = ;          _MelloN_

------_=_NextPart_001_01C11090.4448A0B0-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 16:28:29 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08447; Thu, 19 Jul 2001 16:28:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JKSrL10772; Thu, 19 Jul 2001 16:28:53 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JKSnL04156 for ; Thu, 19 Jul 2001 16:28:49 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6JKSX528431 for ; Thu, 19 Jul 2001 15:28:33 -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 f6JKSWh16979 for ; Thu, 19 Jul 2001 15:28:33 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 19 15:28:32 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPK2793>; Thu, 19 Jul 2001 15:28:31 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32E7@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: 18.10, Server Unicast Option Date: Thu, 19 Jul 2001 15:28:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11091.5FF700D0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11091.5FF700D0 Content-Type: text/plain; charset="iso-8859-1" After a few private exchanges with Ted, while there are still many open issues with the client unicasting to the server (such as how the server replies), how about we: - At a minimum, remove Confirm from the list of messages in Section 18.10. It does not belong because it is NOT directed to a single server but instead to ANY server. (See section 14.3.2, "The client sets the "server-address" field to 0.) The other messages (Request, Renew, Release, and Decline) are all directed to a single server. - At a maximum, remove this section (option) altogether for now - it can always be added as a feature in a later revision (new option). This means we don't have to figure out how a server returns a reply to a unicast message. (Though it may tie in closely to what I've suggested as a clarificaton to Section 15.2.1 on unicasting Reconfigure-inits.) > Bernie Volz > Chief Technical Officer - DNS & DHCP Development Unit > Ericsson, Inc. > Tel: +1-508-875-3162 > Fax: +1-508-875-3018 > Mobile: +1-617-513-9060 > mailto:bernie.volz@ericsson.com > > ------_=_NextPart_001_01C11091.5FF700D0 Content-Type: text/html; charset="iso-8859-1" 18.10, Server Unicast Option

After a few private exchanges with Ted, while there are still many
open issues with the client unicasting to the server (such as how
the server replies), how about we:

- At a minimum, remove Confirm from the list of messages in Section
18.10. It does not belong because it is NOT directed to a single
server but instead to ANY server. (See section 14.3.2, "The client
sets the "server-address" field to 0.) The other messages (Request,
Renew, Release, and Decline) are all directed to a single server.

- At a maximum, remove this section (option) altogether for now - it
can always be added as a feature in a later revision (new option).
This means we don't have to figure out how a server returns a reply
to a unicast message. (Though it may tie in closely to what I've
suggested as a clarificaton to Section 15.2.1 on unicasting
Reconfigure-inits.)


Bernie Volz
Chief Technical Officer - DNS & DHCP Development Unit
Ericsson, Inc.
Tel: +1-508-875-3162
Fax: +1-508-875-3018
Mobile: +1-617-513-9060
mailto:bernie.volz@ericsson.com


------_=_NextPart_001_01C11091.5FF700D0-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 16:31:08 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA08936; Thu, 19 Jul 2001 16:31:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JKVUL07776; Thu, 19 Jul 2001 16:31:30 -0400 (EDT) Received: from rdroms-w2k.bucknell.edu (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JKVML10998; Thu, 19 Jul 2001 16:31:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20010719162351.038ee2b8@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jul 2001 16:25:06 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B32CD@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Off the top of my head, the text Bernie cites in the "Server Unicast Option" is in error. Confirm messages should always be multicast because the client has no way to determine if any of its source addresses are valid. - Ralph At 06:10 PM 7/18/2001 -0500, Bernie Volz (EUD) wrote: >OK. I understand your point. > >BTW, I was originally thinking that only the Reply to a Confirm message >would do this prefix checking and hence return a NoPrefixMatch status. > >But, even that would not have been safe. Note that text for the "Server >Unicast Option": > > "This option is used by a server to send to a client to inform the > client it can send a Request, Renew, Confirm, Release, and Decline > by unicasting directly to the server instead of the All DHCPv6 > Agents > multicast adress as an optimization." > >I think we need to change this OR we need to add a statement to the prefix >checking that prohibits it if the server can't tell where the client is. > >Now, this raises the nasty issue of if the client unicasts a message, how >does the server reply to it (I already raised this issue). One solution is >to use the IPv6 Source Address - but that has problems since then why not >always use it? Another is for the server to save information on how to reach >the client (which it might need to do anyway to send it Reconfigure-Inits?) >via a Relay (or directly if on-link). But this is messy and what if the >client has moved (I guess you could argue then it might not need to be >Reconfigured)? > >- Bernie > >-----Original Message----- >From: Ted Lemon [mailto:mellon@nominum.com] >Sent: Wednesday, July 18, 2001 6:51 PM >To: DHCPv6 discussion list >Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > >IIRC = If I Recall Correctly > > > What difference does that make? A Release or Decline can be unicast as > well > > (if the client has another address - in a different IA - than what it is > > releasing and the server has told the client it can unicast). > >The server doesn't need to make a determination as to what link the >client is on in the case of Release. Decline probably does need to >go through the relay. > > > Why does *HOW* the packet was sent make any difference? Remember, we're > > dealing with MANY addresses so an individual message's IAs have nothing to > > do with other IAs (and hence addresses) that client has. > >If the packet goes through a relay, the relay can say on which link >the packet was received. If it is unicast through a router, that is >not the case. In the case where it is unicast through a router, >therefore, it doesn't make sense to check the prefix - we can only >assume that it is correct. In the case where it is not correct, the >packet probably wouldn't have gotten to us, and even if it did somehow >get to us, we couldn't reply, because our reply will go to the link >where the prefix *is* valid. > > _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 19 16:43:08 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10503; Thu, 19 Jul 2001 16:43:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JKhYL24842; Thu, 19 Jul 2001 16:43:34 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JKhJL07879 for ; Thu, 19 Jul 2001 16:43:19 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA27236 for ; Thu, 19 Jul 2001 16:43:00 -0400 (EDT) Message-Id: <4.3.2.7.2.20010719163903.0383d140@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jul 2001 16:41:43 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: 18.10, Server Unicast Option In-Reply-To: <66F66129A77AD411B76200508B65AC697B32E7@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie - can you be more specific about suggestion #2? Are you referring to the problem of replying to unicast messages when the client has used an invalid source address? - Ralph At 03:28 PM 7/19/2001 -0500, Bernie Volz (EUD) wrote: >After a few private exchanges with Ted, while there are still many >open issues with the client unicasting to the server (such as how >the server replies), how about we: > >- At a minimum, remove Confirm from the list of messages in Section >18.10. It does not belong because it is NOT directed to a single >server but instead to ANY server. (See section 14.3.2, "The client >sets the "server-address" field to 0.) The other messages (Request, >Renew, Release, and Decline) are all directed to a single server. > >- At a maximum, remove this section (option) altogether for now - it >can always be added as a feature in a later revision (new option). >This means we don't have to figure out how a server returns a reply >to a unicast message. (Though it may tie in closely to what I've >suggested as a clarificaton to Section 15.2.1 on unicasting >Reconfigure-inits.) > >Bernie Volz >Chief Technical Officer - DNS & DHCP Development Unit >Ericsson, Inc. >Tel: +1-508-875-3162 >Fax: +1-508-875-3018 >Mobile: +1-617-513-9060 >mailto:bernie.volz@ericsson.com From owner-dhcp-v6@bucknell.edu Thu Jul 19 16:53:52 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12000; Thu, 19 Jul 2001 16:53:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JKsBL02405; Thu, 19 Jul 2001 16:54:11 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JKrqL17533 for ; Thu, 19 Jul 2001 16:53:52 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6JKra509602 for ; Thu, 19 Jul 2001 15:53: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 f6JKraW23813 for ; Thu, 19 Jul 2001 15:53:36 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 19 15:53:35 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPK20CN>; Thu, 19 Jul 2001 15:53:35 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32E9@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: 18.10, Server Unicast Option Date: Thu, 19 Jul 2001 15:53:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11094.E0CA8EE0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11094.E0CA8EE0 Content-Type: text/plain; charset="iso-8859-1" Ralph: No where in the -19 text does it say to ever use the IPv6 Source Address to send messages. I thought the idea was NOT to require this kind of data - we wanted the messages themselves to pretty much contain all the server needed? The text on sending the reply says unicast to relay (if Relay-Forward received) else unicast it to the "client-link-local-address". Perhaps we should change this to unicast to relay (if Relay-Forward received) else unicast it to the IPv6 source address of the client's message. In which case, what's the client-link-local-address needed for (except when relayed, in which case that can be part of the Relay-Forward/Relay-Reply). If the IPv6 Source Address is used, yes there may be an issue if the client doesn't provide an address of sufficent scope. But, I wasn't really worried about that since that isn't really the server's fault. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, July 19, 2001 4:42 PM To: DHCPv6 discussion list Subject: Re: 18.10, Server Unicast Option Bernie - can you be more specific about suggestion #2? Are you referring to the problem of replying to unicast messages when the client has used an invalid source address? - Ralph At 03:28 PM 7/19/2001 -0500, Bernie Volz (EUD) wrote: >After a few private exchanges with Ted, while there are still many >open issues with the client unicasting to the server (such as how >the server replies), how about we: > >- At a minimum, remove Confirm from the list of messages in Section >18.10. It does not belong because it is NOT directed to a single >server but instead to ANY server. (See section 14.3.2, "The client >sets the "server-address" field to 0.) The other messages (Request, >Renew, Release, and Decline) are all directed to a single server. > >- At a maximum, remove this section (option) altogether for now - it >can always be added as a feature in a later revision (new option). >This means we don't have to figure out how a server returns a reply >to a unicast message. (Though it may tie in closely to what I've >suggested as a clarificaton to Section 15.2.1 on unicasting >Reconfigure-inits.) > >Bernie Volz >Chief Technical Officer - DNS & DHCP Development Unit >Ericsson, Inc. >Tel: +1-508-875-3162 >Fax: +1-508-875-3018 >Mobile: +1-617-513-9060 >mailto:bernie.volz@ericsson.com ------_=_NextPart_001_01C11094.E0CA8EE0 Content-Type: text/html; charset="iso-8859-1" RE: 18.10, Server Unicast Option

Ralph:

No where in the -19 text does it say to ever use the IPv6 Source Address
to send messages. I thought the idea was NOT to require this kind
of data - we wanted the messages themselves to pretty much contain all
the server needed?

The text on sending the reply says unicast to relay (if Relay-Forward
received) else unicast it to the "client-link-local-address".

Perhaps we should change this to unicast to relay (if Relay-Forward
received) else unicast it to the IPv6 source address of the client's
message. In which case, what's the client-link-local-address needed
for (except when relayed, in which case that can be part of the
Relay-Forward/Relay-Reply).

If the IPv6 Source Address is used, yes there may be an issue if the
client doesn't provide an address of sufficent scope. But, I wasn't
really worried about that since that isn't really the server's fault.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, July 19, 2001 4:42 PM
To: DHCPv6 discussion list
Subject: Re: 18.10, Server Unicast Option


Bernie - can you be more specific about suggestion #2?  Are you referring
to the problem of replying to unicast messages when the client has used an
invalid source address?

- Ralph

At 03:28 PM 7/19/2001 -0500, Bernie Volz (EUD) wrote:

>After a few private exchanges with Ted, while there are still many
>open issues with the client unicasting to the server (such as how
>the server replies), how about we:
>
>- At a minimum, remove Confirm from the list of messages in Section
>18.10. It does not belong because it is NOT directed to a single
>server but instead to ANY server. (See section 14.3.2, "The client
>sets the "server-address" field to 0.) The other messages (Request,
>Renew, Release, and Decline) are all directed to a single server.
>
>- At a maximum, remove this section (option) altogether for now - it
>can always be added as a feature in a later revision (new option).
>This means we don't have to figure out how a server returns a reply
>to a unicast message. (Though it may tie in closely to what I've
>suggested as a clarificaton to Section 15.2.1 on unicasting
>Reconfigure-inits.)
>
>Bernie Volz
>Chief Technical Officer - DNS & DHCP Development Unit
>Ericsson, Inc.
>Tel: +1-508-875-3162
>Fax: +1-508-875-3018
>Mobile: +1-617-513-9060
><mailto:bernie.volz@ericsson.com>mailto:bernie.volz@ericsson.com

------_=_NextPart_001_01C11094.E0CA8EE0-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 16:58:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12587; Thu, 19 Jul 2001 16:58:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JKwsL19421; Thu, 19 Jul 2001 16:58:54 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JKwkL19638 for ; Thu, 19 Jul 2001 16:58:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA28994; Thu, 19 Jul 2001 16:58:30 -0400 (EDT) Message-Id: <4.3.2.7.2.20010719164251.03868f98@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 19 Jul 2001 16:54:46 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B32BE@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 10:01 AM 7/18/2001 -0500, Bernie Volz (EUD) wrote: >Ralph, et al: > >Here's proposed text for dealing with the DHCPNACK issue. Ted and I >exchanged messages on this text and I've used most of Ted's feedback >here - though Ted has not seen this latest round. > >1) Add to section 7.4.2: > > |NoPrefixMatch_|26______|_An addr in IA not valid for prefix_|_ OK >2) Add to 14.4.1, 14.4.2, 14.4.4: > > If the server finds that the prefix on one or more IP addresses in > any IA in the {Request,Confirm,Rebind} message is not a valid > prefix for the link to which the client is connected, the server > MUST send an NoPrefixMatch status in the IA status field for that > IA in the DHCP Reply message. > > [Should we include Renew in the message list and add to 14.4.3?] Yes, I think we can include Renew. I suggest the following change to the first sentence: If the server can determine that the prefix on any of the IP addresses in an IA in the XXX message is not a valid prefix for the link to which the interface from which the message was received is connected, the server MUST send [...] >3) Add to Section 14.3.5. (Receipt of Reply message in response > to a Request, Confirm, Renew or Rebind message): > > When the client receives a NoPrefixMatch error status in the IA status > field of a Reply to a Confirm message, the client MUST make a > determination as to whether it has moved to a different link. If the > client is unable to make such a determination it MUST assume that it > has moved to a new link. In this case the client MAY discard the IA > that received the NoPrefixMatch status, or may retain it as long as > the addresses in the IA continue to be valid. Why should the client make a determination about moving to a new link? In fact, how can it make that determination at this point, which is, I think, after the point at which the client may have received an event from its interface about loss of carrier, change of access point, etc.? I suggest the following text: When the client receives a NoPrefixMatch error status in the IA status field of a Reply to a Confirm (what about Request and Rebind?) message, the client MUST not use any of the addresses in the IA. Regarding your last sentence - what does it mean to "discard" an IA? >4) Add somewhere (perhaps in 18.3, Identity Association Option): > > The client MUST NOT send any address in an IA once that address' > valid lifetime has expired. OK. - Ralph From owner-dhcp-v6@bucknell.edu Thu Jul 19 17:12:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14513; Thu, 19 Jul 2001 17:12:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JLCAL10514; Thu, 19 Jul 2001 17:12:10 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JLBuL18555 for ; Thu, 19 Jul 2001 17:11:58 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6JLBe516777 for ; Thu, 19 Jul 2001 16:11:40 -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 f6JLBeh00971 for ; Thu, 19 Jul 2001 16:11:40 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 19 16:11:40 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKJAMB>; Thu, 19 Jul 2001 16:11:39 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32EA@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 19 Jul 2001 16:11:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11097.6580CAD0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11097.6580CAD0 Content-Type: text/plain; charset="iso-8859-1" See below - for clarity, my comments prefixed by BV>. I also cut those items where I have no comments. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, July 19, 2001 4:55 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] At 10:01 AM 7/18/2001 -0500, Bernie Volz (EUD) wrote: >2) Add to 14.4.1, 14.4.2, 14.4.4: > > If the server finds that the prefix on one or more IP addresses in > any IA in the {Request,Confirm,Rebind} message is not a valid > prefix for the link to which the client is connected, the server > MUST send an NoPrefixMatch status in the IA status field for that > IA in the DHCP Reply message. > > [Should we include Renew in the message list and add to 14.4.3?] Yes, I think we can include Renew. I suggest the following change to the first sentence: If the server can determine that the prefix on any of the IP addresses in an IA in the XXX message is not a valid prefix for the link to which the interface from which the message was received is connected, the server MUST send [...] BV> Fine by me. >3) Add to Section 14.3.5. (Receipt of Reply message in response > to a Request, Confirm, Renew or Rebind message): > > When the client receives a NoPrefixMatch error status in the IA status > field of a Reply to a Confirm message, the client MUST make a > determination as to whether it has moved to a different link. If the > client is unable to make such a determination it MUST assume that it > has moved to a new link. In this case the client MAY discard the IA > that received the NoPrefixMatch status, or may retain it as long as > the addresses in the IA continue to be valid. Why should the client make a determination about moving to a new link? In fact, how can it make that determination at this point, which is, I think, after the point at which the client may have received an event from its interface about loss of carrier, change of access point, etc.? I suggest the following text: When the client receives a NoPrefixMatch error status in the IA status field of a Reply to a Confirm (what about Request and Rebind?) message, the client MUST not use any of the addresses in the IA. BV> For Confirm, this sounds fine to me. BV> Can this happen on a Request? No addresses in the IA. So, not BV> possible? BV> For Renew, this sounds fine as well (since the original server is BV> responding). BV> For Rebind, I think this would be OK as well but we may want to BV> factor in the level of trust to prevent denial of service attacks. BV> BV> Note also that for Confirm and Rebind, many servers could respond. BV> It may be advisable for a client to wait a short time after receiving BV> the NoPrefixMatch to see what other servers have to say about the BV> addresses. If a client gets multiple NoPrefixMatch, it may believe it. BV> If a client gets multiple confusing responses, what should it do? BV> (Perhaps that a reason not to wait!) BV> Again, the level of trust may be factored in to the decision. Regarding your last sentence - what does it mean to "discard" an IA? BV> Discarding an IA means to completely and utterly remove it from the BV> client's memory. It drops any reference to the addresses in the IA. BV> Some clients may have limited resources and therefore feel that there BV> is no reason to keep something that appears to be useless (for now BV> at least). These addresses are discard although their valid and/or BV> preferred lifetimes have not yet expired. ------_=_NextPart_001_01C11097.6580CAD0 Content-Type: text/html; charset="iso-8859-1" RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

See below - for clarity, my comments prefixed by BV>. I also cut
those items where I have no comments.

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, July 19, 2001 4:55 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]


At 10:01 AM 7/18/2001 -0500, Bernie Volz (EUD) wrote:

>2) Add to 14.4.1, 14.4.2, 14.4.4:
>
>    If the server finds that the prefix on one or more IP addresses in
>    any IA in the {Request,Confirm,Rebind} message is not a valid
>    prefix for the link to which the client is connected, the server
>    MUST send an NoPrefixMatch status in the IA status field for that
>    IA in the DHCP Reply message.
>
>    [Should we include Renew in the message list and add to 14.4.3?]

Yes, I think we can include Renew.  I suggest the following change to the
first sentence:  If the server can determine that the prefix on any of the
IP addresses in an IA in the XXX message is not a valid prefix for the link
to which the interface from which the message was received is connected,
the server MUST send [...]

BV> Fine by me.


>3) Add to Section 14.3.5. (Receipt of Reply message in response
>    to a Request, Confirm, Renew or Rebind message):
>
>    When the client receives a NoPrefixMatch error status in the IA status
>    field of a Reply to a Confirm message, the client MUST make a
>    determination as to whether it has moved to a different link.  If the
>    client is unable to make such a determination it MUST assume that it
>    has moved to a new link.  In this case the client MAY discard the IA
>    that received the NoPrefixMatch status, or may retain it as long as
>    the addresses in the IA continue to be valid.

Why should the client make a determination about moving to a new link?  In
fact, how can it make that determination at this point, which is, I think,
after the point at which the client may have received an event from its
interface about loss of carrier, change of access point, etc.?  I suggest
the following text:

When the client receives a NoPrefixMatch error status in the IA status
field of a Reply to a Confirm (what about Request and Rebind?) message, the
client MUST not use any of the addresses in the IA.

BV> For Confirm, this sounds fine to me.
BV> Can this happen on a Request? No addresses in the IA. So, not
BV> possible?
BV> For Renew, this sounds fine as well (since the original server is
BV> responding).
BV> For Rebind, I think this would be OK as well but we may want to
BV> factor in the level of trust to prevent denial of service attacks.
BV>
BV> Note also that for Confirm and Rebind, many servers could respond.
BV> It may be advisable for a client to wait a short time after receiving
BV> the NoPrefixMatch to see what other servers have to say about the
BV> addresses. If a client gets multiple NoPrefixMatch, it may believe it.
BV> If a client gets multiple confusing responses, what should it do?
BV> (Perhaps that a reason not to wait!)
BV> Again, the level of trust may be factored in to the decision.

Regarding your last sentence - what does it mean to "discard" an IA?

BV> Discarding an IA means to completely and utterly remove it from the
BV> client's memory. It drops any reference to the addresses in the IA.
BV> Some clients may have limited resources and therefore feel that there
BV> is no reason to keep something that appears to be useless (for now
BV> at least). These addresses are discard although their valid and/or
BV> preferred lifetimes have not yet expired.

------_=_NextPart_001_01C11097.6580CAD0-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 17:22:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15851; Thu, 19 Jul 2001 17:22:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JLMML31806; Thu, 19 Jul 2001 17:22:22 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JLM9L08926 for ; Thu, 19 Jul 2001 17:22:09 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6JLHsf17282 for ; Thu, 19 Jul 2001 14:17:54 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6JLH6X00699 for ; Thu, 19 Jul 2001 14:17:06 -0700 (MST) Message-Id: <200107192117.f6JLH6X00699@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from Ralph Droms of "Thu, 19 Jul 2001 16:54:46 -0400." <4.3.2.7.2.20010719164251.03868f98@mail.bucknell.edu> Date: Thu, 19 Jul 2001 14:17:06 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Why should the client make a determination about moving to a new link? In > fact, how can it make that determination at this point, which is, I think, > after the point at which the client may have received an event from its > interface about loss of carrier, change of access point, etc.? I suggest > the following text: This is the multiple overlapping link layers problem - a 3G cell phone that is able to contact two different cell towers. The client in this case has information that the server does not have, and is probably talking to more than one server, and therefore is in a position to know that it can continue to use its addresses. The case where this is most likely is when the client broadcast a Confirm message and gets a response from the server for each cell tower, one of which says "stop using those addresses" and the other of which says "go ahead and keep using them." That is why the text gives the client the option of determining that it has not changed link layers. The way the text is worded, there's an easy out for implementors who have no clue how to make such a determination, which I suspect would be most implementors. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 19 17:24:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16156; Thu, 19 Jul 2001 17:24:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JLOlL06096; Thu, 19 Jul 2001 17:24:47 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JLOZL10375 for ; Thu, 19 Jul 2001 17:24:35 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6JLOK521294 for ; Thu, 19 Jul 2001 16:24:20 -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 f6JLOKh04286 for ; Thu, 19 Jul 2001 16:24:20 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 19 16:24:19 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKJBHQ>; Thu, 19 Jul 2001 16:24:19 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32EC@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: Issues with 14.3.1 Date: Thu, 19 Jul 2001 16:24:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11099.2AC26C30" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11099.2AC26C30 Content-Type: text/plain; charset="iso-8859-1" In Section 14.3.1 of -19 (Creation and Sending of Request Messages)] it says: "If a client has no valid IPv6 addresses of sufficient scope to communicate with a DHCP server, it may send a Request to obtain new addresses." - What difference does it make even if a client has addresses of sufficient scope to communicate with a server? Seems to me we should just say "If a client needs to obtain addresses, it may send a Request to obtain [new] addresses." - What exactly is meant by "new" addresses? I understand that the client should not use a Request message to "renew" addresses, but must these be "new"? Suppose we have a client that is very simple and has no permanent storage. So, each time it boots it simply does a Request on IAID 0. If the client reboots, it will do the same (since it does not remember anything about old "leases"). Now, does this mean that the server MUST NOT allocate the client the same address on each Request? Or is this a server policy issue? The text in Section 14.4.1 isn't of any help. If the server does allocate new addresses, what does it do with the old addresses (put them on an unusable list until the valid lifetime expires)? Again, perhaps this is considered a server implementation issue? My own feeling is that the server should give out the "old" addresses if they are still valid (addresses with a preferred lifetime of 0 should likely not be included because as this is not a Renew, those addresses really have no value to this client.) The server should, of course, consider giving the client new (more) addresses as needed (either to replace those no longer valid or per whatever policy the server has). - Bernie ------_=_NextPart_001_01C11099.2AC26C30 Content-Type: text/html; charset="iso-8859-1" Issues with 14.3.1

In Section 14.3.1 of -19 (Creation and Sending of Request Messages)]
it says:

"If a client has no valid IPv6 addresses of sufficient scope to
communicate with a DHCP server, it may send a Request to obtain
new addresses."

- What difference does it make even if a client has addresses of
sufficient scope to communicate with a server? Seems to me we should
just say "If a client needs to obtain addresses, it may send a
Request to obtain [new] addresses."

- What exactly is meant by "new" addresses? I understand that the
client should not use a Request message to "renew" addresses, but
must these be "new"?

Suppose we have a client that is very simple and has no permanent
storage. So, each time it boots it simply does a Request on IAID 0.
If the client reboots, it will do the same (since it does not
remember anything about old "leases"). Now, does this mean that the
server MUST NOT allocate the client the same address on each
Request? Or is this a server policy issue? The text in Section
14.4.1 isn't of any help. If the server does allocate new
addresses, what does it do with the old addresses (put them on an
unusable list until the valid lifetime expires)?

Again, perhaps this is considered a server implementation issue?

My own feeling is that the server should give out the "old" addresses
if they are still valid (addresses with a preferred lifetime of 0
should likely not be included because as this is not a Renew, those
addresses really have no value to this client.) The server should,
of course, consider giving the client new (more) addresses as needed
(either to replace those no longer valid or per whatever policy the
server has).

- Bernie

------_=_NextPart_001_01C11099.2AC26C30-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 18:53:19 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA06479; Thu, 19 Jul 2001 18:53:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6JMqoL29776; Thu, 19 Jul 2001 18:52:50 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6JMqdL32644 for ; Thu, 19 Jul 2001 18:52:39 -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 f6JMqcp17928 for ; Thu, 19 Jul 2001 17:52:38 -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 f6JMqcW09687 for ; Thu, 19 Jul 2001 17:52:38 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 19 17:52:38 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKJG4H>; Thu, 19 Jul 2001 17:52:37 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32F1@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: 18.10, Server Unicast Option Date: Thu, 19 Jul 2001 17:52:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C110A5.80D18EB0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C110A5.80D18EB0 Content-Type: text/plain; charset="iso-8859-1" I would be happy if the text did say to use the IPv6 Source Address (unless Relay-Forward message was received - though I again see no reason why that can't be used to send the Relay-Reply to the Relay as well). If we do this, why not drop the client-link-local-address from the message formats. It won't be needed anymore. Though of course we will need to change the Relay-Forward and Relay-Reply message formats to put the client-link-local-address (or client-reply-address) such that the relay has the information it needs to get the packet to the client. Note that we do need the relay-address in the Relay- Forward header, but that's to tell the server which link the client is on only and doesn't need to be used by the server to send the Relay-Reply. We also need to make it clear that when a server receives a client packet (when not via the Relay) it can tell where the client is as follows: - If the IPv6 Source Address is a link-local address, it is on the interface the packet was received from. - Otherwise, the IPv6 Source Address should tell the server where the client is. This has lots of benefits though it may require the server to know more about the network than it would need to just to assign addresses. So, we need to add "If the IPv6 Source Address' prefix is not known by the server, the server MUST NOT make any assumptions about the link the client is on." This then has implications as to how it would process each client request type if it doesn't know the link (we had this anyway in the -19 draft when packets were unicast to the server, so this is nothing new). I believe in the past there was some concern that you couldn't always get the IP source address for UDP packets. Recvfrom does provide this but apparently only some implementations it was broken? or could be used to get other information that was more important for the DHCP server (such as the receiving interface?). These are hopefully IPv4 legacy issues and don't apply to IPv6 with its much improved socket API. And DHCPv6 servers will be using that - not the IPv4 interface. DOES *ANYONE* ON THE MAILING LIST HAVE ANY ISSUE WITH DOING THIS CHANGE? - Bernie PS: In terms of unicasting the Reconfigure-Init, I think the server will still need to save some information (such as the Relay address and client's link local address to give to the relay) or the client's link-local address (if on link). But, it still should have all it needs. -----Original Message----- From: Bernie Volz (EUD) Sent: Thursday, July 19, 2001 4:54 PM To: 'dhcp-v6@bucknell.edu' Subject: RE: 18.10, Server Unicast Option Ralph: No where in the -19 text does it say to ever use the IPv6 Source Address to send messages. I thought the idea was NOT to require this kind of data - we wanted the messages themselves to pretty much contain all the server needed? The text on sending the reply says unicast to relay (if Relay-Forward received) else unicast it to the "client-link-local-address". Perhaps we should change this to unicast to relay (if Relay-Forward received) else unicast it to the IPv6 source address of the client's message. In which case, what's the client-link-local-address needed for (except when relayed, in which case that can be part of the Relay-Forward/Relay-Reply). If the IPv6 Source Address is used, yes there may be an issue if the client doesn't provide an address of sufficent scope. But, I wasn't really worried about that since that isn't really the server's fault. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, July 19, 2001 4:42 PM To: DHCPv6 discussion list Subject: Re: 18.10, Server Unicast Option Bernie - can you be more specific about suggestion #2? Are you referring to the problem of replying to unicast messages when the client has used an invalid source address? - Ralph At 03:28 PM 7/19/2001 -0500, Bernie Volz (EUD) wrote: >After a few private exchanges with Ted, while there are still many >open issues with the client unicasting to the server (such as how >the server replies), how about we: > >- At a minimum, remove Confirm from the list of messages in Section >18.10. It does not belong because it is NOT directed to a single >server but instead to ANY server. (See section 14.3.2, "The client >sets the "server-address" field to 0.) The other messages (Request, >Renew, Release, and Decline) are all directed to a single server. > >- At a maximum, remove this section (option) altogether for now - it >can always be added as a feature in a later revision (new option). >This means we don't have to figure out how a server returns a reply >to a unicast message. (Though it may tie in closely to what I've >suggested as a clarificaton to Section 15.2.1 on unicasting >Reconfigure-inits.) > >Bernie Volz >Chief Technical Officer - DNS & DHCP Development Unit >Ericsson, Inc. >Tel: +1-508-875-3162 >Fax: +1-508-875-3018 >Mobile: +1-617-513-9060 >mailto:bernie.volz@ericsson.com ------_=_NextPart_001_01C110A5.80D18EB0 Content-Type: text/html; charset="iso-8859-1" RE: 18.10, Server Unicast Option

I would be happy if the text did say to use the IPv6 Source
Address (unless Relay-Forward message was received - though I
again see no reason why that can't be used to send the
Relay-Reply to the Relay as well).

If we do this, why not drop the client-link-local-address from
the message formats. It won't be needed anymore. Though of course
we will need to change the Relay-Forward and Relay-Reply message
formats to put the client-link-local-address (or client-reply-address)
such that the relay has the information it needs to get the packet
to the client. Note that we do need the relay-address in the Relay-
Forward header, but that's to tell the server which link the
client is on only and doesn't need to be used by the server to
send the Relay-Reply.

We also need to make it clear that when a server receives a client
packet (when not via the Relay) it can tell where the client is as
follows:
- If the IPv6 Source Address is a link-local address, it is on
the interface the packet was received from.
- Otherwise, the IPv6 Source Address should tell the server where
the client is. This has lots of benefits though it may require
the server to know more about the network than it would need to
just to assign addresses. So, we need to add "If the IPv6 Source
Address' prefix is not known by the server, the server MUST NOT
make any assumptions about the link the client is on." This then
has implications as to how it would process each client request
type if it doesn't know the link (we had this anyway in the -19
draft when packets were unicast to the server, so this is nothing
new).


I believe in the past there was some concern that you couldn't
always get the IP source address for UDP packets. Recvfrom does
provide this but apparently only some implementations it was
broken? or could be used to get other information that was more
important for the DHCP server (such as the receiving interface?).
These are hopefully IPv4 legacy issues and don't apply to
IPv6 with its much improved socket API. And DHCPv6 servers will be
using that - not the IPv4 interface.

DOES *ANYONE* ON THE MAILING LIST HAVE ANY ISSUE WITH DOING THIS
CHANGE?

- Bernie

PS: In terms of unicasting the Reconfigure-Init, I think the
server will still need to save some information (such as the
Relay address and client's link local address to give to the
relay) or the client's link-local address (if on link). But, it
still should have all it needs.

-----Original Message-----
From: Bernie Volz (EUD)
Sent: Thursday, July 19, 2001 4:54 PM
To: 'dhcp-v6@bucknell.edu'
Subject: RE: 18.10, Server Unicast Option


Ralph:

No where in the -19 text does it say to ever use the IPv6 Source Address
to send messages. I thought the idea was NOT to require this kind
of data - we wanted the messages themselves to pretty much contain all
the server needed?

The text on sending the reply says unicast to relay (if Relay-Forward
received) else unicast it to the "client-link-local-address".

Perhaps we should change this to unicast to relay (if Relay-Forward
received) else unicast it to the IPv6 source address of the client's
message. In which case, what's the client-link-local-address needed
for (except when relayed, in which case that can be part of the
Relay-Forward/Relay-Reply).

If the IPv6 Source Address is used, yes there may be an issue if the
client doesn't provide an address of sufficent scope. But, I wasn't
really worried about that since that isn't really the server's fault.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, July 19, 2001 4:42 PM
To: DHCPv6 discussion list
Subject: Re: 18.10, Server Unicast Option


Bernie - can you be more specific about suggestion #2?  Are you referring
to the problem of replying to unicast messages when the client has used an
invalid source address?

- Ralph

At 03:28 PM 7/19/2001 -0500, Bernie Volz (EUD) wrote:

>After a few private exchanges with Ted, while there are still many
>open issues with the client unicasting to the server (such as how
>the server replies), how about we:
>
>- At a minimum, remove Confirm from the list of messages in Section
>18.10. It does not belong because it is NOT directed to a single
>server but instead to ANY server. (See section 14.3.2, "The client
>sets the "server-address" field to 0.) The other messages (Request,
>Renew, Release, and Decline) are all directed to a single server.
>
>- At a maximum, remove this section (option) altogether for now - it
>can always be added as a feature in a later revision (new option).
>This means we don't have to figure out how a server returns a reply
>to a unicast message. (Though it may tie in closely to what I've
>suggested as a clarificaton to Section 15.2.1 on unicasting
>Reconfigure-inits.)
>
>Bernie Volz
>Chief Technical Officer - DNS & DHCP Development Unit
>Ericsson, Inc.
>Tel: +1-508-875-3162
>Fax: +1-508-875-3018
>Mobile: +1-617-513-9060
><mailto:bernie.volz@ericsson.com>mailto:bernie.volz@ericsson.com

------_=_NextPart_001_01C110A5.80D18EB0-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 21:25:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA23825; Thu, 19 Jul 2001 21:25:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1P7L32386; Thu, 19 Jul 2001 21:25:07 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1P3L23590 for ; Thu, 19 Jul 2001 21:25:03 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27632; Thu, 19 Jul 2001 21:25:02 -0400 Date: Thu, 19 Jul 2001 21:25:02 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <66F66129A77AD411B76200508B65AC697B32DF@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN if the server does not believe the src address of the client is valid then it is not valid. /jim On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote: > Oh ... one more point for consideration ... > > If a client has multiple links and has received the "Server Unicast Option" from the server, > what's to prevent the client from sending the server a message out another interface (using > a prefix that the server has perhaps no knowledge of). > > Or, the client might use a stateless autoconfigured address, again one the server has no > knowledge of since there's no reason to give the server this information. > > Therefore when the server receives a message, it can NOT make ANY assumption about > the client's location based on the source address of the packet (unless it is a link local). > > - Bernie > > -----Original Message----- > From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] > Sent: Thursday, July 19, 2001 9:32 AM > To: DHCPv6 discussion list > Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > > This probably won't add much since in the case of a Confirm, the client > will likely be using its link-local address since that is the only one > it can reliable use (well, except for others that it has obtained via > stateless on the link). Thus, by definition, the client's Source IP > address will be *valid*. > > If the client is unicasting a message to the server (hence it is likely > using an address of greater scope than the link-local unless the server > is on the link), the relay won't see it but the routers will and they > would drop packets with invalid source addresses if they do egress > filtering. > > In order for the relay to add valid, it would need to parse the client's > message, find the addresses in the IAs, and check their prefixes. Hence, > it is a bit of work. > > I don't think the relay requires any state to do this since it just needs > to know the prefixes valid on that interface (which it should know either > because it is the router OR because it can listen to Router Advertisements > and learn them) and to parse the message. No state needs to be retained > *BETWEEN* client messages. > > However, while there is some merit in allowing this, again, a server *MUST* > also do it because it may be on-link with the client (hence no relay) or > perhaps some relays will not chose to implement this. > > So, if we wanted to explicitly allow this relay behavoir, we could say > that Relays *MAY* do this. In any case, servers *MUST* do it. > > I'm also wondering if there are cases where a DHCPv6 server might give out > addressses that a relay has no knowledge of. For example, is there any > prohibition against giving out IPv4 (mapped) addresses? [Perhaps these > prefixes would also be advertised via Router Advertisements and thus we > are OK.] > > - Bernie > > -----Original Message----- > From: Vijay Bhaskar A K [ mailto:vijayak@india.hp.com ] > Sent: Thursday, July 19, 2001 5:54 AM > To: DHCPv6 discussion list > Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > No, the relay need not to be stateful. It can just compare the > prefix of Source IP address of the client packet and has to compare > with the prefix of its interface in which it is received. It don't need > to parse the packet. It has to just see the sender's address, that's all. > But, this prevent the more and more processing that going to be > happened on the servers. I think, including this functionality in the relay > won't be a big problem. > ~Vijay > > > -----Original Message----- > > From: owner-dhcp-v6@bucknell.edu [ mailto:owner-dhcp-v6@bucknell.edu ]On > > Behalf Of Jim Bound > > Sent: Thursday, July 19, 2001 10:18 AM > > To: DHCPv6 discussion list > > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > > > > I think this is an option we can do later. But I think we > > are asking to > > much of the relay. The entire design goal has always been to keep the > > relay as stateless as possible. If the relay knows which prefixes are > > good for a client and has to parse the addresses in a client packet I > > think I am against that as one who has worked on building a > > router this is > > a bit intense. In fact now that I think about it I think > > this is simply > > not a good idea. > > > > > > /jim > > > > > > On Wed, 18 Jul 2001, Ted Lemon wrote: > > > > > > > > > The format of "Error Code" option is not specified in > > the draft. It is > > > > needed to be included. > > > > > > I think it goes into the IA option, but you're right - it > > needs to be > > > clarified. > > > > > > > It will be better, if this functionality can be > > incorporated in the > > > > agent,since, it is the only thing which knows well about > > the prefix in which > > > > the client message is received. And the advantage is, if > > this checking is > > > > done, this packet can be prevented from forwarding it to > > the multiple > > > > servers and save multiple processing time. The agent > > itself can send the > > > > NoPrefixMatch status directly to the client. > > > > > > Ooh, good point! I think it would be good if the agent could do > > > this, although I have to admit that I am concerned that some people > > > who implement relay agents may not want to have to delve into the IA > > > to validate a packet. I'm in favor of doing as you suggest, but I > > > suggest that we defer to the working group to see if any router > > > vendors have a problem with this. > > > > > > Also, the timing is a bit tight on making this change, and > > I wouldn't > > > blame the authors if they said "no, sorry, do this in a new > > draft." I > > > think it's okay to make this optional, so doing it in a > > seperate draft > > > should be fine. > > > > > > > If the client is receiving the error status as > > NoPrefixMatch error, what > > > > may be the reason other than client's plugging in to > > different subnet. I > > > > agree that, some roghe server can send this status, but, > > it can be prevented > > > > by authentication. > > > > > > The client may be mobile, and may be able to reach more than one > > > mobile access point. The two access points may want to think of > > > themselves as seperate links, even though their physical link-layers > > > overlap. I don't know how likely this is with existing technology, > > > but it's certainly been discussed with respect to 3G > > phones. I think > > > it's important to leave the language open for this case. > > > > > > _MelloN_ > > > > > > > > > From owner-dhcp-v6@bucknell.edu Thu Jul 19 21:25:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24151; Thu, 19 Jul 2001 21:25:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1QFL00505; Thu, 19 Jul 2001 21:26:15 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1Q7L23825 for ; Thu, 19 Jul 2001 21:26:07 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27451; Thu, 19 Jul 2001 21:26:06 -0400 Date: Thu, 19 Jul 2001 21:26:06 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <200107191846.f6JIkZX00383@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I think the entire notion of having a relay do server functions is a separate piece of work. /jim On Thu, 19 Jul 2001, Ted Lemon wrote: > > > No, the relay need not to be stateful. It can just compare the > > prefix of Source IP address of the client packet and has to compare > > with the prefix of its interface in which it is received. It don't need > > to parse the packet. It has to just see the sender's address, that's all. > > But, this prevent the more and more processing that going to be > > happened on the servers. I think, including this functionality in the relay > > won't be a big problem. > > This is true; the only concern is that the relay may not have complete > knowledge of the network configuration, and in that case it could > cause some serious breakage. I like the idea of saving work by > having the relay generate the Invalid Prefix result, but I think it > should be approached with great caution. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 21:27:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA24569; Thu, 19 Jul 2001 21:27:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1RcL07623; Thu, 19 Jul 2001 21:27:38 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1RTL22098 for ; Thu, 19 Jul 2001 21:27:30 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA26476; Thu, 19 Jul 2001 21:27:29 -0400 Date: Thu, 19 Jul 2001 21:27:29 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <200107191906.f6JJ6OX00469@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN the relay can't without looking at the UDP packet. sorry I don't believe routers perform well when looking past the header or as well. this is raging debate in the ietf. /jim On Thu, 19 Jul 2001, Ted Lemon wrote: > > > true. but the relay cannot see the addresses inside the IA option. > > thats the addresses that will have to be nak'd not the source address. > > Hm, why not? You mean because of authentication? > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 21:29:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25129; Thu, 19 Jul 2001 21:29:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1TkL03808; Thu, 19 Jul 2001 21:29:46 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1TVL15464 for ; Thu, 19 Jul 2001 21:29:31 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA24854; Thu, 19 Jul 2001 21:29:25 -0400 Date: Thu, 19 Jul 2001 21:29:25 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: 15.2.1, Creation & Sending of Reconfigure-init messages In-Reply-To: <66F66129A77AD411B76200508B65AC697B32E5@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I don't agree with number 3. A server who never gave the client its address or even talkd to it can send a reconfigure-init to it. How it knew the clients address is implementation defined. This behavior is important. /jim On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote: > I believe Section 15.2.1 of -19 needs some edits. > > It says: > > The server unicasts the Reconfigure-init message to one client. The > server may unicast Reconfigure-init messages to more than one client > concurrently; for example, to reliably reconfigure all known clients, > the server will unicast a Reconfigure-init message to each client. > > Can we specify this a bit more tightly. What does "server unicasts" > mean? Does that mean directly to the client? > > Well, consider that the server may not be able to do this. Why? > 1) If the server did not assign any addresses to the client (just gave > it configuration information), how does it know how to contact the > client directly? All it may have is the client's link local address > (and the relay's address if relayed). > 2) If the server did assign addresses, it may be that those addresses > are not of sufficient scope for the server to use to reach the client > directly. Even if they are, which address should it use (this may be > less of an issue but what if the preferred lifetimes have all elapsed > and the client may have removed the address - or *MUST* a client retain > the address until the valid lifetime expires?). > > Therefore, I would suggest that the text be revised to indicate HOW > the server unicasts. > > I suggest the following text: > > The server unicasts to the client by using one of the following > methods: > 1) If the client is on one of the server's interfaces, the clients > link local address is used. (The client's link local address must > have been saved from a previous communication from the client.) > 2) If the client has been assigned an address of sufficient scope > for the server to use in communicating with it and that address > is still preferred, this address MAY be used. > 3) Otherwise, the Reconfigure-Init should be unicast to a relay > agent (as a Relay-reply) and that relay will unicast it to the > client's link local address. (The client's link local address and > the relay's address must have been saved from a previous communication > from the client; or a suiteable relay agent's address is known by > some mechanism by the server.) > > BTW, there may be 4 (or more correctly, it should be 2.5) ... if the > client has unicast a packet directly to the server (because of the > Server Unicast Option, Section 18.10), the server could save that > address and use it. However, if the server did not assign this address, > it may have no information about the validity of that address and > therefore I did not include it. > > > Bernie Volz > > Chief Technical Officer - DNS & DHCP Development Unit > > Ericsson, Inc. > > Tel: +1-508-875-3162 > > Fax: +1-508-875-3018 > > Mobile: +1-617-513-9060 > > mailto:bernie.volz@ericsson.com > > > > > From owner-dhcp-v6@bucknell.edu Thu Jul 19 21:32:16 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA26036; Thu, 19 Jul 2001 21:32:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1WdL03360; Thu, 19 Jul 2001 21:32:39 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1WbL01924 for ; Thu, 19 Jul 2001 21:32:37 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27245; Thu, 19 Jul 2001 21:32:36 -0400 Date: Thu, 19 Jul 2001 21:32:36 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: 18.10, Server Unicast Option In-Reply-To: <66F66129A77AD411B76200508B65AC697B32E7@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN We must have capability to do unicast. I think removing that is not an option. It is a performance enhancement to a significant degree to not use relays. /jim On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote: > After a few private exchanges with Ted, while there are still many > open issues with the client unicasting to the server (such as how > the server replies), how about we: > > - At a minimum, remove Confirm from the list of messages in Section > 18.10. It does not belong because it is NOT directed to a single > server but instead to ANY server. (See section 14.3.2, "The client > sets the "server-address" field to 0.) The other messages (Request, > Renew, Release, and Decline) are all directed to a single server. > > - At a maximum, remove this section (option) altogether for now - it > can always be added as a feature in a later revision (new option). > This means we don't have to figure out how a server returns a reply > to a unicast message. (Though it may tie in closely to what I've > suggested as a clarificaton to Section 15.2.1 on unicasting > Reconfigure-inits.) > > > > Bernie Volz > > Chief Technical Officer - DNS & DHCP Development Unit > > Ericsson, Inc. > > Tel: +1-508-875-3162 > > Fax: +1-508-875-3018 > > Mobile: +1-617-513-9060 > > mailto:bernie.volz@ericsson.com > > > > > From owner-dhcp-v6@bucknell.edu Thu Jul 19 21:37:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28268; Thu, 19 Jul 2001 21:36:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1bIL25474; Thu, 19 Jul 2001 21:37:19 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K1b3L26944 for ; Thu, 19 Jul 2001 21:37:03 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA27868; Thu, 19 Jul 2001 21:37:03 -0400 Date: Thu, 19 Jul 2001 21:37:03 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <200107192117.f6JLH6X00699@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN but this would have to be two different interfaces which are two different IA's? /jim On Thu, 19 Jul 2001, Ted Lemon wrote: > > > Why should the client make a determination about moving to a new link? In > > fact, how can it make that determination at this point, which is, I think, > > after the point at which the client may have received an event from its > > interface about loss of carrier, change of access point, etc.? I suggest > > the following text: > > This is the multiple overlapping link layers problem - a 3G cell phone > that is able to contact two different cell towers. The client in this > case has information that the server does not have, and is probably > talking to more than one server, and therefore is in a position to > know that it can continue to use its addresses. The case where this > is most likely is when the client broadcast a Confirm message and gets > a response from the server for each cell tower, one of which says > "stop using those addresses" and the other of which says "go ahead and > keep using them." > > That is why the text gives the client the option of determining that > it has not changed link layers. The way the text is worded, there's > an easy out for implementors who have no clue how to make such a > determination, which I suspect would be most implementors. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Thu Jul 19 22:04:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08038; Thu, 19 Jul 2001 22:04:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K24OL12664; Thu, 19 Jul 2001 22:04:24 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6K24JL30864 for ; Thu, 19 Jul 2001 22:04:19 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f6K24Ip25406 for ; Thu, 19 Jul 2001 21:04:18 -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 f6K24IK15438 for ; Thu, 19 Jul 2001 21:04:18 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Jul 19 21:04:17 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKJNF5>; Thu, 19 Jul 2001 21:04:18 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32F3@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: 15.2.1, Creation & Sending of Reconfigure-init messages Date: Thu, 19 Jul 2001 21:04:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C110C0.475A4CB0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C110C0.475A4CB0 Content-Type: text/plain; charset="iso-8859-1" Jim: Agreed that if a server has been pre-configured with an address (or learns of it some other way), it can communicate. I'm just talking about the general case here - where the server has not been pre-configured with that information. The server *HAS* talked to the client in the past since otherwise it would not care to reconfigure it (again, if some configuration information is present, it can talk to *ANY* client). - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Thursday, July 19, 2001 9:29 PM To: DHCPv6 discussion list Subject: Re: 15.2.1, Creation & Sending of Reconfigure-init messages I don't agree with number 3. A server who never gave the client its address or even talkd to it can send a reconfigure-init to it. How it knew the clients address is implementation defined. This behavior is important. /jim On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote: > I believe Section 15.2.1 of -19 needs some edits. > > It says: > > The server unicasts the Reconfigure-init message to one client. The > server may unicast Reconfigure-init messages to more than one client > concurrently; for example, to reliably reconfigure all known clients, > the server will unicast a Reconfigure-init message to each client. > > Can we specify this a bit more tightly. What does "server unicasts" > mean? Does that mean directly to the client? > > Well, consider that the server may not be able to do this. Why? > 1) If the server did not assign any addresses to the client (just gave > it configuration information), how does it know how to contact the > client directly? All it may have is the client's link local address > (and the relay's address if relayed). > 2) If the server did assign addresses, it may be that those addresses > are not of sufficient scope for the server to use to reach the client > directly. Even if they are, which address should it use (this may be > less of an issue but what if the preferred lifetimes have all elapsed > and the client may have removed the address - or *MUST* a client retain > the address until the valid lifetime expires?). > > Therefore, I would suggest that the text be revised to indicate HOW > the server unicasts. > > I suggest the following text: > > The server unicasts to the client by using one of the following > methods: > 1) If the client is on one of the server's interfaces, the clients > link local address is used. (The client's link local address must > have been saved from a previous communication from the client.) > 2) If the client has been assigned an address of sufficient scope > for the server to use in communicating with it and that address > is still preferred, this address MAY be used. > 3) Otherwise, the Reconfigure-Init should be unicast to a relay > agent (as a Relay-reply) and that relay will unicast it to the > client's link local address. (The client's link local address and > the relay's address must have been saved from a previous communication > from the client; or a suiteable relay agent's address is known by > some mechanism by the server.) > > BTW, there may be 4 (or more correctly, it should be 2.5) ... if the > client has unicast a packet directly to the server (because of the > Server Unicast Option, Section 18.10), the server could save that > address and use it. However, if the server did not assign this address, > it may have no information about the validity of that address and > therefore I did not include it. > > > Bernie Volz > > Chief Technical Officer - DNS & DHCP Development Unit > > Ericsson, Inc. > > Tel: +1-508-875-3162 > > Fax: +1-508-875-3018 > > Mobile: +1-617-513-9060 > > mailto:bernie.volz@ericsson.com > > > > > ------_=_NextPart_001_01C110C0.475A4CB0 Content-Type: text/html; charset="iso-8859-1" RE: 15.2.1, Creation & Sending of Reconfigure-init messages

Jim:

Agreed that if a server has been pre-configured with an address (or
learns of it some other way), it can communicate. I'm just talking
about the general case here - where the server has not been pre-configured
with that information. The server *HAS* talked to the client in the past
since otherwise it would not care to reconfigure it (again, if some
configuration information is present, it can talk to *ANY* client).

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Thursday, July 19, 2001 9:29 PM
To: DHCPv6 discussion list
Subject: Re: 15.2.1, Creation & Sending of Reconfigure-init messages


I don't agree with number 3.  A server who never gave the client its
address or even talkd to it can send a reconfigure-init to it.  How it
knew the clients address is implementation defined.  This behavior is
important.


/jim


On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote:

> I believe Section 15.2.1 of -19 needs some edits.
>
> It says:
>
>    The server unicasts the Reconfigure-init message to one client.  The
>    server may unicast Reconfigure-init messages to more than one client
>    concurrently; for example, to reliably reconfigure all known clients,
>    the server will unicast a Reconfigure-init message to each client.
>
> Can we specify this a bit more tightly. What does "server unicasts"
> mean? Does that mean directly to the client?
>
> Well, consider that the server may not be able to do this. Why?
> 1) If the server did not assign any addresses to the client (just gave
> it configuration information), how does it know how to contact the
> client directly? All it may have is the client's link local address
> (and the relay's address if relayed).
> 2) If the server did assign addresses, it may be that those addresses
> are not of sufficient scope for the server to use to reach the client
> directly. Even if they are, which address should it use (this may be
> less of an issue but what if the preferred lifetimes have all elapsed
> and the client may have removed the address - or *MUST* a client retain
> the address until the valid lifetime expires?).
>
> Therefore, I would suggest that the text be revised to indicate HOW
> the server unicasts.
>
> I suggest the following text:
>
>   The server unicasts to the client by using one of the following
>   methods:
>   1) If the client is on one of the server's interfaces, the clients
>   link local address is used. (The client's link local address must
>   have been saved from a previous communication from the client.)
>   2) If the client has been assigned an address of sufficient scope
>   for the server to use in communicating with it and that address
>   is still preferred, this address MAY be used.
>   3) Otherwise, the Reconfigure-Init should be unicast to a relay
>   agent (as a Relay-reply) and that relay will unicast it to the
>   client's link local address. (The client's link local address and
>   the relay's address must have been saved from a previous communication
>   from the client; or a suiteable relay agent's address is known by
>   some mechanism by the server.)
>
> BTW, there may be 4 (or more correctly, it should be 2.5) ... if the
> client has unicast a packet directly to the server (because of the
> Server Unicast Option, Section 18.10), the server could save that
> address and use it. However, if the server did not assign this address,
> it may have no information about the validity of that address and
> therefore I did not include it.
>
> > Bernie Volz
> > Chief Technical Officer - DNS & DHCP Development Unit
> > Ericsson, Inc.
> > Tel: +1-508-875-3162
> > Fax: +1-508-875-3018
> > Mobile: +1-617-513-9060
> > mailto:bernie.volz@ericsson.com
> >
> >
>

------_=_NextPart_001_01C110C0.475A4CB0-- From owner-dhcp-v6@bucknell.edu Thu Jul 19 22:09:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA10229; Thu, 19 Jul 2001 22:09:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K2A1L18033; Thu, 19 Jul 2001 22:10:02 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6K29wL05237 for ; Thu, 19 Jul 2001 22:09:58 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f6K29kl07477 for ; Thu, 19 Jul 2001 19:09:46 -0700 (PDT) Date: Thu, 19 Jul 2001 22:09:41 -0400 (EDT) From: Ralph Droms To: DHCPv6 discussion list Subject: -20 rev of the DHCPv6 draft Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Based on the number of outstanding issues in the DHCPv6 spec, Jim and I have decided not to publish a -20 rev of the draft before the London I-D cutoff. Our plan now is to continue to discuss the outstanding issues on the mailing list and come to final resolution of any remaining issues at the WG meeting in London. Jim and I will then publish a -20 rev of the draft as soon as we can after we meet in London. Presumably this draft will be ready for WG last call. The good news is that we've had *significant* and *broad* participation in the mailing list discussion. Thanks to all who have read the draft thoroughly and contributed to the discussion... - Ralph From owner-dhcp-v6@bucknell.edu Thu Jul 19 22:12:29 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA11209; Thu, 19 Jul 2001 22:12:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K2CvL01661; Thu, 19 Jul 2001 22:12:57 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6K2ClL07172 for ; Thu, 19 Jul 2001 22:12:47 -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 f6K2Ckp26774 for ; Thu, 19 Jul 2001 21:12:46 -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 f6K2CkK16659 for ; Thu, 19 Jul 2001 21:12:46 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 19 21:12:45 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPJBVLH>; Thu, 19 Jul 2001 21:12:45 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B32F4@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 19 Jul 2001 21:12:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C110C1.768DC6A0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C110C1.768DC6A0 Content-Type: text/plain; charset="iso-8859-1" In the case of 3G cell phone, yes. But, what about Wireless LAN (802.11b)? Could this "flop" between two Access Point which have different prefixes? Anyway, Ted was just trying to leave some room for implementations to use other information they may have that would contradict the NoPrefixMatch or possibly make it suspect. In the case were a client has just powered on (or gets a link signal that it may have moved) and is doing a Confirm, getting a NoPrefixMatch likely would not require further determination. But, if what if that NoPrefixMatch is returned for other messages. The client has no other signal that the link may have changed out from under it, so in that case it might want to be a bit more cautious. I suspect that most implementations will simply assume that the link has changed and do a Solicit to find servers. So, do we want to force that behavior or allow a client some latitude to take steps to confirm this change? - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Thursday, July 19, 2001 9:37 PM To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] but this would have to be two different interfaces which are two different IA's? /jim On Thu, 19 Jul 2001, Ted Lemon wrote: > > > Why should the client make a determination about moving to a new link? In > > fact, how can it make that determination at this point, which is, I think, > > after the point at which the client may have received an event from its > > interface about loss of carrier, change of access point, etc.? I suggest > > the following text: > > This is the multiple overlapping link layers problem - a 3G cell phone > that is able to contact two different cell towers. The client in this > case has information that the server does not have, and is probably > talking to more than one server, and therefore is in a position to > know that it can continue to use its addresses. The case where this > is most likely is when the client broadcast a Confirm message and gets > a response from the server for each cell tower, one of which says > "stop using those addresses" and the other of which says "go ahead and > keep using them." > > That is why the text gives the client the option of determining that > it has not changed link layers. The way the text is worded, there's > an easy out for implementors who have no clue how to make such a > determination, which I suspect would be most implementors. > > _MelloN_ > ------_=_NextPart_001_01C110C1.768DC6A0 Content-Type: text/html; charset="iso-8859-1" RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

In the case of 3G cell phone, yes.

But, what about Wireless LAN (802.11b)? Could this "flop" between two Access
Point which have different prefixes?

Anyway, Ted was just trying to leave some room for implementations to use
other information they may have that would contradict the NoPrefixMatch or
possibly make it suspect.

In the case were a client has just powered on (or gets a link signal that it
may have moved) and is doing a Confirm, getting a NoPrefixMatch likely would
not require further determination.

But, if what if that NoPrefixMatch is returned for other messages. The client
has no other signal that the link may have changed out from under it, so in
that case it might want to be a bit more cautious.

I suspect that most implementations will simply assume that the link has
changed and do a Solicit to find servers.

So, do we want to force that behavior or allow a client some latitude to take
steps to confirm this change?

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Thursday, July 19, 2001 9:37 PM
To: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]


but this would have to be two different interfaces which are two different
IA's?


/jim


On Thu, 19 Jul 2001, Ted Lemon wrote:

>
> > Why should the client make a determination about moving to a new link?  In
> > fact, how can it make that determination at this point, which is, I think,
> > after the point at which the client may have received an event from its
> > interface about loss of carrier, change of access point, etc.?  I suggest
> > the following text:
>
> This is the multiple overlapping link layers problem - a 3G cell phone
> that is able to contact two different cell towers.  The client in this
> case has information that the server does not have, and is probably
> talking to more than one server, and therefore is in a position to
> know that it can continue to use its addresses.  The case where this
> is most likely is when the client broadcast a Confirm message and gets
> a response from the server for each cell tower, one of which says
> "stop using those addresses" and the other of which says "go ahead and
> keep using them."
>
> That is why the text gives the client the option of determining that
> it has not changed link layers.  The way the text is worded, there's
> an easy out for implementors who have no clue how to make such a
> determination, which I suspect would be most implementors.
>
>                              _MelloN_
>

------_=_NextPart_001_01C110C1.768DC6A0-- From owner-dhcp-v6@bucknell.edu Fri Jul 20 00:04:15 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19451; Fri, 20 Jul 2001 00:04:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K44EL05689; Fri, 20 Jul 2001 00:04:15 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K448L23343 for ; Fri, 20 Jul 2001 00:04:08 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA30704; Fri, 20 Jul 2001 00:04:07 -0400 Date: Fri, 20 Jul 2001 00:04:07 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: 15.2.1, Creation & Sending of Reconfigure-init messages In-Reply-To: <66F66129A77AD411B76200508B65AC697B32F3@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN ack bernie...sorry I was being anal...(plus I want to build one of those for IPv6 transition :----)) /jim On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote: > Jim: > > Agreed that if a server has been pre-configured with an address (or > learns of it some other way), it can communicate. I'm just talking > about the general case here - where the server has not been pre-configured > with that information. The server *HAS* talked to the client in the past > since otherwise it would not care to reconfigure it (again, if some > configuration information is present, it can talk to *ANY* client). > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Thursday, July 19, 2001 9:29 PM > To: DHCPv6 discussion list > Subject: Re: 15.2.1, Creation & Sending of Reconfigure-init messages > > > I don't agree with number 3. A server who never gave the client its > address or even talkd to it can send a reconfigure-init to it. How it > knew the clients address is implementation defined. This behavior is > important. > > > /jim > > > On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote: > > > I believe Section 15.2.1 of -19 needs some edits. > > > > It says: > > > > The server unicasts the Reconfigure-init message to one client. The > > server may unicast Reconfigure-init messages to more than one client > > concurrently; for example, to reliably reconfigure all known clients, > > the server will unicast a Reconfigure-init message to each client. > > > > Can we specify this a bit more tightly. What does "server unicasts" > > mean? Does that mean directly to the client? > > > > Well, consider that the server may not be able to do this. Why? > > 1) If the server did not assign any addresses to the client (just gave > > it configuration information), how does it know how to contact the > > client directly? All it may have is the client's link local address > > (and the relay's address if relayed). > > 2) If the server did assign addresses, it may be that those addresses > > are not of sufficient scope for the server to use to reach the client > > directly. Even if they are, which address should it use (this may be > > less of an issue but what if the preferred lifetimes have all elapsed > > and the client may have removed the address - or *MUST* a client retain > > the address until the valid lifetime expires?). > > > > Therefore, I would suggest that the text be revised to indicate HOW > > the server unicasts. > > > > I suggest the following text: > > > > The server unicasts to the client by using one of the following > > methods: > > 1) If the client is on one of the server's interfaces, the clients > > link local address is used. (The client's link local address must > > have been saved from a previous communication from the client.) > > 2) If the client has been assigned an address of sufficient scope > > for the server to use in communicating with it and that address > > is still preferred, this address MAY be used. > > 3) Otherwise, the Reconfigure-Init should be unicast to a relay > > agent (as a Relay-reply) and that relay will unicast it to the > > client's link local address. (The client's link local address and > > the relay's address must have been saved from a previous communication > > from the client; or a suiteable relay agent's address is known by > > some mechanism by the server.) > > > > BTW, there may be 4 (or more correctly, it should be 2.5) ... if the > > client has unicast a packet directly to the server (because of the > > Server Unicast Option, Section 18.10), the server could save that > > address and use it. However, if the server did not assign this address, > > it may have no information about the validity of that address and > > therefore I did not include it. > > > > > Bernie Volz > > > Chief Technical Officer - DNS & DHCP Development Unit > > > Ericsson, Inc. > > > Tel: +1-508-875-3162 > > > Fax: +1-508-875-3018 > > > Mobile: +1-617-513-9060 > > > mailto:bernie.volz@ericsson.com > > > > > > > > > From owner-dhcp-v6@bucknell.edu Fri Jul 20 00:09:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21115; Fri, 20 Jul 2001 00:09:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K4AJL07330; Fri, 20 Jul 2001 00:10:19 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K4AFL31136 for ; Fri, 20 Jul 2001 00:10:16 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA30958; Fri, 20 Jul 2001 00:10:15 -0400 Date: Fri, 20 Jul 2001 00:10:15 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <66F66129A77AD411B76200508B65AC697B32F4@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN just as some other input. we are working on this exactly now in research with a handheld. one interface is 802.11 and the other GPRS. As best as I can see now the only approach is to treat it as two interfaces in this case and it becomes a multihomed ipv6 node. Now the other case I am talking to folks about is sending voice over 802.11 even though it supposed to be only for data (who cares thats 11mbs) but then its still the same interface to the Acess Point. So where I was coming from was I think if someone could build a card that supported say two cell area providers at the same time they may have one interface to their dhcpv6 client. But is also this moot in practice? I think the one place stateless is a done deal is at the wireless handheld for IPv6? Maybe not. I don't really know I guess but thats my gut feeling. /jim On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote: > In the case of 3G cell phone, yes. > > But, what about Wireless LAN (802.11b)? Could this "flop" between two Access > Point which have different prefixes? > > Anyway, Ted was just trying to leave some room for implementations to use > other information they may have that would contradict the NoPrefixMatch or > possibly make it suspect. > > In the case were a client has just powered on (or gets a link signal that it > may have moved) and is doing a Confirm, getting a NoPrefixMatch likely would > not require further determination. > > But, if what if that NoPrefixMatch is returned for other messages. The client > has no other signal that the link may have changed out from under it, so in > that case it might want to be a bit more cautious. > > I suspect that most implementations will simply assume that the link has > changed and do a Solicit to find servers. > > So, do we want to force that behavior or allow a client some latitude to take > steps to confirm this change? > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Thursday, July 19, 2001 9:37 PM > To: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > but this would have to be two different interfaces which are two different > IA's? > > > /jim > > > On Thu, 19 Jul 2001, Ted Lemon wrote: > > > > > > Why should the client make a determination about moving to a new link? In > > > fact, how can it make that determination at this point, which is, I think, > > > after the point at which the client may have received an event from its > > > interface about loss of carrier, change of access point, etc.? I suggest > > > the following text: > > > > This is the multiple overlapping link layers problem - a 3G cell phone > > that is able to contact two different cell towers. The client in this > > case has information that the server does not have, and is probably > > talking to more than one server, and therefore is in a position to > > know that it can continue to use its addresses. The case where this > > is most likely is when the client broadcast a Confirm message and gets > > a response from the server for each cell tower, one of which says > > "stop using those addresses" and the other of which says "go ahead and > > keep using them." > > > > That is why the text gives the client the option of determining that > > it has not changed link layers. The way the text is worded, there's > > an easy out for implementors who have no clue how to make such a > > determination, which I suspect would be most implementors. > > > > _MelloN_ > > > From owner-dhcp-v6@bucknell.edu Fri Jul 20 00:46:08 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02006; Fri, 20 Jul 2001 00:46:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K4kSL28706; Fri, 20 Jul 2001 00:46:28 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6K4kEL21102 for ; Fri, 20 Jul 2001 00:46:14 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6K4fxf17766 for ; Thu, 19 Jul 2001 21:41:59 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6K4edX01119 for ; Thu, 19 Jul 2001 21:40:39 -0700 (MST) Message-Id: <200107200440.f6K4edX01119@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from Jim Bound of "Thu, 19 Jul 2001 21:37:03 -0400." Date: Thu, 19 Jul 2001 21:40:39 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >> This is the multiple overlapping link layers problem - a 3G cell phone >> that is able to contact two different cell towers. The client in this >> case has information that the server does not have, and is probably >> talking to more than one server, and therefore is in a position to >> know that it can continue to use its addresses. The case where this >> is most likely is when the client broadcast a Confirm message and gets >> a response from the server for each cell tower, one of which says >> "stop using those addresses" and the other of which says "go ahead and >> keep using them." >> >> That is why the text gives the client the option of determining that >> it has not changed link layers. The way the text is worded, there's >> an easy out for implementors who have no clue how to make such a >> determination, which I suspect would be most implementors. > but this would have to be two different interfaces which are two different > IA's? No, it would be the same interface. Cell phones only have one interface. There's really only one physical layer if you want to get technical, but because we're dealing with real-world radio propogation, it's mostly possible to think of the space around one beacon as a seperate physical layer than the space around another beacon. But when two beacons' coverage overlaps, there are places where you could get the behaviour that I'm talking about, where both beacons think their idea of the network is authoritative, but in fact it's not. I do not know if cell phone manufacturers will actually use this capability, nor if community-based wireless networks will, but I don't think it causes any harm to leave this possibility open, and I would therefore like to avoid closing it. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Jul 20 00:49:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA02924; Fri, 20 Jul 2001 00:49:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K4njL09310; Fri, 20 Jul 2001 00:49:45 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6K4nUL10868 for ; Fri, 20 Jul 2001 00:49:30 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6K4jFf17771 for ; Thu, 19 Jul 2001 21:45:15 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6K4htX01129 for ; Thu, 19 Jul 2001 21:43:55 -0700 (MST) Message-Id: <200107200443.f6K4htX01129@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from Jim Bound of "Fri, 20 Jul 2001 00:10:15 -0400." Date: Thu, 19 Jul 2001 21:43:55 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > But is also this moot in practice? I think the one place stateless is a > done deal is at the wireless handheld for IPv6? Maybe not. I don't > really know I guess but thats my gut feeling. There's no harm in leaving the flexibility in. I have no idea how it will be used. Do you see any harm in it? _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Jul 20 05:38:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07208 for ; Fri, 20 Jul 2001 05:38:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6K9ZkL28029; Fri, 20 Jul 2001 05:35:46 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6K9YuL19878 for ; Fri, 20 Jul 2001 05:34: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 FAA04892; Fri, 20 Jul 2001 05:33:59 -0400 (EDT) Message-Id: <200107200933.FAA04892@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-key-management-00.txt Date: Fri, 20 Jul 2001 05:33:59 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 : Wireless Key Management using DHCP Author(s) : N. Shankar et al. Filename : draft-ietf-dhc-key-management-00.txt Pages : Date : 19-Jul-01 This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to configure the WEP key on a client's wireless card. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-key-management-00.txt 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-key-management-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-key-management-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010719145547.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-key-management-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-key-management-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010719145547.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Jul 20 15:02:46 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02416 for ; Fri, 20 Jul 2001 15:02:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6KIxdL31189; Fri, 20 Jul 2001 14:59:39 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6KIxaL32305 for ; Fri, 20 Jul 2001 14:59:36 -0400 (EDT) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-111.cisco.com [161.44.149.111]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA01108; Fri, 20 Jul 2001 14:59:19 -0400 (EDT) Message-Id: <4.3.2.7.2.20010720144940.022f1df0@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 20 Jul 2001 15:00:56 -0400 To: DHCPv4 discussion list From: Kim Kinnear Subject: draft-ietf-dhc-failover-09.txt Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Folks, I've just submitted the latest version of the failover draft, draft-ietf-dhc-failover-09.txt. It has a number of changes in it, derived both from discussions held during the last IETF in Minneapolis in December of 2000, as well as some discussions which were generated by problems discussed on this list. I've given a complete list of the changes below. All are fairly minor, but several are more than editoral corrections or clarifications (of which there were also plenty). Thanks to Bernie for another *stellar* editorial review which added many clarifications, and thanks to Ted bringing up some real-world issues that are now handled acceptably. (I hope you agree, Ted, since I believe I took every one of your suggestions.) In talking with Ralph, we believe that it makes sense to put the failover draft through another WG last call immediately after London IETF, and then (if possible), move quickly to IESG last call. At least that is the plan. As I won't be able to attend London IETF, there is no need to hold your comments until then -- please bring any problems you have with the -09 version of the draft up on this list. Cheers -- Kim ============================================== Here is a SUMMARY of changes made to the -08 version of the draft to yield the -09 version of the draft: 1. Fix a potentially major inefficiency in recovery (which has actually occurred moderately often in production use) by adding a new failover state: RECOVER-WAIT. 2. Fix a problem which occurs when two existing servers, both with active lease state, become part of a failover pair. 3. Clarification on reusing lease when in PARTNER-DOWN state. 4. Clean up some security Issues: 5. Fix Bootp problem with communications interrupted: 6. Server-id option removed, relationship-name option added. 7. Textual and editoral corrections from Bernie Volz, Ted Lemon, and Kim Kinnear. -------------------------------------------- Here are the changes IN DETAIL: -------------------------------------------- 1. Fix a potentially major inefficiency in recovery (which has actually occurred moderately often in production use) by adding a new failover state: The problem: It turns out that there's a problem in the recovery process. Let's say I go into RECOVER, and send an UPDREQALL. I get all the updates, and ack them, and then I get the UPDDONE. Now I set a timer for start time of state (STOS)+MCLT. When that goes off, I make the transition into RECOVER-DONE. The peer makes the transition into NORMAL, and then I make the transition into NORMAL. But what happens if I get interrupted after I've set that timer, but before it's expired? Currently, I come back in the RECOVER state, with no knowledge that I had gotten a complete update. In the -08 draft, this happens: So I guess I send another UPDREQALL, and then things proceed normally. But this can be a pretty expensive thing to do, and this is not a very far-fetched scenario. The solution to this problem: Add an additional state, RECOVER-WAIT, which we enter when we get the UPDDONE from the partner. When we enter RECOVER-WAIT, we start a timer which should expire at the time equal to when the server went down plus the MCLT or later. When this timer expires, we move into RECOVER-DONE state. ----------------------------------------------------------------- 2. Fix a problem which occurs when two existing servers, both with active lease state, become part of a failover pair. The problem: There is a problem if two failover peers come up and neither one has done failover before but both peers have valid lease state at that time. In this case, they each need to see all of their peers' non-virgin leases. If the primary starts in PARTNER-DOWN and the secondary in RECOVER (as written in the -08 draft), then the primary may hand out leases that the secondary already assigned back when both servers were operating independently. The solution: Start both primary and secondary servers in RECOVER. Both peers send UPDREQALL messages at the same time. There is a slight change: if I am in RECOVER-DONE and the peer goes into RECOVER-DONE, I have to go into NORMAL. An implementation SHOULD have a configuration parameter which can be set on the primary to indicate that the primary should move to PARTNER-DOWN state if has never had any contact with the secondary server and is unable to contact that server on startup. This will allow a server which is made a failover server to continue to operate until it can rendevous with the newly created secondary. It can only be used in cases where the secondary has no existing lease state information. ----------------------------------------------------------------- 3. Clarification on reusing leases when in PARTNER-DOWN state. >From the -08 draft: In addition, once a server has transitioned to PARTNER-DOWN state, it MUST NOT reallocate an IP address from one client to another client until an additional MCLT interval after the lease by the original client expires. (Actually, until the maximum client lead time after what it believes to be the lease expiration time of the client.) The problem here is that if the peers were in communications- interrupted for an extended period of time, the secondary may have renewed the lease to MCLT quite a few times, so that the actual lease expiry time on the client is well past the lease time recorded on the server that is now in partner-down state. To be safe, I think that this lease should not be reallocated until partner-down-stos + MCLT. Make it clear that this must be the greater of the time mentioned above or the start-time-of-state+mclt. ------------------------------------------------- 4. Clean up some security Issues: a.) To look into the MD5/HMAC issue. Bernie decided we should use HMAC. b.) We will require that the message digest option is first in the packet if you are doing a message digest. c.) We will specify that you must keep the last time a connect message came in (the time in the message), and if we ever saw that connect message or one earlier then we would reject the connect. d.) We will require that the XID's must go up, and that you must reject a message that didn't have an increasing XID. e.) We will suggest a configurable parameter for time differential when using message digests. -------------------------------------------------- 5. Fix Bootp problem with communications interrupted: The problem is: If there are two server in communications-interrupted that are both responsive to dynamic BOOTP, then the same client could get an address from both of them. There are two possible solutions: 1. When the server reconnect and find the conflict, they should not take the "primary wins" strategy, but rather agree to disagree. The client will keep both addresses, since neither server can know which one he remembers. Requires manual intervention to fix. 2. When in communications-interrupted state, a server doesn't become responsive until it is in partner down state. This would cause a lack of responsiveness or dynamic bootp clients, but would keep them from ever getting into this situation. We will require solution #1 in the draft. ----------------------------------------------------- 6. Server-id option removed, relationship-name option added. On the failover server-id option, we will put a string valued name (the relationship-name option) in the packet which would identify the relationship. This would allow more than one relationship between two machines using the same IP address (instead of the previous requirement for multihoming to do this). It will also allow for moving a relationship more easily. You may choose to allow configuration of the IP address of the partner, and if they connect from a different place, you can choose to use it or not, but you don't have to. If no security, MAY want to validate IP of partner instead of just allowing anyone with proper string to operate. Can use the source-ip of the TCP connection to do that. The relationship-name option is in the connect message. We will take out the server-id option. Because of this, the connect message processing is different -- the connect processing must look at the relationship-name as opposed to the sending-server-ip-address option. --------------------------------------------------------- 7. Textual and editorial changes. a.) Ted's "has transitioned" -> "has made the transition to". b.) Bernie's -08 review. Moderate editorial changes and clarifications. Lots of actual changes. c.) updated bibliography for draft->rfc progress From owner-dhcp-v4@bucknell.edu Sat Jul 21 21:31:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09297 for ; Sat, 21 Jul 2001 21:31:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6M1SE832573; Sat, 21 Jul 2001 21:28:16 -0400 (EDT) Received: from falcon.mail.pas.earthlink.net (falcon.mail.pas.earthlink.net [207.217.120.74]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6M1S7832134 for ; Sat, 21 Jul 2001 21:28:07 -0400 (EDT) Received: from earthlink.net (sdn-ar-001nctarbP264.dialsprint.net [168.191.248.26]) by falcon.mail.pas.earthlink.net (EL-8_9_3_3/8.9.3) with ESMTP id SAA13244 for ; Sat, 21 Jul 2001 18:27:57 -0700 (PDT) Message-ID: <3B5A2BC0.9B3C229A@earthlink.net> Date: Sat, 21 Jul 2001 21:26:24 -0400 From: Alexa Ruffin X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: What is? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: klragw@earthlink.net Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I know what DHCP is and what it does but I do not know what DHCP-v4 does? From owner-dhcp-v4@bucknell.edu Sat Jul 21 21:55:39 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16936 for ; Sat, 21 Jul 2001 21:55:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6M1tu802401; Sat, 21 Jul 2001 21:55:56 -0400 (EDT) Received: from plato.protechpts.com ([209.161.92.100]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6M1tn801939 for ; Sat, 21 Jul 2001 21:55:49 -0400 (EDT) Received: from 024-240-187-186.rcm.charterpa.net (024-240-187-186.rcm.charterpa.net [24.240.187.186]) by plato.protechpts.com (NTMail 5.06.0016/QS1090.00.89c82519) with ESMTP id hnticaaa for dhcp-v4@bucknell.edu; Sat, 21 Jul 2001 21:55:48 -0400 Message-Id: <5.1.0.14.2.20010721215306.00a15d20@mail.protechpts.com> X-Sender: hgottfried@mail.protechpts.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sat, 21 Jul 2001 21:58:17 -0400 To: DHCPv4 discussion list From: "Hal F. Gottfried" Subject: Re: What is? In-Reply-To: <3B5A2BC0.9B3C229A@earthlink.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: hgottfried@protechpts.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Alexa, I am under the impression that DHCPv4 is normal DHCP as opposed to DHCPv6, which is the DHCP for TCPv6. If I am incorrect some one please let me know. Hal F. Gottfried Technical Instructor ProTech Professional Technical Services , Inc. 800-373-9188 At 09:26 PM 7/21/2001 -0400, Alexa Ruffin wrote: >I know what DHCP is and what it does but I do not know what DHCP-v4 >does? From owner-dhcp-v6@bucknell.edu Sun Jul 22 21:48:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16951; Sun, 22 Jul 2001 21:48:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6N1mS813561; Sun, 22 Jul 2001 21:48:28 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6N1mR814607 for ; Sun, 22 Jul 2001 21:48:27 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA14602; Sun, 22 Jul 2001 21:48:26 -0400 Date: Sun, 22 Jul 2001 21:48:26 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <200107200440.f6K4edX01119@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I would like to close it until we are sure we need to have such an abstraction and in fact it will be deployed. But, if there are properties from this we should consider and discuss thats a different story. thanks /jim On Thu, 19 Jul 2001, Ted Lemon wrote: > > >> This is the multiple overlapping link layers problem - a 3G cell phone > >> that is able to contact two different cell towers. The client in this > >> case has information that the server does not have, and is probably > >> talking to more than one server, and therefore is in a position to > >> know that it can continue to use its addresses. The case where this > >> is most likely is when the client broadcast a Confirm message and gets > >> a response from the server for each cell tower, one of which says > >> "stop using those addresses" and the other of which says "go ahead and > >> keep using them." > >> > >> That is why the text gives the client the option of determining that > >> it has not changed link layers. The way the text is worded, there's > >> an easy out for implementors who have no clue how to make such a > >> determination, which I suspect would be most implementors. > > > but this would have to be two different interfaces which are two different > > IA's? > > No, it would be the same interface. Cell phones only have one > interface. There's really only one physical layer if you want to get > technical, but because we're dealing with real-world radio > propogation, it's mostly possible to think of the space around one > beacon as a seperate physical layer than the space around another > beacon. But when two beacons' coverage overlaps, there are places > where you could get the behaviour that I'm talking about, where both > beacons think their idea of the network is authoritative, but in fact > it's not. > > I do not know if cell phone manufacturers will actually use this > capability, nor if community-based wireless networks will, but I don't > think it causes any harm to leave this possibility open, and I > would therefore like to avoid closing it. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Sun Jul 22 21:50:07 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16977; Sun, 22 Jul 2001 21:50:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6N1na815289; Sun, 22 Jul 2001 21:49:36 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6N1nN815105 for ; Sun, 22 Jul 2001 21:49:23 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA14597; Sun, 22 Jul 2001 21:49:22 -0400 Date: Sun, 22 Jul 2001 21:49:22 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <200107200443.f6K4htX01129@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Any time we add bloat to a protocol design for things that may never get used I treat as harm. /jim On Thu, 19 Jul 2001, Ted Lemon wrote: > > > But is also this moot in practice? I think the one place stateless is a > > done deal is at the wireless handheld for IPv6? Maybe not. I don't > > really know I guess but thats my gut feeling. > > There's no harm in leaving the flexibility in. I have no idea how it > will be used. Do you see any harm in it? > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Mon Jul 23 13:15:09 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07247; Mon, 23 Jul 2001 13:15:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6NHBC822019; Mon, 23 Jul 2001 13:11:12 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6NHB8830987 for ; Mon, 23 Jul 2001 13:11:08 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6NHAq505752 for ; Mon, 23 Jul 2001 12:10:52 -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 f6NHAq502292 for ; Mon, 23 Jul 2001 12:10:52 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Jul 23 12:10:51 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKNGA6>; Mon, 23 Jul 2001 12:10:51 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B330D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: A few additional items re: -19 draft Date: Mon, 23 Jul 2001 12:10:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1139A.6712A110" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C1139A.6712A110 Content-Type: text/plain; charset="iso-8859-1" In further reviews of the -19 draft, here are a few other issues/clarifications that should be considered for the -20 draft: - Can the Authentication Option be used for Relay <--> Server communications? I didn't find anything in the draft that specifically prohibits or allows it. This might be useful to add additional security for the communication between these devices. - Should we consider a client prefix-selection option as a base option to allow a "client" to allocate an address for a prefix other than the one it might be on? Should this be part of the base specification? Note: Perhaps these devices should just be Relays and use the Relay-Forward. In this case, they can simply specify that information via the relay-address field. And, if we have the server use the IPv6 source address for sending replies to the relay's, then this field (relay-address) can even contain something that might not truly be an address assigned to the relay. - For Reply messages to Decline and Release messages, what should the server do about options (other than the IA)? This may be less of a server issue but more of a client issue. It probably makes little sense for the server to include a "Domain Name Server option"? And servers may want to provide a minimal message to save bandwidth and processing overhead? I guess since we have no idea what future options may be defined, the best recommendations is that servers MUST send those options explicitly requested by a client's ORO option; a server MAY send other options (though clients are free to ignore these extra options - as they normally are!). Perhaps this is already implied by the options processing (based on DHCPv4) but wouldn't it be best to make it explicit? This same processing probably applies to ALL option handling in any Reply to a client message. Is it already in the draft and I missed it? - For the Confirm message, Section 14. states: Confirm Confirm the validity of assigned addresses and other configuration changes through the server from which the configuration information was obtained when the client's assigned addresses may not be valid; for example, when the client reboots or loses its connection to a link We probably need to clarify the behavior somewhat. For example, if a server that did not give out the addresses responds, can it: - Allocate additional addresses (to the IA)? - Extend the lifetimes of existing addresses? - Change/respond with configuration parameters? If the client does request (and supply) other options, what happens if the server's reply does not include those options (perhaps because the server doesn't feel it can supply them). I guess what I'm suggesting is that we indicate that allocation of addresses and supplying configuration parameters with a Confirm are problematic. And, that a client MUST NOT assume that the lack of a configuration parameter (option) means that the previous value for that option should be removed. Similar behavior might be required for Rebind - as multiple servers may respond? Though I think there are fewer issues here. Perhaps we should stress that Confirm SHOULD (MUST) only be used to confirm whether addresses are valid and SHOULD NOT (MUST NOT) be used in place of a Renew/Rebind?? Perhaps we should even specifically state that clients MUST NOT apply changes to the lifetimes or addition of new addresses received in a Reply to a Confirm? - When forming the Advertise in response to a Solicit, there isn't any clear indication of what to do if no addresses may be available for the client from that server at that time (because all available addresses are in use). In particular, should the server: - Ignore the Solicit (in the hopes that by the time a subsequent Solicit arrives, addresses may be available) - Send the Advertise but without the IA option - Send the Advertise with the IA option but with an error (such as Unavail) - Send the Advertise with the IA option with num-addrs = 0 Or, should a client be prepared to handle all of the above? - Regarding Releases and Declines ... if we stay with allowing a client to do partial releases/declines (which I hope we do!), we should change the text to be a bit more forgiving. In particular, if a server has no Transaction cache, it may well be that a lost Reply generates unwanted errors on client retransmission of the Release/Decline. So, what I suggest we do is to simply have the Server ignore any addresses that are not assigned to the client. The ONLY case that should generate an error is if a Release/Decline for an IA has an address that is assigned to that client but not that IA - since this is the only case that is truly an error and ambiguous to the server as to whether the client is still using that address or not. Of course, in any case, the server should only Release or Decline those addresses it still has a record of belonging to that Client (DUID)/IA. - Bernie Volz ------_=_NextPart_001_01C1139A.6712A110 Content-Type: text/html; charset="iso-8859-1" A few additional items re: -19 draft

In further reviews of the -19 draft, here are a few other
issues/clarifications that should be considered for the -20
draft:

- Can the Authentication Option be used for Relay <-->
Server communications? I didn't find anything in the draft
that specifically prohibits or allows it. This might be
useful to add additional security for the communication
between these devices.

- Should we consider a client prefix-selection option as
a base option to allow a "client" to allocate an address
for a prefix other than the one it might be on? Should
this be part of the base specification?

Note: Perhaps these devices should just be Relays and use
the Relay-Forward. In this case, they can simply specify
that information via the relay-address field. And, if we
have the server use the IPv6 source address for sending
replies to the relay's, then this field (relay-address)
can even contain something that might not truly be an
address assigned to the relay.

- For Reply messages to Decline and Release messages,
what should the server do about options (other than the
IA)? This may be less of a server issue but more of a
client issue. It probably makes little sense for the
server to include a "Domain Name Server option"? And
servers may want to provide a minimal message to save
bandwidth and processing overhead? I guess since we have
no idea what future options may be defined, the best
recommendations is that servers MUST send those options
explicitly requested by a client's ORO option; a server
MAY send other options (though clients are free to
ignore these extra options - as they normally are!).
Perhaps this is already implied by the options
processing (based on DHCPv4) but wouldn't it be best to
make it explicit? This same processing probably applies
to ALL option handling in any Reply to a client message.
Is it already in the draft and I missed it?

- For the Confirm message, Section 14. states:

Confirm Confirm the validity of assigned addresses and other
                configuration changes through the server from which the
                configuration information was obtained when the client's
                assigned addresses may not be valid; for example, when
                the client reboots or loses its connection to a link

We probably need to clarify the behavior somewhat. For example,
if a server that did not give out the addresses responds, can
it:
- Allocate additional addresses (to the IA)?
- Extend the lifetimes of existing addresses?
- Change/respond with configuration parameters?

If the client does request (and supply) other options, what
happens if the server's reply does not include those options
(perhaps because the server doesn't feel it can supply them).

I guess what I'm suggesting is that we indicate that allocation
of addresses and supplying configuration parameters with a
Confirm are problematic. And, that a client MUST NOT assume
that the lack of a configuration parameter (option) means
that the previous value for that option should be removed.

Similar behavior might be required for Rebind - as multiple
servers may respond? Though I think there are fewer issues
here.

Perhaps we should stress that Confirm SHOULD (MUST) only be
used to confirm whether addresses are valid and SHOULD NOT
(MUST NOT) be used in place of a Renew/Rebind?? Perhaps we
should even specifically state that clients MUST NOT apply
changes to the lifetimes or addition of new addresses received
in a Reply to a Confirm?

- When forming the Advertise in response to a Solicit, there
isn't any clear indication of what to do if no addresses may
be available for the client from that server at that time
(because all available addresses are in use). In particular,
should the server:
- Ignore the Solicit (in the hopes that by the time a subsequent
  Solicit arrives, addresses may be available)
- Send the Advertise but without the IA option
- Send the Advertise with the IA option but with an error (such
  as Unavail)
- Send the Advertise with the IA option with num-addrs = 0

Or, should a client be prepared to handle all of the above?

- Regarding Releases and Declines ... if we stay with allowing
a client to do partial releases/declines (which I hope we do!),
we should change the text to be a bit more forgiving. In
particular, if a server has no Transaction cache, it may well
be that a lost Reply generates unwanted errors on client
retransmission of the Release/Decline. So, what I suggest we
do is to simply have the Server ignore any addresses that are
not assigned to the client. The ONLY case that should generate
an error is if a Release/Decline for an IA has an address that
is assigned to that client but not that IA - since this is the
only case that is truly an error and ambiguous to the server
as to whether the client is still using that address or not.
Of course, in any case, the server should only Release or
Decline those addresses it still has a record of belonging to
that Client (DUID)/IA.

- Bernie Volz

------_=_NextPart_001_01C1139A.6712A110-- From owner-dhcp-v6@bucknell.edu Mon Jul 23 23:57:48 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11162; Mon, 23 Jul 2001 23:57:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6O3vk811819; Mon, 23 Jul 2001 23:57:46 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6O3vd813676 for ; Mon, 23 Jul 2001 23:57:39 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6O3rEf25478 for ; Mon, 23 Jul 2001 20:53:14 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6O3rUB29989 for ; Mon, 23 Jul 2001 20:53:30 -0700 (MST) Message-Id: <200107240353.f6O3rUB29989@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: A few additional items re: -19 draft In-Reply-To: Message from "Bernie Volz (EUD)" of "Mon, 23 Jul 2001 12:10:41 EST." <66F66129A77AD411B76200508B65AC697B330D@eambunt705.ena-east.ericsson.se> Date: Mon, 23 Jul 2001 20:53:29 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > - Can the Authentication Option be used for Relay <--> > Server communications? I didn't find anything in the draft > that specifically prohibits or allows it. This might be > useful to add additional security for the communication > between these devices. IPsec solves this! _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Jul 24 06:35:17 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06848 for ; Tue, 24 Jul 2001 06:35:17 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6OAUn817995; Tue, 24 Jul 2001 06:30:49 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6OAUX812175 for ; Tue, 24 Jul 2001 06:30:33 -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 GAA05912; Tue, 24 Jul 2001 06:29:35 -0400 (EDT) Message-Id: <200107241029.GAA05912@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list CC: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-guttman-dhc-mdns-enable-01.txt Date: Tue, 24 Jul 2001 06:29:35 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP mDNS Enable Option Author(s) : E. Guttman Filename : draft-guttman-dhc-mdns-enable-01.txt Pages : 6 Date : 23-Jul-01 The Dynamic Host Configuration Protocol [2] allows network administrators to determine host configuration parameters. This document defines a new DHCP option [3] specifically to enable and control multicast DNS behavior. This is an alternative to using the Domain Search Option [4] to configure mDNS behavior, as has been proposed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-guttman-dhc-mdns-enable-01.txt 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-guttman-dhc-mdns-enable-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-guttman-dhc-mdns-enable-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: <20010723140443.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-guttman-dhc-mdns-enable-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-guttman-dhc-mdns-enable-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010723140443.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Tue Jul 24 10:21:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19940; Tue, 24 Jul 2001 10:21:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6OEL3822048; Tue, 24 Jul 2001 10:21:03 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6OEL0820266 for ; Tue, 24 Jul 2001 10:21:01 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6OEKj511291 for ; Tue, 24 Jul 2001 09:20: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 f6OEKin06717 for ; Tue, 24 Jul 2001 09:20:44 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jul 24 09:20:44 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPK3Z8K>; Tue, 24 Jul 2001 09:20:43 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3312@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: A few additional items re: -19 draft Date: Tue, 24 Jul 2001 09:20:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1144B.CF13AB40" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C1144B.CF13AB40 Content-Type: text/plain; charset="iso-8859-1" Yeah, but perhaps you don't want to use it. With the server code already set up to handle the Authentication Option for clients, I'm just asking why can't this also be used between the Relay and Server. It may simplify configuration of the devices (though it does add some new configuration on the Relay). Are you thus in favor of DISALLOWING this? - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Monday, July 23, 2001 11:53 PM To: DHCPv6 discussion list Subject: Re: A few additional items re: -19 draft > - Can the Authentication Option be used for Relay <--> > Server communications? I didn't find anything in the draft > that specifically prohibits or allows it. This might be > useful to add additional security for the communication > between these devices. IPsec solves this! _MelloN_ ------_=_NextPart_001_01C1144B.CF13AB40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A few additional items re: -19 draft

Yeah, but perhaps you don't want to use it. With the = server code already set up to handle the
Authentication Option for clients, I'm just asking = why can't this also be used between the
Relay and Server. It may simplify configuration of = the devices (though it does add some new
configuration on the Relay).

Are you thus in favor of DISALLOWING this?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Monday, July 23, 2001 11:53 PM
To: DHCPv6 discussion list
Subject: Re: A few additional items re: -19 draft =



> - Can the Authentication Option be used for = Relay <-->
> Server communications? I didn't find anything = in the draft
> that specifically prohibits or allows it. This = might be
> useful to add additional security for the = communication
> between these devices.

IPsec solves this!

        =         =                _MelloN_

------_=_NextPart_001_01C1144B.CF13AB40-- From owner-dhcp-v6@bucknell.edu Tue Jul 24 10:55:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA22393; Tue, 24 Jul 2001 10:55:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6OEtj825019; Tue, 24 Jul 2001 10:55:45 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6OEtd820746 for ; Tue, 24 Jul 2001 10:55:39 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6OEpBf26692 for ; Tue, 24 Jul 2001 07:51:11 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6OEofB01020 for ; Tue, 24 Jul 2001 07:50:41 -0700 (MST) Message-Id: <200107241450.f6OEofB01020@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: A few additional items re: -19 draft In-Reply-To: Message from "Bernie Volz (EUD)" of "Tue, 24 Jul 2001 09:20:37 EST." <66F66129A77AD411B76200508B65AC697B3312@eambunt705.ena-east.ericsson.se> Date: Tue, 24 Jul 2001 07:50:41 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Yeah, but perhaps you don't want to use it. With the server code > already set up to handle the Authentication Option for clients, I'm > just asking why can't this also be used between the Relay and > Server. It may simplify configuration of the devices (though it does > add some new configuration on the Relay). Because we'll get beaten up when we try to go to RFC. This is not a technical reason, but the reason we'd get beaten up is that there's already a standard solution to this problem in the case of server<->relay agent communications. If we add language to the draft to explain how to do DHCP authentication between relay and server, someone will notice, and it will delay the draft, and they'll be right to do so. > Are you thus in favor of DISALLOWING this? I don't see any benefit to it. I don't see how it would simplify configuration, either - the key management problem is the same in either case. We don't have a solution to the key management problem in DHCP authentication yet, so I think it's more likely that we will have IPsec and not DHCPauth than DHCPauth and not IPsec, frankly. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 24 18:43:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29187; Tue, 24 Jul 2001 18:43:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6OMht802869; Tue, 24 Jul 2001 18:43:55 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6OMhe808335 for ; Tue, 24 Jul 2001 18:43:40 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn2-151.cisco.com [10.21.112.151]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA17084 for ; Tue, 24 Jul 2001 18:43:24 -0400 (EDT) Message-Id: <4.3.2.7.2.20010724183353.03443130@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Jul 2001 18:42:04 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: Simplify release and decline of addresses In-Reply-To: <66F66129A77AD411B76200508B65AC697B32CC@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN My memory is that we've come to consensus that the client doesn't get to specify what kind of addresses it wants; the client sends an IA to the server and the server's response is determined by the server's admin policies. - Ralph At 05:57 PM 7/18/2001 -0500, Bernie Volz (EUD) wrote: >Regarding a new option to handle Temporary Addresses, I think this has >merit simply because there has been no way for a client to communicate >what kind of addresses it wants. Having this option provides that mechanism. >Alternatives, such as allowing 'num-addrs' and thus some address information >(T bit) to be specified by the client in a Request were discussed at one >point but did not make it into the -19 draft and I'm not sure if it would be >in the -20. > >Perhaps Ralph and Jim will care to provide some indication of how this >will be >resolved in the -20 draft - to give the client some ability to communicate to >the server what it needs. OR, perhaps the answer is simply "no, we're not >going to support it - it is up to the server to figure it out." From owner-dhcp-v6@bucknell.edu Tue Jul 24 19:09:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00376; Tue, 24 Jul 2001 19:09:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6ON9l808535; Tue, 24 Jul 2001 19:09:47 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6ON9g803867 for ; Tue, 24 Jul 2001 19:09:42 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6ON9Q521542 for ; Tue, 24 Jul 2001 18:09:26 -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 f6ON9QA05562 for ; Tue, 24 Jul 2001 18:09:26 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jul 24 18:09:26 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <3CPKQCZM>; Tue, 24 Jul 2001 18:09:25 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B331D@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses Date: Tue, 24 Jul 2001 18:09:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11495.AAD89D90" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11495.AAD89D90 Content-Type: text/plain; charset="iso-8859-1" The issues you have are: - What if multiple servers are involved. A client only wants a new temporary address, but gets a boatload of other addresses. Perhaps it releases them (but then if we don't allow the selective release ...). This adds extra processing overhead to client and server. - This imposes additional requirements on a server. If a server gets a new IA, does it automatically assume well that client already has non-temporary addresses, so just give it more temporary addresses. What if a server doesn't have this policy and keeps giving the client more and more non-temporary addresses as well? We need to make sure we reflect that as a requirement to server implementators. Again a client culd release those it doesn't want (assuming selective release allowed) but again that adds extra processing overhead to both client and server. - All I think we really need is "I want addresses (of whatever type the server is willing to give" and "I want temporary addresses only". I don't really see a need for any other cases since a client can simply use a new IA if it wants more addresses in general. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, July 24, 2001 6:42 PM To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses My memory is that we've come to consensus that the client doesn't get to specify what kind of addresses it wants; the client sends an IA to the server and the server's response is determined by the server's admin policies. - Ralph At 05:57 PM 7/18/2001 -0500, Bernie Volz (EUD) wrote: >Regarding a new option to handle Temporary Addresses, I think this has >merit simply because there has been no way for a client to communicate >what kind of addresses it wants. Having this option provides that mechanism. >Alternatives, such as allowing 'num-addrs' and thus some address information >(T bit) to be specified by the client in a Request were discussed at one >point but did not make it into the -19 draft and I'm not sure if it would be >in the -20. > >Perhaps Ralph and Jim will care to provide some indication of how this >will be >resolved in the -20 draft - to give the client some ability to communicate to >the server what it needs. OR, perhaps the answer is simply "no, we're not >going to support it - it is up to the server to figure it out." ------_=_NextPart_001_01C11495.AAD89D90 Content-Type: text/html; charset="iso-8859-1" RE: Simplify release and decline of addresses

The issues you have are:

- What if multiple servers are involved. A client only wants a new temporary address,
but gets a boatload of other addresses. Perhaps it releases them (but then if we don't
allow the selective release ...). This adds extra processing overhead to client and
server.

- This imposes additional requirements on a server. If a server gets a new IA, does
it automatically assume well that client already has <n> non-temporary addresses, so
just give it <y> more temporary addresses. What if a server doesn't have this policy
and keeps giving the client more and more non-temporary addresses as well? We need to
make sure we reflect that as a requirement to server implementators. Again a client
culd release those it doesn't want (assuming selective release allowed) but again
that adds extra processing overhead to both client and server.

- All I think we really need is "I want addresses (of whatever type the server is
willing to give" and "I want temporary addresses only". I don't really see a need
for any other cases since a client can simply use a new IA if it wants more addresses
in general.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, July 24, 2001 6:42 PM
To: DHCPv6 discussion list
Subject: RE: Simplify release and decline of addresses


My memory is that we've come to consensus that the client doesn't get to
specify what kind of addresses it wants; the client sends an IA to the
server and the server's response is determined by the server's admin policies.

- Ralph

At 05:57 PM 7/18/2001 -0500, Bernie Volz (EUD) wrote:

>Regarding a new option to handle Temporary Addresses, I think this has
>merit simply because there has been no way for a client to communicate
>what kind of addresses it wants. Having this option provides that mechanism.
>Alternatives, such as allowing 'num-addrs' and thus some address information
>(T bit) to be specified by the client in a Request were discussed at one
>point but did not make it into the -19 draft and I'm not sure if it would be
>in the -20.
>
>Perhaps Ralph and Jim will care to provide some indication of how this
>will be
>resolved in the -20 draft - to give the client some ability to communicate to
>the server what it needs. OR, perhaps the answer is simply "no, we're not
>going to support it - it is up to the server to figure it out."


------_=_NextPart_001_01C11495.AAD89D90-- From owner-dhcp-v6@bucknell.edu Tue Jul 24 19:13:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00537; Tue, 24 Jul 2001 19:13:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6ONDW830820; Tue, 24 Jul 2001 19:13:32 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6ONDR810116 for ; Tue, 24 Jul 2001 19:13:27 -0400 (EDT) Received: from cisco.com (dhcp-161-44-149-168.cisco.com [161.44.149.168]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA19362 for ; Tue, 24 Jul 2001 19:13:12 -0400 (EDT) Message-ID: <3B5E00D9.56F734CF@cisco.com> Date: Tue, 24 Jul 2001 19:12:26 -0400 From: Josh Littlefield Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Re: Simplify release and decline of addresses References: <4.3.2.7.2.20010724183353.03443130@mail.bucknell.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Ralph, I'm surprised by this. I don't want to respond to the list, because I haven't been following this. I was trying to find notes back to the 3/14 teleconf here, which is the last time I was involved in a discussion about this, but haven't been able to do so. I thought the client who wanted both temporary and non-temporary addresses would use two IAs, asking for temps with one and not the other. How are you proposing a client get both kinds of addresses (the most common case, I believe)? Can this be done with one IA? I thought all the addrs for an IA were either temp or perm. Ralph Droms wrote: > My memory is that we've come to consensus that the client doesn't get to > specify what kind of addresses it wants; the client sends an IA to the > server and the server's response is determined by the server's admin policies. > > - Ralph > > At 05:57 PM 7/18/2001 -0500, Bernie Volz (EUD) wrote: > > >Regarding a new option to handle Temporary Addresses, I think this has > >merit simply because there has been no way for a client to communicate > >what kind of addresses it wants. Having this option provides that mechanism. > >Alternatives, such as allowing 'num-addrs' and thus some address information > >(T bit) to be specified by the client in a Request were discussed at one > >point but did not make it into the -19 draft and I'm not sure if it would be > >in the -20. > > > >Perhaps Ralph and Jim will care to provide some indication of how this > >will be > >resolved in the -20 draft - to give the client some ability to communicate to > >the server what it needs. OR, perhaps the answer is simply "no, we're not > >going to support it - it is up to the server to figure it out." -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 From owner-dhcp-v6@bucknell.edu Tue Jul 24 19:16:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA00628; Tue, 24 Jul 2001 19:16:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6ONGo808872; Tue, 24 Jul 2001 19:16:50 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6ONGa811097 for ; Tue, 24 Jul 2001 19:16:36 -0400 (EDT) Received: from cisco.com (dhcp-161-44-149-168.cisco.com [161.44.149.168]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA19572 for ; Tue, 24 Jul 2001 19:16:21 -0400 (EDT) Message-ID: <3B5E0196.F123D62A@cisco.com> Date: Tue, 24 Jul 2001 19:15:35 -0400 From: Josh Littlefield Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Re: Simplify release and decline of addresses References: <4.3.2.7.2.20010724183353.03443130@mail.bucknell.edu> <3B5E00D9.56F734CF@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Well, so much for not replying to the list... (Damn mail clients). Just hold your tomatoes and be kind in replying if I'm way off-base here. -josh Josh Littlefield wrote: > Ralph, I'm surprised by this. I don't want to respond to the list, because I > haven't been following this. I was trying to find notes back to the 3/14 teleconf > here, which is the last time I was involved in a discussion about this, but > haven't been able to do so. > > I thought the client who wanted both temporary and non-temporary addresses would > use two IAs, asking for temps with one and not the other. How are you proposing a > client get both kinds of addresses (the most common case, I believe)? Can this be > done with one IA? I thought all the addrs for an IA were either temp or perm. > > Ralph Droms wrote: > > > My memory is that we've come to consensus that the client doesn't get to > > specify what kind of addresses it wants; the client sends an IA to the > > server and the server's response is determined by the server's admin policies. > > > > - Ralph > > > > At 05:57 PM 7/18/2001 -0500, Bernie Volz (EUD) wrote: > > > > >Regarding a new option to handle Temporary Addresses, I think this has > > >merit simply because there has been no way for a client to communicate > > >what kind of addresses it wants. Having this option provides that mechanism. > > >Alternatives, such as allowing 'num-addrs' and thus some address information > > >(T bit) to be specified by the client in a Request were discussed at one > > >point but did not make it into the -19 draft and I'm not sure if it would be > > >in the -20. > > > > > >Perhaps Ralph and Jim will care to provide some indication of how this > > >will be > > >resolved in the -20 draft - to give the client some ability to communicate to > > >the server what it needs. OR, perhaps the answer is simply "no, we're not > > >going to support it - it is up to the server to figure it out." > > -- > ===================================================================== > Josh Littlefield Cisco Systems, Inc. > joshl@cisco.com 250 Apollo Drive > tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 From owner-dhcp-v6@bucknell.edu Tue Jul 24 20:14:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02589; Tue, 24 Jul 2001 20:14:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P0Eu805035; Tue, 24 Jul 2001 20:14:57 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6P0Em822593 for ; Tue, 24 Jul 2001 20:14:48 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6P0ALf27317 for ; Tue, 24 Jul 2001 17:10:21 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6P09og00383 for ; Tue, 24 Jul 2001 17:09:50 -0700 (MST) Message-Id: <200107250009.f6P09og00383@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Simplify release and decline of addresses In-Reply-To: Message from Josh Littlefield of "Tue, 24 Jul 2001 19:12:26 -0400." <3B5E00D9.56F734CF@cisco.com> Date: Tue, 24 Jul 2001 17:09:50 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I thought the client who wanted both temporary and non-temporary > addresses would use two IAs, asking for temps with one and not the > other. How are you proposing a client get both kinds of addresses > (the most common case, I believe)? Can this be done with one IA? I > thought all the addrs for an IA were either temp or perm. That is my recollection as well. I remember that we went around on whether to have a special "temporary" IA as well. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 24 23:55:16 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11083; Tue, 24 Jul 2001 23:55:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P3tS831666; Tue, 24 Jul 2001 23:55:28 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P3tF802610 for ; Tue, 24 Jul 2001 23:55:15 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA24368; Tue, 24 Jul 2001 23:55:15 -0400 Date: Tue, 24 Jul 2001 23:55:14 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Simplify release and decline of addresses In-Reply-To: <4.3.2.7.2.20010724183353.03443130@mail.bucknell.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I support Ralphs recollection too. /jim On Tue, 24 Jul 2001, Ralph Droms wrote: > My memory is that we've come to consensus that the client doesn't get to > specify what kind of addresses it wants; the client sends an IA to the > server and the server's response is determined by the server's admin policies. > > - Ralph > > At 05:57 PM 7/18/2001 -0500, Bernie Volz (EUD) wrote: > > >Regarding a new option to handle Temporary Addresses, I think this has > >merit simply because there has been no way for a client to communicate > >what kind of addresses it wants. Having this option provides that mechanism. > >Alternatives, such as allowing 'num-addrs' and thus some address information > >(T bit) to be specified by the client in a Request were discussed at one > >point but did not make it into the -19 draft and I'm not sure if it would be > >in the -20. > > > >Perhaps Ralph and Jim will care to provide some indication of how this > >will be > >resolved in the -20 draft - to give the client some ability to communicate to > >the server what it needs. OR, perhaps the answer is simply "no, we're not > >going to support it - it is up to the server to figure it out." > > > From owner-dhcp-v6@bucknell.edu Tue Jul 24 23:57:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11240; Tue, 24 Jul 2001 23:57:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P3vq801114; Tue, 24 Jul 2001 23:57:52 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P3vc801676 for ; Tue, 24 Jul 2001 23:57:38 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA25232; Tue, 24 Jul 2001 23:57:38 -0400 Date: Tue, 24 Jul 2001 23:57:38 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: Simplify release and decline of addresses In-Reply-To: <3B5E00D9.56F734CF@cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Josh, A client can have 10 addresses for one IA. 3 of them could be temporary. /jim On Tue, 24 Jul 2001, Josh Littlefield wrote: > Ralph, I'm surprised by this. I don't want to respond to the list, because I > haven't been following this. I was trying to find notes back to the 3/14 teleconf > here, which is the last time I was involved in a discussion about this, but > haven't been able to do so. > > I thought the client who wanted both temporary and non-temporary addresses would > use two IAs, asking for temps with one and not the other. How are you proposing a > client get both kinds of addresses (the most common case, I believe)? Can this be > done with one IA? I thought all the addrs for an IA were either temp or perm. > > Ralph Droms wrote: > > > My memory is that we've come to consensus that the client doesn't get to > > specify what kind of addresses it wants; the client sends an IA to the > > server and the server's response is determined by the server's admin policies. > > > > - Ralph > > > > At 05:57 PM 7/18/2001 -0500, Bernie Volz (EUD) wrote: > > > > >Regarding a new option to handle Temporary Addresses, I think this has > > >merit simply because there has been no way for a client to communicate > > >what kind of addresses it wants. Having this option provides that mechanism. > > >Alternatives, such as allowing 'num-addrs' and thus some address information > > >(T bit) to be specified by the client in a Request were discussed at one > > >point but did not make it into the -19 draft and I'm not sure if it would be > > >in the -20. > > > > > >Perhaps Ralph and Jim will care to provide some indication of how this > > >will be > > >resolved in the -20 draft - to give the client some ability to communicate to > > >the server what it needs. OR, perhaps the answer is simply "no, we're not > > >going to support it - it is up to the server to figure it out." > > -- > ===================================================================== > Josh Littlefield Cisco Systems, Inc. > joshl@cisco.com 250 Apollo Drive > tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 > From owner-dhcp-v6@bucknell.edu Tue Jul 24 23:59:29 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA11303; Tue, 24 Jul 2001 23:59:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P3xr832594; Tue, 24 Jul 2001 23:59:53 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P3xe801882 for ; Tue, 24 Jul 2001 23:59:40 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA25007; Tue, 24 Jul 2001 23:59:39 -0400 Date: Tue, 24 Jul 2001 23:59:39 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: Simplify release and decline of addresses In-Reply-To: <200107250009.f6P09og00383@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Not mine. an IA is for an interface. an interface has x addresses. x(1) and x(4) could be temporary where all others are permanent. we agreed to this to keep it simple for first work on private addresses. /jim On Tue, 24 Jul 2001, Ted Lemon wrote: > > > I thought the client who wanted both temporary and non-temporary > > addresses would use two IAs, asking for temps with one and not the > > other. How are you proposing a client get both kinds of addresses > > (the most common case, I believe)? Can this be done with one IA? I > > thought all the addrs for an IA were either temp or perm. > > That is my recollection as well. I remember that we went around on > whether to have a special "temporary" IA as well. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Wed Jul 25 00:02:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11452; Wed, 25 Jul 2001 00:02:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P430803628; Wed, 25 Jul 2001 00:03:00 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P42p800086 for ; Wed, 25 Jul 2001 00:02:51 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA23787; Wed, 25 Jul 2001 00:02:51 -0400 Date: Wed, 25 Jul 2001 00:02:51 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: Simplify release and decline of addresses In-Reply-To: <200107250009.f6P09og00383@grosse.bisbee.fugue.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN also the consensus was when we agreed to provide the T bit for an address within an IA set of addresses. But default. Rather than explicitly. We had the T bit above all addresses at one point which would have required an IA for T bit address set. But people barfed on that at the Minneapolis meeting. Also I would argue this is not a problem either. And in accordance with the spirit of using private addresses. Also having servers keep extra IAs for yet another derivation has to be justified and no one did that either. /jim On Tue, 24 Jul 2001, Ted Lemon wrote: > > > I thought the client who wanted both temporary and non-temporary > > addresses would use two IAs, asking for temps with one and not the > > other. How are you proposing a client get both kinds of addresses > > (the most common case, I believe)? Can this be done with one IA? I > > thought all the addrs for an IA were either temp or perm. > > That is my recollection as well. I remember that we went around on > whether to have a special "temporary" IA as well. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Wed Jul 25 00:17:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA11950; Wed, 25 Jul 2001 00:17:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P4Hd832561; Wed, 25 Jul 2001 00:17:39 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6P4HW811530 for ; Wed, 25 Jul 2001 00:17:32 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA25898; Wed, 25 Jul 2001 00:17:32 -0400 Date: Wed, 25 Jul 2001 00:17:32 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Use of Relays with DHCPv6 In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Folks, This is just a personal comment and concern. I think it fine that we use IPv6 multicast for our msgs in DHCPv6. I think it wonderful we use the relay-forward and relay-reply too. I also think it wise we made sure that the client can use unicast for request messages (confirm is in question now for sure). But I caution the working group to not overload the relay with state or server type functions as a MANDATORY REQUIREMENT, but as MAY REQUIREMENT. Also in todays maket typically organizations run dhcp servers for multiple sites. This will be true for the traditional wireline communications with dhcpv6 too. But at access points to the Internet for wireless and broadband for IPv6 and for IP Telephony the dhcpv6 server in most cases will be on the same link (good news for all you server and dhcp software vendors I predict more boxes will get sold becaue of this with dhcpv6). The reason is locality of reference to obtain an address for these type devices. The operators for this infrastructure will maintain tight control for performance reasons and avoid excessive network traffic routing where ever possible. Ergo dhcp relays. So its imperative that our abstraction work very well for implementors where a relay may never be used OR a sys admin wants the clients to unicast directly when possible to the server. I will look carefully at this as Ralph and I absorb this last round of input into the last call draft after London meeting. I will do my best to do that before London of course. /jim From owner-dhcp-v4@bucknell.edu Wed Jul 25 16:14:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02400 for ; Wed, 25 Jul 2001 16:14:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6PKBC805398; Wed, 25 Jul 2001 16:11:13 -0400 (EDT) Received: from homer.incognito.com. (HOMER.INCOGNITO.COM [207.102.214.21]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6PKB5806406 for ; Wed, 25 Jul 2001 16:11:05 -0400 (EDT) Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id ; Wed, 25 Jul 2001 13:11:32 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198EF34@homer.incognito.com.> From: "Kostur, Andre" To: DHCPv4 discussion list Subject: draft-ietf-dhc-agent-vpn-id-00.txt and -dhc-vpn-option-00.txt Date: Wed, 25 Jul 2001 13:11:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11545.FF75EE10" Reply-To: Andre@incognito.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11545.FF75EE10 Content-Type: text/plain; charset="iso-8859-1" These two Drafts don't agree on what should happen if both the option and the sub-option are specified. dhc-agnet-vpn-id says MUST (p. 5) and dhc-vpn-option says SHOULD (p. 3). These two drafts should have the same term for this... :) ------_=_NextPart_001_01C11545.FF75EE10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable draft-ietf-dhc-agent-vpn-id-00.txt and = -dhc-vpn-option-00.txt

These two Drafts don't agree on what should happen if = both the option and the sub-option are specified.  = dhc-agnet-vpn-id says MUST (p. 5) and dhc-vpn-option says SHOULD (p. = 3).  These two drafts should have the same term for this... = :)

------_=_NextPart_001_01C11545.FF75EE10-- From owner-dhcp-v4@bucknell.edu Wed Jul 25 17:32:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11096 for ; Wed, 25 Jul 2001 17:32:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6PLTx830157; Wed, 25 Jul 2001 17:29:59 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6PLTu830408 for ; Wed, 25 Jul 2001 17:29:56 -0400 (EDT) Received: from KKINNEAR-W2K.cisco.com (dhcp-161-44-149-111.cisco.com [161.44.149.111]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA11319; Wed, 25 Jul 2001 17:29:39 -0400 (EDT) Message-Id: <4.3.2.7.2.20010725173058.02239bc0@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 25 Jul 2001 17:31:20 -0400 To: DHCPv4 discussion list From: Kim Kinnear Subject: Re: draft-ietf-dhc-agent-vpn-id-00.txt and -dhc-vpn-option-00.txt Cc: kkinnear@cisco.com, raj@cisco.com In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198EF34@homer.incognito.com.> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I hate it when that happens... We'll try to get it together next time around. So does anyone have a strong opinion? I think it should be MUST, as I cannot imagine a useful situation where the relay agent would not be more "trusted" to know the vpn information than the client itself, but ... now that I think about it, I suppose a DHCP proxy on a VPN could want to allocate IP addresses on another VPN (or not on a VPN at all) in order to satisfy other clients. That would seem to say that SHOULD would be more appropriate. It also points up that there is no value for the vpn-id sub-option which could be used to specify the default or global vpn (i.e., no vpn). No option doesn't exactly indicate the global VPN if you get competition between a client and a relay agent. While I would be surprised if this "dueling vpn-id" stuff ever really amounts to much in practice, I think we could: 1. Fix both drafts to say the relay agent vpn-id SHOULD take precedence over the normal vpn-id option if they both appear. 2. Enhance the option definition value of both of the options to allow specification of "no" vpn, and specify that this would be used when there was a possibility of conflict. Comments? Cheers -- Kim At 01:11 PM 7/25/2001 -0700, Kostur, Andre wrote: >These two Drafts don't agree on what should happen if both the option and the sub-option are specified. dhc-agnet-vpn-id says MUST (p. 5) and dhc-vpn-option says SHOULD (p. 3). These two drafts should have the same term for this... :) From owner-dhcp-v6@bucknell.edu Thu Jul 26 13:57:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26931; Thu, 26 Jul 2001 13:57:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QHvt822464; Thu, 26 Jul 2001 13:57:55 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QHvo829776 for ; Thu, 26 Jul 2001 13:57:50 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6QHvZ525200 for ; Thu, 26 Jul 2001 12:57:35 -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 f6QHvZX21117 for ; Thu, 26 Jul 2001 12:57:35 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 26 12:57:34 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 12:57:34 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B332C@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: 15.2.1, Creation & Sending of Reconfigure-init messages Date: Thu, 26 Jul 2001 12:57:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C115FC.70F6AA00" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C115FC.70F6AA00 Content-Type: text/plain; charset="iso-8859-1" Ralph: I was not intending to specify an order - I should have made it a bulleted list, not a numbered list. Perhaps it is best that the draft does not specify an order? Though I guess stating that a server SHOULD use a configured address over any other mechanism would be good? - Bernie -----Original Message----- From: Droms Ralph [mailto:rdroms@cisco.com] Sent: Thursday, July 26, 2001 1:43 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: RE: 15.2.1, Creation & Sending of Reconfigure-init messages I agree that the server may be able to use an address obtained through some other mechanism to contact the client. I think that behavior should be captured explicitly in the list of alternatives. Bernie - is your list intended to imply a priority ordering or should we tweak the text a little to indicate that the server can use, according to local policy, any of the alternatives? - Ralph At 09:04 PM 7/19/2001 -0500, Bernie Volz (EUD) wrote: >Jim: > >Agreed that if a server has been pre-configured with an address (or >learns of it some other way), it can communicate. I'm just talking >about the general case here - where the server has not been pre-configured >with that information. The server *HAS* talked to the client in the past >since otherwise it would not care to reconfigure it (again, if some >configuration information is present, it can talk to *ANY* client). > >- Bernie > >-----Original Message----- >From: Jim Bound [mailto:seamus@bit-net.com] >Sent: Thursday, July 19, 2001 9:29 PM >To: DHCPv6 discussion list >Subject: Re: 15.2.1, Creation & Sending of Reconfigure-init messages > >I don't agree with number 3. A server who never gave the client its >address or even talkd to it can send a reconfigure-init to it. How it >knew the clients address is implementation defined. This behavior is >important. > >/jim > >On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote: > > > I believe Section 15.2.1 of -19 needs some edits. > > > > It says: > > > > The server unicasts the Reconfigure-init message to one client. The > > server may unicast Reconfigure-init messages to more than one client > > concurrently; for example, to reliably reconfigure all known clients, > > the server will unicast a Reconfigure-init message to each client. > > > > Can we specify this a bit more tightly. What does "server unicasts" > > mean? Does that mean directly to the client? > > > > Well, consider that the server may not be able to do this. Why? > > 1) If the server did not assign any addresses to the client (just gave > > it configuration information), how does it know how to contact the > > client directly? All it may have is the client's link local address > > (and the relay's address if relayed). > > 2) If the server did assign addresses, it may be that those addresses > > are not of sufficient scope for the server to use to reach the client > > directly. Even if they are, which address should it use (this may be > > less of an issue but what if the preferred lifetimes have all elapsed > > and the client may have removed the address - or *MUST* a client retain > > the address until the valid lifetime expires?). > > > > Therefore, I would suggest that the text be revised to indicate HOW > > the server unicasts. > > > > I suggest the following text: > > > > The server unicasts to the client by using one of the following > > methods: > > 1) If the client is on one of the server's interfaces, the clients > > link local address is used. (The client's link local address must > > have been saved from a previous communication from the client.) > > 2) If the client has been assigned an address of sufficient scope > > for the server to use in communicating with it and that address > > is still preferred, this address MAY be used. > > 3) Otherwise, the Reconfigure-Init should be unicast to a relay > > agent (as a Relay-reply) and that relay will unicast it to the > > client's link local address. (The client's link local address and > > the relay's address must have been saved from a previous communication > > from the client; or a suiteable relay agent's address is known by > > some mechanism by the server.) > > > > BTW, there may be 4 (or more correctly, it should be 2.5) ... if the > > client has unicast a packet directly to the server (because of the > > Server Unicast Option, Section 18.10), the server could save that > > address and use it. However, if the server did not assign this address, > > it may have no information about the validity of that address and > > therefore I did not include it. > > > > > Bernie Volz > > > Chief Technical Officer - DNS & DHCP Development Unit > > > Ericsson, Inc. > > > Tel: +1-508-875-3162 > > > Fax: +1-508-875-3018 > > > Mobile: +1-617-513-9060 > > > mailto:bernie.volz@ericsson.com > > > > > > > > ------_=_NextPart_001_01C115FC.70F6AA00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: 15.2.1, Creation & Sending of Reconfigure-init = messages

Ralph:

I was not intending to specify an order - I should = have made it a bulleted list,
not a numbered list.

Perhaps it is best that the draft does not specify an = order? Though I guess stating
that a server SHOULD use a configured address over = any other mechanism would
be good?

- Bernie

-----Original Message-----
From: Droms Ralph [mailto:rdroms@cisco.com]
Sent: Thursday, July 26, 2001 1:43 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: RE: 15.2.1, Creation & Sending of = Reconfigure-init messages


I agree that the server may be able to use an address = obtained through some
other mechanism to contact the client.  I think = that behavior should be
captured explicitly in the list of = alternatives.

Bernie - is your list intended to imply a priority = ordering or should we
tweak the text a little to indicate that the server = can use, according to
local policy, any of the alternatives?

- Ralph

At 09:04 PM 7/19/2001 -0500, Bernie Volz (EUD) = wrote:

>Jim:
>
>Agreed that if a server has been pre-configured = with an address (or
>learns of it some other way), it can = communicate. I'm just talking
>about the general case here - where the server = has not been pre-configured
>with that information. The server *HAS* talked = to the client in the past
>since otherwise it would not care to reconfigure = it (again, if some
>configuration information is present, it can = talk to *ANY* client).
>
>- Bernie
>
>-----Original Message-----
>From: Jim Bound [<mailto:seamus@bit-net.com>mailto:seamus@bit-net.com]=
>Sent: Thursday, July 19, 2001 9:29 PM
>To: DHCPv6 discussion list
>Subject: Re: 15.2.1, Creation & Sending of = Reconfigure-init messages
>
>I don't agree with number 3.  A server who = never gave the client its
>address or even talkd to it can send a = reconfigure-init to it.  How it
>knew the clients address is implementation = defined.  This behavior is
>important.
>
>/jim
>
>On Thu, 19 Jul 2001, Bernie Volz (EUD) = wrote:
>
> > I believe Section 15.2.1 of -19 needs some = edits.
> >
> > It says:
> >
> >    The server unicasts the = Reconfigure-init message to one client.  The
> >    server may unicast = Reconfigure-init messages to more than one client
> >    concurrently; for = example, to reliably reconfigure all known clients,
> >    the server will unicast = a Reconfigure-init message to each client.
> >
> > Can we specify this a bit more tightly. = What does "server unicasts"
> > mean? Does that mean directly to the = client?
> >
> > Well, consider that the server may not be = able to do this. Why?
> > 1) If the server did not assign any = addresses to the client (just gave
> > it configuration information), how does it = know how to contact the
> > client directly? All it may have is the = client's link local address
> > (and the relay's address if = relayed).
> > 2) If the server did assign addresses, it = may be that those addresses
> > are not of sufficient scope for the server = to use to reach the client
> > directly. Even if they are, which address = should it use (this may be
> > less of an issue but what if the preferred = lifetimes have all elapsed
> > and the client may have removed the = address - or *MUST* a client retain
> > the address until the valid lifetime = expires?).
> >
> > Therefore, I would suggest that the text = be revised to indicate HOW
> > the server unicasts.
> >
> > I suggest the following text:
> >
> >   The server unicasts to the = client by using one of the following
> >   methods:
> >   1) If the client is on one of = the server's interfaces, the clients
> >   link local address is used. = (The client's link local address must
> >   have been saved from a = previous communication from the client.)
> >   2) If the client has been = assigned an address of sufficient scope
> >   for the server to use in = communicating with it and that address
> >   is still preferred, this = address MAY be used.
> >   3) Otherwise, the = Reconfigure-Init should be unicast to a relay
> >   agent (as a Relay-reply) and = that relay will unicast it to the
> >   client's link local address. = (The client's link local address and
> >   the relay's address must have = been saved from a previous communication
> >   from the client; or a = suiteable relay agent's address is known by
> >   some mechanism by the = server.)
> >
> > BTW, there may be 4 (or more correctly, it = should be 2.5) ... if the
> > client has unicast a packet directly to = the server (because of the
> > Server Unicast Option, Section 18.10), the = server could save that
> > address and use it. However, if the server = did not assign this address,
> > it may have no information about the = validity of that address and
> > therefore I did not include it.
> >
> > > Bernie Volz
> > > Chief Technical Officer - DNS & = DHCP Development Unit
> > > Ericsson, Inc.
> > > Tel: +1-508-875-3162
> > > Fax: +1-508-875-3018
> > > Mobile: +1-617-513-9060
> > > <mailto:bernie.volz@ericsson.com= >mailto:bernie.volz@ericsson.com=
> > >
> > >
> >

------_=_NextPart_001_01C115FC.70F6AA00-- From owner-dhcp-v6@bucknell.edu Thu Jul 26 13:59:40 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27183; Thu, 26 Jul 2001 13:59:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QFuV826399; Thu, 26 Jul 2001 11:56:31 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QFuT831326 for ; Thu, 26 Jul 2001 11:56:29 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA17351; Thu, 26 Jul 2001 11:56:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726114016.00b5c1e8@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 11:54:52 -0400 To: DHCPv6 discussion list From: Droms Ralph Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B3325@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 09:18 AM 7/26/2001 -0500, Bernie Volz (EUD) wrote: >The new text works for me. OK... >Regarding your other issue: >"In the middle of writing my previous message, I had the following thought: >suppose the link has been renumbered - the addresses in the IA will be >invalid although the client has remained connected to the same link..." > >Isn't this a violation of the address lifetimes? If the lifetimes are >maintained properly, this should never happen. Right - but this behavior is mandated in DHCPv4 (well, I guess RFC2131 isn't exactly clear about a DHCPNAK in response to DHCPRENEW), even though it constitutes a violation of the lease. Perhaps the difference is that a "lease" constitutes an agreement about a period of time during which a server will not reassign an address, while a "lifetime" describes a period of time during which an address will be valid on a link. >And, what's the impact? Won't the server send a NoPrefixMatch in this case >because the client's prefixes aren't valid - though the client is still on >the same link? In that case, the client will simply either believe the >NoPrefixMatch and go through Solicit/Advertise or it will ignore the >NoPrefixMatch in which case the lifetimes will expire the address anyway. Yeah, but the client may well be unable to exchange IPv6 datagrams because it's insisting on using addresses that aren't valid until the lifetimes expire. - Ralph From owner-dhcp-v6@BUCKNELL.EDU Thu Jul 26 14:01:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA27370; Thu, 26 Jul 2001 14:01:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QCWO806350; Thu, 26 Jul 2001 08:32:24 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QCWB807661 for ; Thu, 26 Jul 2001 08:32:11 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn2-48.cisco.com [10.21.112.48]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA25130; Thu, 26 Jul 2001 08:31:54 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726082817.03a2eb28@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 08:30:34 -0400 To: DHCPv6 discussion list From: Droms Ralph Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B32BE@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@BUCKNELL.EDU Sender: owner-dhcp-v6@BUCKNELL.EDU X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In the middle of writing my previous message, I had the following thought: suppose the link has been renumbered - the addresses in the IA will be invalid although the client has remained connected to the same link... - Ralph At 10:01 AM 7/18/2001 -0500, Bernie Volz (EUD) wrote: >3) Add to Section 14.3.5. (Receipt of Reply message in response > to a Request, Confirm, Renew or Rebind message): > > When the client receives a NoPrefixMatch error status in the IA status > field of a Reply to a Confirm message, the client MUST make a > determination as to whether it has moved to a different link. If the > client is unable to make such a determination it MUST assume that it > has moved to a new link. In this case the client MAY discard the IA > that received the NoPrefixMatch status, or may retain it as long as > the addresses in the IA continue to be valid. From owner-dhcp-v6@bucknell.edu Thu Jul 26 14:22:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00743; Thu, 26 Jul 2001 14:22:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QCTX803680; Thu, 26 Jul 2001 08:29:33 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QCTU808160 for ; Thu, 26 Jul 2001 08:29:30 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn2-48.cisco.com [10.21.112.48]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA24912; Thu, 26 Jul 2001 08:29:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726081031.03a2b7d8@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 08:27:53 -0400 To: DHCPv6 discussion list From: Droms Ralph Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] Cc: DHCPv6 discussion list In-Reply-To: <200107192117.f6JLH6X00699@grosse.bisbee.fugue.com> References: <4.3.2.7.2.20010719164251.03868f98@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 02:17 PM 7/19/2001 -0700, Ted Lemon wrote: > > Why should the client make a determination about moving to a new link? In > > fact, how can it make that determination at this point, which is, I think, > > after the point at which the client may have received an event from its > > interface about loss of carrier, change of access point, etc.? I suggest > > the following text: > >This is the multiple overlapping link layers problem - a 3G cell phone >that is able to contact two different cell towers. The client in this >case has information that the server does not have, and is probably >talking to more than one server, and therefore is in a position to >know that it can continue to use its addresses. OK, now I get it. I misunderstood the phrase "whether it has moved to a different link." In some sense, if the client is communicating with overlapping links, it has, in fact, moved to a new link. It is still on the old link, as well... Is it more that the client can determine, through some other means, that the addresses in an IA are valid although some server - through misconfiguration, overlapping links, ??? - has indicated that the addresses are not valid? I suggest the following text in section 14.3.5 (rev -19): When the client receives a NoPrefixMatch error status in the IA status field of a Reply to a Confirm, Rebind or Renew message, if the client can determine through some other means that the addresses in the IA are valid for the link to which the interface is attached, the client MAY choose to ignore the NoPrefixMatch error. Examples of ways a client can determine the validity are: examining prefixes in router advertisements, receipt of a Confirm message from a different server that indicates validity of the addresses in the IA, link-layer specific mechanisms through which the client can determine that it is currently connected to the link for which the client previously determined that the addresses in the IA were valid. After receiving a NoPrefixMatch error status in the IA status field of a Reply to a Confirm, Rebind or Renew message, if the client cannot independently determine that the addresses in the IA are still valid, the client MUST NOT use any of the addresses in the IA. - Ralph From owner-dhcp-v6@bucknell.edu Thu Jul 26 14:22:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00810; Thu, 26 Jul 2001 14:22:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QGKb804081; Thu, 26 Jul 2001 12:20:37 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QGKW800328 for ; Thu, 26 Jul 2001 12:20:32 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6QGKH506305 for ; Thu, 26 Jul 2001 11:20:17 -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 f6QGKHU24465 for ; Thu, 26 Jul 2001 11:20:17 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Jul 26 11:20:16 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 11:20:17 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B332A@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 26 Jul 2001 11:20:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C115EE.D9B5BAD0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C115EE.D9B5BAD0 Content-Type: text/plain; charset="iso-8859-1" >Yeah, but the client may well be unable to exchange IPv6 datagrams because >it's insisting on using addresses that aren't valid until the lifetimes expire. Not much we can do about it though is there? While a "fix" for this case could be to make a client not use the addresses if it gets a NoPrefixMatch, that may be wrong in other situations. I believe that we want to encourage a client to assume that it has changed links or something pretty drastic has happened when it receives a NoPrefixMatch, but we want to leave an out that says a client MAY take other actions if it has information that the NoPrefixMatch might be in error (such as it is now on an "overlapping" link, it has received other information, such as Router Advertisements, that validate the addresses or some of the addresses, or perhaps it otherwise believes the NoPrefixMatch message to be in error [such as sent by an unauthorized server]). >Yeah, but the client may well be unable to exchange IPv6 datagrams because >it's insisting on using addresses that aren't valid until the lifetimes expire. Hopefully the client will figure out something's wrong because of ICMP errors it receives or because of its inability to communicate? [Perhaps this is further input to the client in making its determination that the link has changed.] But, if not, then it will recover once the preferred lifetime expires since it won't be able to "renew" the lifetimes. - Bernie -----Original Message----- From: Droms Ralph [mailto:rdroms@cisco.com] Sent: Thursday, July 26, 2001 11:55 AM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] At 09:18 AM 7/26/2001 -0500, Bernie Volz (EUD) wrote: >The new text works for me. OK... >Regarding your other issue: >"In the middle of writing my previous message, I had the following thought: >suppose the link has been renumbered - the addresses in the IA will be >invalid although the client has remained connected to the same link..." > >Isn't this a violation of the address lifetimes? If the lifetimes are >maintained properly, this should never happen. Right - but this behavior is mandated in DHCPv4 (well, I guess RFC2131 isn't exactly clear about a DHCPNAK in response to DHCPRENEW), even though it constitutes a violation of the lease. Perhaps the difference is that a "lease" constitutes an agreement about a period of time during which a server will not reassign an address, while a "lifetime" describes a period of time during which an address will be valid on a link. >And, what's the impact? Won't the server send a NoPrefixMatch in this case >because the client's prefixes aren't valid - though the client is still on >the same link? In that case, the client will simply either believe the >NoPrefixMatch and go through Solicit/Advertise or it will ignore the >NoPrefixMatch in which case the lifetimes will expire the address anyway. Yeah, but the client may well be unable to exchange IPv6 datagrams because it's insisting on using addresses that aren't valid until the lifetimes expire. - Ralph ------_=_NextPart_001_01C115EE.D9B5BAD0 Content-Type: text/html; charset="iso-8859-1" RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

>Yeah, but the client may well be unable to exchange IPv6 datagrams because
>it's insisting on using addresses that aren't valid until the lifetimes expire.

Not much we can do about it though is there?

While a "fix" for this case could be to make a client not use the addresses if it
gets a NoPrefixMatch, that may be wrong in other situations.

I believe that we want to encourage a client to assume that it has changed links
or something pretty drastic has happened when it receives a NoPrefixMatch, but we
want to leave an out that says a client MAY take other actions if it has
information that the NoPrefixMatch might be in error (such as it is now on an
"overlapping" link, it has received other information, such as Router Advertisements,
that validate the addresses or some of the addresses, or perhaps it otherwise
believes the NoPrefixMatch message to be in error [such as sent by an unauthorized
server]).

>Yeah, but the client may well be unable to exchange IPv6 datagrams because
>it's insisting on using addresses that aren't valid until the lifetimes expire.

Hopefully the client will figure out something's wrong because of ICMP errors it
receives or because of its inability to communicate? [Perhaps this is further input
to the client in making its determination that the link has changed.] But, if not,
then it will recover once the preferred lifetime expires since it won't be able to
"renew" the lifetimes.

- Bernie

-----Original Message-----
From: Droms Ralph [mailto:rdroms@cisco.com]
Sent: Thursday, July 26, 2001 11:55 AM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]


At 09:18 AM 7/26/2001 -0500, Bernie Volz (EUD) wrote:

>The new text works for me.

OK...


>Regarding your other issue:
>"In the middle of writing my previous message, I had the following thought:
>suppose the link has been renumbered - the addresses in the IA will be
>invalid although the client has remained connected to the same link..."
>
>Isn't this a violation of the address lifetimes? If the lifetimes are
>maintained properly, this should never happen.

Right - but this behavior is mandated in DHCPv4 (well, I guess RFC2131
isn't exactly clear about a DHCPNAK in response to DHCPRENEW), even though
it constitutes a violation of the lease.  Perhaps the difference is that a
"lease" constitutes an agreement about a period of time during which a
server will not reassign an address, while a "lifetime" describes a period
of time during which an address will be valid on a link.

>And, what's the impact? Won't the server send a NoPrefixMatch in this case
>because the client's prefixes aren't valid - though the client is still on
>the same link? In that case, the client will simply either believe the
>NoPrefixMatch and go through Solicit/Advertise or it will ignore the
>NoPrefixMatch in which case the lifetimes will expire the address anyway.

Yeah, but the client may well be unable to exchange IPv6 datagrams because
it's insisting on using addresses that aren't valid until the lifetimes expire.

- Ralph


------_=_NextPart_001_01C115EE.D9B5BAD0-- From owner-dhcp-v6@bucknell.edu Thu Jul 26 14:22:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00841; Thu, 26 Jul 2001 14:22:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QEJA800418; Thu, 26 Jul 2001 10:19:10 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QEJ0831799 for ; Thu, 26 Jul 2001 10:19:00 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6QEIi506876 for ; Thu, 26 Jul 2001 09:18:44 -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 f6QEIiU11337 for ; Thu, 26 Jul 2001 09:18:44 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Jul 26 09:18:43 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 09:18:43 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3325@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Thu, 26 Jul 2001 09:18:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C115DD.DFA32010" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C115DD.DFA32010 Content-Type: text/plain; charset="iso-8859-1" Ralph, et al: The new text works for me. Regarding your other issue: "In the middle of writing my previous message, I had the following thought: suppose the link has been renumbered - the addresses in the IA will be invalid although the client has remained connected to the same link..." Isn't this a violation of the address lifetimes? If the lifetimes are maintained properly, this should never happen. And, what's the impact? Won't the server send a NoPrefixMatch in this case because the client's prefixes aren't valid - though the client is still on the same link? In that case, the client will simply either believe the NoPrefixMatch and go through Solicit/Advertise or it will ignore the NoPrefixMatch in which case the lifetimes will expire the address anyway. Note: There will probably be instances because of clock differences where a client may still believe an address to be valid when it truely is not. But that condition should only last for short periods of time and it is adviseable that there be some "grace" involved in lifetimes. - Bernie -----Original Message----- From: Droms Ralph [mailto:rdroms@cisco.com] Sent: Thursday, July 26, 2001 8:28 AM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] At 02:17 PM 7/19/2001 -0700, Ted Lemon wrote: > > Why should the client make a determination about moving to a new link? In > > fact, how can it make that determination at this point, which is, I think, > > after the point at which the client may have received an event from its > > interface about loss of carrier, change of access point, etc.? I suggest > > the following text: > >This is the multiple overlapping link layers problem - a 3G cell phone >that is able to contact two different cell towers. The client in this >case has information that the server does not have, and is probably >talking to more than one server, and therefore is in a position to >know that it can continue to use its addresses. OK, now I get it. I misunderstood the phrase "whether it has moved to a different link." In some sense, if the client is communicating with overlapping links, it has, in fact, moved to a new link. It is still on the old link, as well... Is it more that the client can determine, through some other means, that the addresses in an IA are valid although some server - through misconfiguration, overlapping links, ??? - has indicated that the addresses are not valid? I suggest the following text in section 14.3.5 (rev -19): When the client receives a NoPrefixMatch error status in the IA status field of a Reply to a Confirm, Rebind or Renew message, if the client can determine through some other means that the addresses in the IA are valid for the link to which the interface is attached, the client MAY choose to ignore the NoPrefixMatch error. Examples of ways a client can determine the validity are: examining prefixes in router advertisements, receipt of a Confirm message from a different server that indicates validity of the addresses in the IA, link-layer specific mechanisms through which the client can determine that it is currently connected to the link for which the client previously determined that the addresses in the IA were valid. After receiving a NoPrefixMatch error status in the IA status field of a Reply to a Confirm, Rebind or Renew message, if the client cannot independently determine that the addresses in the IA are still valid, the client MUST NOT use any of the addresses in the IA. - Ralph ------_=_NextPart_001_01C115DD.DFA32010 Content-Type: text/html; charset="iso-8859-1" RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

Ralph, et al:

The new text works for me.

Regarding your other issue:
"In the middle of writing my previous message, I had the following thought:
suppose the link has been renumbered - the addresses in the IA will be
invalid although the client has remained connected to the same link..."

Isn't this a violation of the address lifetimes? If the lifetimes are
maintained properly, this should never happen.

And, what's the impact? Won't the server send a NoPrefixMatch in this case
because the client's prefixes aren't valid - though the client is still on
the same link? In that case, the client will simply either believe the
NoPrefixMatch and go through Solicit/Advertise or it will ignore the
NoPrefixMatch in which case the lifetimes will expire the address anyway.

Note: There will probably be instances because of clock differences where
a client may still believe an address to be valid when it truely is not.
But that condition should only last for short periods of time and it is
adviseable that there be some "grace" involved in lifetimes.

- Bernie

-----Original Message-----
From: Droms Ralph [mailto:rdroms@cisco.com]
Sent: Thursday, July 26, 2001 8:28 AM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]


At 02:17 PM 7/19/2001 -0700, Ted Lemon wrote:

> > Why should the client make a determination about moving to a new link?  In
> > fact, how can it make that determination at this point, which is, I think,
> > after the point at which the client may have received an event from its
> > interface about loss of carrier, change of access point, etc.?  I suggest
> > the following text:
>
>This is the multiple overlapping link layers problem - a 3G cell phone
>that is able to contact two different cell towers.  The client in this
>case has information that the server does not have, and is probably
>talking to more than one server, and therefore is in a position to
>know that it can continue to use its addresses.

OK, now I get it.  I misunderstood the phrase "whether it has moved to a
different link."  In some sense, if the client is communicating with
overlapping links, it has, in fact, moved to a new link.  It is still on
the old link, as well...

Is it more that the client can determine, through some other means, that
the addresses in an IA are valid although some server - through
misconfiguration, overlapping links, ??? - has indicated that the addresses
are not valid?  I suggest the following text in section 14.3.5 (rev -19):

    When the client receives a NoPrefixMatch error status in the IA status
    field of a Reply to a Confirm, Rebind or Renew message, if the client
    can determine through some other means that the addresses in the IA
    are valid for the link to which the interface is attached, the client
    MAY choose to ignore the NoPrefixMatch error.  Examples of ways a client
    can determine the validity are: examining prefixes in router
    advertisements, receipt of a Confirm message from a different server
    that indicates validity of the addresses in the IA, link-layer
    specific mechanisms through which the client can determine that it
    is currently connected to the link for which the client previously
    determined that the addresses in the IA were valid.

    After receiving a NoPrefixMatch error status in the IA status
    field of a Reply to a Confirm, Rebind or Renew message, if the client
    cannot independently determine that the addresses in the IA are still
    valid, the client MUST NOT use any of the addresses in the IA.

- Ralph


------_=_NextPart_001_01C115DD.DFA32010-- From owner-dhcp-v4@bucknell.edu Thu Jul 26 14:29:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA01508 for ; Thu, 26 Jul 2001 14:29:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QEOq802151; Thu, 26 Jul 2001 10:24:53 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QEOc805420 for ; Thu, 26 Jul 2001 10:24: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 f6QEObp26159 for ; Thu, 26 Jul 2001 09:24: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 f6QEObb24049 for ; Thu, 26 Jul 2001 09:24:37 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Jul 26 09:24:36 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 09:24:37 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3327@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Cc: raj@cisco.com Subject: RE: draft-ietf-dhc-agent-vpn-id-00.txt and -dhc-vpn-option-00.txt Date: Thu, 26 Jul 2001 09:24:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C115DE.B2A5AE10" Reply-To: Bernie.Volz@am1.ericsson.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C115DE.B2A5AE10 Content-Type: text/plain; charset="iso-8859-1" Kim: While not having looked at the latest version of either draft, I think SHOULD is better. Isn't this really a server implementation/policy issue? Server should be allowed to believe whatever it feels is better or appropriate. Regarding the 2nd issue ("no" vpn), that does seem like a reasonable enhancement. - Bernie -----Original Message----- From: Kim Kinnear [mailto:kkinnear@cisco.com] Sent: Wednesday, July 25, 2001 5:31 PM To: DHCPv4 discussion list Cc: kkinnear@cisco.com; raj@cisco.com Subject: Re: draft-ietf-dhc-agent-vpn-id-00.txt and -dhc-vpn-option-00.txt I hate it when that happens... We'll try to get it together next time around. So does anyone have a strong opinion? I think it should be MUST, as I cannot imagine a useful situation where the relay agent would not be more "trusted" to know the vpn information than the client itself, but ... now that I think about it, I suppose a DHCP proxy on a VPN could want to allocate IP addresses on another VPN (or not on a VPN at all) in order to satisfy other clients. That would seem to say that SHOULD would be more appropriate. It also points up that there is no value for the vpn-id sub-option which could be used to specify the default or global vpn (i.e., no vpn). No option doesn't exactly indicate the global VPN if you get competition between a client and a relay agent. While I would be surprised if this "dueling vpn-id" stuff ever really amounts to much in practice, I think we could: 1. Fix both drafts to say the relay agent vpn-id SHOULD take precedence over the normal vpn-id option if they both appear. 2. Enhance the option definition value of both of the options to allow specification of "no" vpn, and specify that this would be used when there was a possibility of conflict. Comments? Cheers -- Kim At 01:11 PM 7/25/2001 -0700, Kostur, Andre wrote: >These two Drafts don't agree on what should happen if both the option and the sub-option are specified. dhc-agnet-vpn-id says MUST (p. 5) and dhc-vpn-option says SHOULD (p. 3). These two drafts should have the same term for this... :) ------_=_NextPart_001_01C115DE.B2A5AE10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-ietf-dhc-agent-vpn-id-00.txt and = -dhc-vpn-option-00.txt

Kim:

While not having looked at the latest version of = either draft, I think SHOULD is better.
Isn't this really a server implementation/policy = issue? Server should be allowed to
believe whatever it feels is better or = appropriate.

Regarding the 2nd issue ("no" vpn), that = does seem like a reasonable enhancement.

- Bernie

-----Original Message-----
From: Kim Kinnear [mailto:kkinnear@cisco.com]=
Sent: Wednesday, July 25, 2001 5:31 PM
To: DHCPv4 discussion list
Cc: kkinnear@cisco.com; raj@cisco.com
Subject: Re: draft-ietf-dhc-agent-vpn-id-00.txt = and
-dhc-vpn-option-00.txt



I hate it when that happens...

We'll try to get it together next time around.

So does anyone have a strong opinion?

I think it should be MUST, as I cannot imagine a = useful situation
where the relay agent would not be more = "trusted" to know the vpn
information than the client itself, but ...  = now that I think
about it, I suppose a DHCP proxy on a VPN could want = to allocate
IP addresses on another VPN (or not on a VPN at all) = in order to
satisfy other clients.

That would seem to say that SHOULD would be more = appropriate.

It also points up that there is no value for the = vpn-id sub-option
which could be used to specify the default or global = vpn (i.e.,
no vpn).  No option doesn't exactly indicate = the global VPN if
you get competition between a client and a relay = agent.

While I would be surprised if this "dueling = vpn-id" stuff ever
really amounts to much in practice, I think we = could:

  1.  Fix both drafts to say the relay = agent vpn-id SHOULD take
  precedence over the normal vpn-id option if = they both appear.

  2.  Enhance the option definition value = of both of the options
  to allow specification of "no" vpn, = and specify that this would
  be used when there was a possibility of = conflict.

Comments?

Cheers -- Kim



At 01:11 PM 7/25/2001 -0700, Kostur, Andre = wrote:

>These two Drafts don't agree on what should = happen if both the option and the sub-option are specified.  = dhc-agnet-vpn-id says MUST (p. 5) and dhc-vpn-option says SHOULD (p. = 3).  These two drafts should have the same term for this... = :)

------_=_NextPart_001_01C115DE.B2A5AE10-- From owner-dhcp-v6@bucknell.edu Thu Jul 26 14:36:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02052; Thu, 26 Jul 2001 14:36:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QIaM803807; Thu, 26 Jul 2001 14:36:22 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QIa7818080 for ; Thu, 26 Jul 2001 14:36:07 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6QIVZf01785 for ; Thu, 26 Jul 2001 11:31:35 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6QIa3Y00407 for ; Thu, 26 Jul 2001 11:36:03 -0700 (MST) Message-Id: <200107261836.f6QIa3Y00407@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from Droms Ralph of "Thu, 26 Jul 2001 08:27:53 -0400." <4.3.2.7.2.20010726081031.03a2b7d8@mail.bucknell.edu> Date: Thu, 26 Jul 2001 11:36:02 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Is it more that the client can determine, through some other means, that > the addresses in an IA are valid although some server - through > misconfiguration, overlapping links, ??? - has indicated that the addresses > are not valid? I suggest the following text in section 14.3.5 (rev -19): Your new text works for me. Thanks! _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 26 14:36:32 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02136; Thu, 26 Jul 2001 14:36:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QIav805056; Thu, 26 Jul 2001 14:36:57 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QIam807318 for ; Thu, 26 Jul 2001 14:36:48 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6QIWEf01789 for ; Thu, 26 Jul 2001 11:32:14 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6QIafY00417 for ; Thu, 26 Jul 2001 11:36:41 -0700 (MST) Message-Id: <200107261836.f6QIafY00417@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: Message from Droms Ralph of "Thu, 26 Jul 2001 08:30:34 -0400." <4.3.2.7.2.20010726082817.03a2eb28@mail.bucknell.edu> Date: Thu, 26 Jul 2001 11:36:41 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > In the middle of writing my previous message, I had the following thought: > suppose the link has been renumbered - the addresses in the IA will be > invalid although the client has remained connected to the same link... Good point. I think the language you just suggested accounts for this, though. _MelloN_ From owner-dhcp-v6@BUCKNELL.EDU Thu Jul 26 14:40:16 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02505; Thu, 26 Jul 2001 14:40:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QHiY823354; Thu, 26 Jul 2001 13:44:34 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QHiS822921 for ; Thu, 26 Jul 2001 13:44:28 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA01682; Thu, 26 Jul 2001 13:44:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726133943.039ec0f0@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 13:42:49 -0400 To: DHCPv6 discussion list From: Droms Ralph Subject: RE: 15.2.1, Creation & Sending of Reconfigure-init messages Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B32F3@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@BUCKNELL.EDU Sender: owner-dhcp-v6@BUCKNELL.EDU X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I agree that the server may be able to use an address obtained through some other mechanism to contact the client. I think that behavior should be captured explicitly in the list of alternatives. Bernie - is your list intended to imply a priority ordering or should we tweak the text a little to indicate that the server can use, according to local policy, any of the alternatives? - Ralph At 09:04 PM 7/19/2001 -0500, Bernie Volz (EUD) wrote: >Jim: > >Agreed that if a server has been pre-configured with an address (or >learns of it some other way), it can communicate. I'm just talking >about the general case here - where the server has not been pre-configured >with that information. The server *HAS* talked to the client in the past >since otherwise it would not care to reconfigure it (again, if some >configuration information is present, it can talk to *ANY* client). > >- Bernie > >-----Original Message----- >From: Jim Bound [mailto:seamus@bit-net.com] >Sent: Thursday, July 19, 2001 9:29 PM >To: DHCPv6 discussion list >Subject: Re: 15.2.1, Creation & Sending of Reconfigure-init messages > >I don't agree with number 3. A server who never gave the client its >address or even talkd to it can send a reconfigure-init to it. How it >knew the clients address is implementation defined. This behavior is >important. > >/jim > >On Thu, 19 Jul 2001, Bernie Volz (EUD) wrote: > > > I believe Section 15.2.1 of -19 needs some edits. > > > > It says: > > > > The server unicasts the Reconfigure-init message to one client. The > > server may unicast Reconfigure-init messages to more than one client > > concurrently; for example, to reliably reconfigure all known clients, > > the server will unicast a Reconfigure-init message to each client. > > > > Can we specify this a bit more tightly. What does "server unicasts" > > mean? Does that mean directly to the client? > > > > Well, consider that the server may not be able to do this. Why? > > 1) If the server did not assign any addresses to the client (just gave > > it configuration information), how does it know how to contact the > > client directly? All it may have is the client's link local address > > (and the relay's address if relayed). > > 2) If the server did assign addresses, it may be that those addresses > > are not of sufficient scope for the server to use to reach the client > > directly. Even if they are, which address should it use (this may be > > less of an issue but what if the preferred lifetimes have all elapsed > > and the client may have removed the address - or *MUST* a client retain > > the address until the valid lifetime expires?). > > > > Therefore, I would suggest that the text be revised to indicate HOW > > the server unicasts. > > > > I suggest the following text: > > > > The server unicasts to the client by using one of the following > > methods: > > 1) If the client is on one of the server's interfaces, the clients > > link local address is used. (The client's link local address must > > have been saved from a previous communication from the client.) > > 2) If the client has been assigned an address of sufficient scope > > for the server to use in communicating with it and that address > > is still preferred, this address MAY be used. > > 3) Otherwise, the Reconfigure-Init should be unicast to a relay > > agent (as a Relay-reply) and that relay will unicast it to the > > client's link local address. (The client's link local address and > > the relay's address must have been saved from a previous communication > > from the client; or a suiteable relay agent's address is known by > > some mechanism by the server.) > > > > BTW, there may be 4 (or more correctly, it should be 2.5) ... if the > > client has unicast a packet directly to the server (because of the > > Server Unicast Option, Section 18.10), the server could save that > > address and use it. However, if the server did not assign this address, > > it may have no information about the validity of that address and > > therefore I did not include it. > > > > > Bernie Volz > > > Chief Technical Officer - DNS & DHCP Development Unit > > > Ericsson, Inc. > > > Tel: +1-508-875-3162 > > > Fax: +1-508-875-3018 > > > Mobile: +1-617-513-9060 > > > mailto:bernie.volz@ericsson.com > > > > > > > > From owner-dhcp-v6@bucknell.edu Thu Jul 26 15:19:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05034; Thu, 26 Jul 2001 15:19:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QJJF818779; Thu, 26 Jul 2001 15:19:15 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QJJ8814266 for ; Thu, 26 Jul 2001 15:19:09 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA15072; Thu, 26 Jul 2001 15:18:52 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726151630.01d70210@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 15:17:30 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: A few additional items re: -19 draft Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B330D@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie - I don't understand your question. Can you explain what you mean by "client" and "allocate"? - Ralph At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: >- Should we consider a client prefix-selection option as >a base option to allow a "client" to allocate an address >for a prefix other than the one it might be on? Should >this be part of the base specification? > >Note: Perhaps these devices should just be Relays and use >the Relay-Forward. In this case, they can simply specify >that information via the relay-address field. And, if we >have the server use the IPv6 source address for sending >replies to the relay's, then this field (relay-address) >can even contain something that might not truly be an >address assigned to the relay. From owner-dhcp-v6@bucknell.edu Thu Jul 26 15:32:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05891; Thu, 26 Jul 2001 15:32:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QJX8812346; Thu, 26 Jul 2001 15:33:08 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QJWx828210 for ; Thu, 26 Jul 2001 15:32:59 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA16930; Thu, 26 Jul 2001 15:32:43 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726151935.01ee4168@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 15:31:22 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: A few additional items re: -19 draft Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B330D@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: >- For the Confirm message, Section 14. states: > >Confirm Confirm the validity of assigned addresses and other > configuration changes through the server from which the > configuration information was obtained when the client's > assigned addresses may not be valid; for example, when > the client reboots or loses its connection to a link Turns out you've pointed out redundant and conflicting text in -19. DHCPv6 messages are defined in section 7 and each definition includes a short description. There's no need to include a definition in section 14 as well. Here's the text from section 7: CONFIRM (4) The DHCP Confirm (or Confirm) message is used by clients to confirm that the addresses assigned to an IA and the lifetimes for those addresses, as well as the current configuration parameters assigned by the server to the client are still valid. Perhaps the easiest thing to do would be to constrain the Reply to a Confirm to be a binary response: ACK implies everything OK (no changes from the server; everything from the client used as currently known to the client); NAK implies client does a Request. Otherwise, we might get conflicting responses from multiple, non-coordinating servers, as you point out: >We probably need to clarify the behavior somewhat. For example, >if a server that did not give out the addresses responds, can >it: >- Allocate additional addresses (to the IA)? >- Extend the lifetimes of existing addresses? >- Change/respond with configuration parameters? Perhaps we might allow extension of address lifetimes, as this has been shown to work among multiple servers with DHCPv4 failover... >If the client does request (and supply) other options, what >happens if the server's reply does not include those options >(perhaps because the server doesn't feel it can supply them). > >I guess what I'm suggesting is that we indicate that allocation >of addresses and supplying configuration parameters with a >Confirm are problematic. And, that a client MUST NOT assume >that the lack of a configuration parameter (option) means >that the previous value for that option should be removed. > >Similar behavior might be required for Rebind - as multiple >servers may respond? Though I think there are fewer issues >here. > >Perhaps we should stress that Confirm SHOULD (MUST) only be >used to confirm whether addresses are valid and SHOULD NOT >(MUST NOT) be used in place of a Renew/Rebind?? Perhaps we >should even specifically state that clients MUST NOT apply >changes to the lifetimes or addition of new addresses received >in a Reply to a Confirm? From owner-dhcp-v6@bucknell.edu Thu Jul 26 15:37:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06221; Thu, 26 Jul 2001 15:37:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QJbb825607; Thu, 26 Jul 2001 15:37:37 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QJbW807673 for ; Thu, 26 Jul 2001 15:37:33 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA17478; Thu, 26 Jul 2001 15:37:17 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726153220.01ef6d40@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 15:33:49 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Advertise when no addresses available (was: Re: A few additional items re: -19 draft) Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B330D@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I vote for the server to not respond if it has no addresses available. - Ralph At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: >- When forming the Advertise in response to a Solicit, there >isn't any clear indication of what to do if no addresses may >be available for the client from that server at that time >(because all available addresses are in use). In particular, >should the server: >- Ignore the Solicit (in the hopes that by the time a subsequent > Solicit arrives, addresses may be available) >- Send the Advertise but without the IA option >- Send the Advertise with the IA option but with an error (such > as Unavail) >- Send the Advertise with the IA option with num-addrs = 0 > >Or, should a client be prepared to handle all of the above? From owner-dhcp-v6@bucknell.edu Thu Jul 26 15:37:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06247; Thu, 26 Jul 2001 15:37:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QJbm821271; Thu, 26 Jul 2001 15:37:48 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QJbX819561 for ; Thu, 26 Jul 2001 15:37:34 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA17484; Thu, 26 Jul 2001 15:37:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726153449.01eed7f8@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 15:35:56 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: A few additional items re: -19 draft Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B330D@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Why would the server send any options at all in a Reply to a Decline or Release message? Of course, if the server shouldn't send any options in those Reply messages, the spec should explicitly say so. - Ralph At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: >- For Reply messages to Decline and Release messages, >what should the server do about options (other than the >IA)? This may be less of a server issue but more of a >client issue. It probably makes little sense for the >server to include a "Domain Name Server option"? And >servers may want to provide a minimal message to save >bandwidth and processing overhead? I guess since we have >no idea what future options may be defined, the best >recommendations is that servers MUST send those options >explicitly requested by a client's ORO option; a server >MAY send other options (though clients are free to >ignore these extra options - as they normally are!). >Perhaps this is already implied by the options >processing (based on DHCPv4) but wouldn't it be best to >make it explicit? This same processing probably applies >to ALL option handling in any Reply to a client message. >Is it already in the draft and I missed it? From owner-dhcp-v6@bucknell.edu Thu Jul 26 15:48:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07181; Thu, 26 Jul 2001 15:48:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QJmx826496; Thu, 26 Jul 2001 15:48:59 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QJmw824969 for ; Thu, 26 Jul 2001 15:48:58 -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 f6QJmvp23379 for ; Thu, 26 Jul 2001 14:48: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 f6QJmv712114 for ; Thu, 26 Jul 2001 14:48:57 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Jul 26 14:48:57 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 14:48:56 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3332@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: A few additional items re: -19 draft Date: Thu, 26 Jul 2001 14:48:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1160C.0169BCD0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C1160C.0169BCD0 Content-Type: text/plain; charset="iso-8859-1" Let me try to clarify ... By client I meant something like a Network Access Server (Remote Access Server) that is acting as a DHCPv6 client on behalf of "real" clients (but those clients don't run DHCP but instead us some other means of obtaining addresses from the NAS/RAS). Perhaps this model doesn't apply to IPv6? (As I recall, the PPP over IPv6 document only allows negotation of a interface identifier. And, this probably contracts a lot of the IPv6 address configuration specifications.) Basically, I'm trying to forsee the situation where a device is using DHCPv6 on behalf of a "client" (not a DHCPv6 client) to obtain addresses for it. However, the link on which that device (which is the DHCPv6 client) is communicating with the DHCPv6 server (either directly or indirectly) is NOT the link on which it needs to obtain addresses for. Now, perhaps the argument in DHCPv6 would be that that device should act as a relay, but perhaps that adds one more level of complexity into the implementation that isn't needed or desired. A server always can have policy controls as to whether it will or will not accept that "Prefix Selection Option" or not. Does that help? Perhaps this is a useless request at this time if noone else feels there is any need (it can always be added later I guess like the subnet selection option was). - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, July 26, 2001 3:18 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: A few additional items re: -19 draft Bernie - I don't understand your question. Can you explain what you mean by "client" and "allocate"? - Ralph At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: >- Should we consider a client prefix-selection option as >a base option to allow a "client" to allocate an address >for a prefix other than the one it might be on? Should >this be part of the base specification? > >Note: Perhaps these devices should just be Relays and use >the Relay-Forward. In this case, they can simply specify >that information via the relay-address field. And, if we >have the server use the IPv6 source address for sending >replies to the relay's, then this field (relay-address) >can even contain something that might not truly be an >address assigned to the relay. ------_=_NextPart_001_01C1160C.0169BCD0 Content-Type: text/html; charset="iso-8859-1" RE: A few additional items re: -19 draft

Let me try to clarify ...

By client I meant something like a Network Access Server (Remote Access
Server) that is acting as a DHCPv6 client on behalf of "real" clients (but
those clients don't run DHCP but instead us some other means of obtaining
addresses from the NAS/RAS).

Perhaps this model doesn't apply to IPv6? (As I recall, the PPP over IPv6
document only allows negotation of a interface identifier. And, this probably
contracts a lot of the IPv6 address configuration specifications.)

Basically, I'm trying to forsee the situation where a device is using DHCPv6
on behalf of a "client" (not a DHCPv6 client) to obtain addresses for it.
However, the link on which that device (which is the DHCPv6 client) is
communicating with the DHCPv6 server (either directly or indirectly) is NOT
the link on which it needs to obtain addresses for.

Now, perhaps the argument in DHCPv6 would be that that device should act
as a relay, but perhaps that adds one more level of complexity into the
implementation that isn't needed or desired.

A server always can have policy controls as to whether it will or will not
accept that "Prefix Selection Option" or not.

Does that help? Perhaps this is a useless request at this time if noone
else feels there is any need (it can always be added later I guess like the
subnet selection option was).

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, July 26, 2001 3:18 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: A few additional items re: -19 draft


Bernie - I don't understand your question.  Can you explain what you mean
by "client" and "allocate"?

- Ralph

At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote:

>- Should we consider a client prefix-selection option as
>a base option to allow a "client" to allocate an address
>for a prefix other than the one it might be on? Should
>this be part of the base specification?
>
>Note: Perhaps these devices should just be Relays and use
>the Relay-Forward. In this case, they can simply specify
>that information via the relay-address field. And, if we
>have the server use the IPv6 source address for sending
>replies to the relay's, then this field (relay-address)
>can even contain something that might not truly be an
>address assigned to the relay.


------_=_NextPart_001_01C1160C.0169BCD0-- From owner-dhcp-v6@bucknell.edu Thu Jul 26 16:18:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09265; Thu, 26 Jul 2001 16:18:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QKIU802354; Thu, 26 Jul 2001 16:18:30 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QKIH829347 for ; Thu, 26 Jul 2001 16:18:17 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA22585; Thu, 26 Jul 2001 16:18:02 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726161512.01d797e0@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 16:16:40 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Prefix selection option (Was: RE: A few additional items re: -19 draft) Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B3332@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks for the clarification, Bernie. I suggest that this option can be considered separately at a later date. - Ralph At 02:48 PM 7/26/2001 -0500, Bernie Volz (EUD) wrote: >Let me try to clarify ... > >By client I meant something like a Network Access Server (Remote Access >Server) that is acting as a DHCPv6 client on behalf of "real" clients (but >those clients don't run DHCP but instead us some other means of obtaining >addresses from the NAS/RAS). > >Perhaps this model doesn't apply to IPv6? (As I recall, the PPP over IPv6 >document only allows negotation of a interface identifier. And, this probably >contracts a lot of the IPv6 address configuration specifications.) > >Basically, I'm trying to forsee the situation where a device is using DHCPv6 >on behalf of a "client" (not a DHCPv6 client) to obtain addresses for it. >However, the link on which that device (which is the DHCPv6 client) is >communicating with the DHCPv6 server (either directly or indirectly) is NOT >the link on which it needs to obtain addresses for. > >Now, perhaps the argument in DHCPv6 would be that that device should act >as a relay, but perhaps that adds one more level of complexity into the >implementation that isn't needed or desired. > >A server always can have policy controls as to whether it will or will not >accept that "Prefix Selection Option" or not. > >Does that help? Perhaps this is a useless request at this time if noone >else feels there is any need (it can always be added later I guess like the >subnet selection option was). > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, July 26, 2001 3:18 PM >To: DHCPv6 discussion list >Cc: DHCPv6 discussion list >Subject: Re: A few additional items re: -19 draft > >Bernie - I don't understand your question. Can you explain what you mean >by "client" and "allocate"? > >- Ralph > >At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: > > >- Should we consider a client prefix-selection option as > >a base option to allow a "client" to allocate an address > >for a prefix other than the one it might be on? Should > >this be part of the base specification? > > > >Note: Perhaps these devices should just be Relays and use > >the Relay-Forward. In this case, they can simply specify > >that information via the relay-address field. And, if we > >have the server use the IPv6 source address for sending > >replies to the relay's, then this field (relay-address) > >can even contain something that might not truly be an > >address assigned to the relay. From owner-dhcp-v6@bucknell.edu Thu Jul 26 16:26:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09670; Thu, 26 Jul 2001 16:26:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QKQJ805413; Thu, 26 Jul 2001 16:26:19 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QKQD819267 for ; Thu, 26 Jul 2001 16:26:13 -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 f6QKQDp13527 for ; Thu, 26 Jul 2001 15:26:13 -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 f6QKQC726257 for ; Thu, 26 Jul 2001 15:26:13 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 26 15:26:12 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 15:26:12 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3333@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: A few additional items re: -19 draft Date: Thu, 26 Jul 2001 15:01:50 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1160D.CF012830" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C1160D.CF012830 Content-Type: text/plain; charset="iso-8859-1" >There's no need to include a definition in section 14 as well. Great. Guess I didn't do a throughout enough saerch. Removing redundancy (especially when conflicting) is good. >Perhaps we might allow extension of address lifetimes, as this has been >shown to work among multiple servers with DHCPv4 failover... Hum ... Failover servers are kind of special since they generally share information. But consider if you have multiple servers that don't communicate with each other (and have the protections of the failover protocol), then you can't allow one to extend the lifetimes since the original server never learns of the extension and would potentially "reclaim" the addresses. So, I would say that only the server that gave out the addresses in the first place can extend them on a Confirm. Future extensions to DHCPv6 or special server-to-server communication protocols could alter this behavior in the future. Also, if you did allow *ANY* server to extend the lifetimes on a Confirm, does that mean the client should communicate with that new server when it is time to Renew? Or should it go back to "old" server (that gave it the addresses on a Request or previously Renewed)? - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, July 26, 2001 3:31 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: A few additional items re: -19 draft At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: >- For the Confirm message, Section 14. states: > >Confirm Confirm the validity of assigned addresses and other > configuration changes through the server from which the > configuration information was obtained when the client's > assigned addresses may not be valid; for example, when > the client reboots or loses its connection to a link Turns out you've pointed out redundant and conflicting text in -19. DHCPv6 messages are defined in section 7 and each definition includes a short description. There's no need to include a definition in section 14 as well. Here's the text from section 7: CONFIRM (4) The DHCP Confirm (or Confirm) message is used by clients to confirm that the addresses assigned to an IA and the lifetimes for those addresses, as well as the current configuration parameters assigned by the server to the client are still valid. Perhaps the easiest thing to do would be to constrain the Reply to a Confirm to be a binary response: ACK implies everything OK (no changes from the server; everything from the client used as currently known to the client); NAK implies client does a Request. Otherwise, we might get conflicting responses from multiple, non-coordinating servers, as you point out: >We probably need to clarify the behavior somewhat. For example, >if a server that did not give out the addresses responds, can >it: >- Allocate additional addresses (to the IA)? >- Extend the lifetimes of existing addresses? >- Change/respond with configuration parameters? Perhaps we might allow extension of address lifetimes, as this has been shown to work among multiple servers with DHCPv4 failover... >If the client does request (and supply) other options, what >happens if the server's reply does not include those options >(perhaps because the server doesn't feel it can supply them). > >I guess what I'm suggesting is that we indicate that allocation >of addresses and supplying configuration parameters with a >Confirm are problematic. And, that a client MUST NOT assume >that the lack of a configuration parameter (option) means >that the previous value for that option should be removed. > >Similar behavior might be required for Rebind - as multiple >servers may respond? Though I think there are fewer issues >here. > >Perhaps we should stress that Confirm SHOULD (MUST) only be >used to confirm whether addresses are valid and SHOULD NOT >(MUST NOT) be used in place of a Renew/Rebind?? Perhaps we >should even specifically state that clients MUST NOT apply >changes to the lifetimes or addition of new addresses received >in a Reply to a Confirm? ------_=_NextPart_001_01C1160D.CF012830 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: A few additional items re: -19 draft

>There's no need to include a definition in = section 14 as well.

Great. Guess I didn't do a throughout enough saerch. = Removing redundancy
(especially when conflicting) is good.

>Perhaps we might allow extension of address = lifetimes, as this has been
>shown to work among multiple servers with DHCPv4 = failover...

Hum ...

Failover servers are kind of special since they = generally share information.

But consider if you have multiple servers that don't = communicate with each
other (and have the protections of the failover = protocol), then you can't
allow one to extend the lifetimes since the original = server never learns of
the extension and would potentially = "reclaim" the addresses.

So, I would say that only the server that gave out = the addresses in the
first place can extend them on a Confirm. Future = extensions to DHCPv6 or
special server-to-server communication protocols = could alter this behavior
in the future.

Also, if you did allow *ANY* server to extend the = lifetimes on a Confirm,
does that mean the client should communicate with = that new server when it
is time to Renew? Or should it go back to = "old" server (that gave it the
addresses on a Request or previously = Renewed)?

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, July 26, 2001 3:31 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: A few additional items re: -19 = draft


At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) = wrote:

>- For the Confirm message, Section 14. = states:
>
>Confirm Confirm the validity of assigned = addresses and other
>        = configuration changes through the server from which the
>        = configuration information was obtained when the client's
>        = assigned addresses may not be valid; for example, when
>        the = client reboots or loses its connection to a link

Turns out you've pointed out redundant and = conflicting text in -19.  DHCPv6
messages are defined in section 7 and each = definition includes a short
description.  There's no need to include a = definition in section 14 as well.

Here's the text from section 7:

       CONFIRM = (4)          The DHCP = Confirm (or Confirm) message is used
          &nb= sp;           &nb= sp;     by clients to confirm that the = addresses
          &nb= sp;           &nb= sp;     assigned to an IA and the lifetimes = for
          &nb= sp;           &nb= sp;     those addresses, as well as the = current
          &nb= sp;           &nb= sp;     configuration parameters assigned by = the
          &nb= sp;           &nb= sp;     server to the client are still = valid.

Perhaps the easiest thing to do would be to constrain = the Reply to a
Confirm to be a binary response: ACK implies = everything OK (no changes from
the server; everything from the client used as = currently known to the
client); NAK implies client does a Request.  = Otherwise, we might get
conflicting responses from multiple, = non-coordinating servers, as you point
out:


>We probably need to clarify the behavior = somewhat. For example,
>if a server that did not give out the addresses = responds, can
>it:
>- Allocate additional addresses (to the = IA)?
>- Extend the lifetimes of existing = addresses?
>- Change/respond with configuration = parameters?

Perhaps we might allow extension of address = lifetimes, as this has been
shown to work among multiple servers with DHCPv4 = failover...


>If the client does request (and supply) other = options, what
>happens if the server's reply does not include = those options
>(perhaps because the server doesn't feel it can = supply them).
>
>I guess what I'm suggesting is that we indicate = that allocation
>of addresses and supplying configuration = parameters with a
>Confirm are problematic. And, that a client MUST = NOT assume
>that the lack of a configuration parameter = (option) means
>that the previous value for that option should = be removed.
>
>Similar behavior might be required for Rebind - = as multiple
>servers may respond? Though I think there are = fewer issues
>here.
>
>Perhaps we should stress that Confirm SHOULD = (MUST) only be
>used to confirm whether addresses are valid and = SHOULD NOT
>(MUST NOT) be used in place of a Renew/Rebind?? = Perhaps we
>should even specifically state that clients MUST = NOT apply
>changes to the lifetimes or addition of new = addresses received
>in a Reply to a Confirm?


------_=_NextPart_001_01C1160D.CF012830-- From owner-dhcp-v6@bucknell.edu Thu Jul 26 16:29:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09832; Thu, 26 Jul 2001 16:29:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QKTd806569; Thu, 26 Jul 2001 16:29:39 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QKTV828823 for ; Thu, 26 Jul 2001 16:29:31 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6QKTF509164 for ; Thu, 26 Jul 2001 15:29:15 -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 f6QKTFX13950 for ; Thu, 26 Jul 2001 15:29:15 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 26 15:29:14 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 15:29:14 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3334@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: A few additional items re: -19 draft Date: Thu, 26 Jul 2001 15:07:35 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1160E.9C65E040" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C1160E.9C65E040 Content-Type: text/plain; charset="iso-8859-1" Ralph ... that may be perfectly acceptable - especially with the options we have defined today. Of course, you probably do need the server to send back the IA option with the "success" code in it. Also, we should state that the client MUST NOT include the ORO option? We should allow future options to define different behavior (since they may be similar to the IA option). Here's a new issue ... I think the server should ALWAYS send back an IA option with *ALL* of the addresses that it believes the client still has after a DECLINE or RELEASE. Only if the server believes the client has no more addresses should it send back the IA option with num-addrs = 0. Now, if the Release/Decline FAILS, then the server should send back the IA option that the client sent with the error information. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, July 26, 2001 3:36 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Re: A few additional items re: -19 draft Why would the server send any options at all in a Reply to a Decline or Release message? Of course, if the server shouldn't send any options in those Reply messages, the spec should explicitly say so. - Ralph At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: >- For Reply messages to Decline and Release messages, >what should the server do about options (other than the >IA)? This may be less of a server issue but more of a >client issue. It probably makes little sense for the >server to include a "Domain Name Server option"? And >servers may want to provide a minimal message to save >bandwidth and processing overhead? I guess since we have >no idea what future options may be defined, the best >recommendations is that servers MUST send those options >explicitly requested by a client's ORO option; a server >MAY send other options (though clients are free to >ignore these extra options - as they normally are!). >Perhaps this is already implied by the options >processing (based on DHCPv4) but wouldn't it be best to >make it explicit? This same processing probably applies >to ALL option handling in any Reply to a client message. >Is it already in the draft and I missed it? ------_=_NextPart_001_01C1160E.9C65E040 Content-Type: text/html; charset="iso-8859-1" RE: A few additional items re: -19 draft

Ralph ... that may be perfectly acceptable - especially with the options we
have defined today. Of course, you probably do need the server to send back
the IA option with the "success" code in it. Also, we should state that the
client MUST NOT include the ORO option?

We should allow future options to define different behavior (since they may
be similar to the IA option).

Here's a new issue ... I think the server should ALWAYS send back an IA option
with *ALL* of the addresses that it believes the client still has after a
DECLINE or RELEASE. Only if the server believes the client has no more addresses
should it send back the IA option with num-addrs = 0.

Now, if the Release/Decline FAILS, then the server should send back the IA option
that the client sent with the error information.

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, July 26, 2001 3:36 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Re: A few additional items re: -19 draft


Why would the server send any options at all in a Reply to a Decline or
Release message?  Of course, if the server shouldn't send any options in
those Reply messages, the spec should explicitly say so.

- Ralph

At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote:
>- For Reply messages to Decline and Release messages,
>what should the server do about options (other than the
>IA)? This may be less of a server issue but more of a
>client issue. It probably makes little sense for the
>server to include a "Domain Name Server option"? And
>servers may want to provide a minimal message to save
>bandwidth and processing overhead? I guess since we have
>no idea what future options may be defined, the best
>recommendations is that servers MUST send those options
>explicitly requested by a client's ORO option; a server
>MAY send other options (though clients are free to
>ignore these extra options - as they normally are!).
>Perhaps this is already implied by the options
>processing (based on DHCPv4) but wouldn't it be best to
>make it explicit? This same processing probably applies
>to ALL option handling in any Reply to a client message.
>Is it already in the draft and I missed it?

------_=_NextPart_001_01C1160E.9C65E040-- From owner-dhcp-v6@bucknell.edu Thu Jul 26 16:34:56 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10237; Thu, 26 Jul 2001 16:34:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QKZA806859; Thu, 26 Jul 2001 16:35:10 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QKZ3801223 for ; Thu, 26 Jul 2001 16:35:03 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA24985; Thu, 26 Jul 2001 16:34:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726163113.01e4fa98@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 16:33:25 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Address lifetime extension and configuration changes in response to Confirm (Was: RE: A few additional items re: -19 draft) Cc: DHCPv6 discussion list In-Reply-To: <66F66129A77AD411B76200508B65AC697B3333@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie, you don't explicitly react to my proposal that the Reply to a Confirm should be a simple ACK/NAK. I infer that since you argue against even a simple address lifetime extension, you support the ACK/NAK model. Does my inference correctly reflect your opinion? - Ralph At 03:01 PM 7/26/2001 -0500, Bernie Volz (EUD) wrote: > >There's no need to include a definition in section 14 as well. > >Great. Guess I didn't do a throughout enough saerch. Removing redundancy >(especially when conflicting) is good. > > >Perhaps we might allow extension of address lifetimes, as this has been > >shown to work among multiple servers with DHCPv4 failover... > >Hum ... > >Failover servers are kind of special since they generally share information. > >But consider if you have multiple servers that don't communicate with each >other (and have the protections of the failover protocol), then you can't >allow one to extend the lifetimes since the original server never learns of >the extension and would potentially "reclaim" the addresses. > >So, I would say that only the server that gave out the addresses in the >first place can extend them on a Confirm. Future extensions to DHCPv6 or >special server-to-server communication protocols could alter this behavior >in the future. > >Also, if you did allow *ANY* server to extend the lifetimes on a Confirm, >does that mean the client should communicate with that new server when it >is time to Renew? Or should it go back to "old" server (that gave it the >addresses on a Request or previously Renewed)? > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, July 26, 2001 3:31 PM >To: DHCPv6 discussion list >Cc: DHCPv6 discussion list >Subject: Re: A few additional items re: -19 draft > >At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: > > >- For the Confirm message, Section 14. states: > > > >Confirm Confirm the validity of assigned addresses and other > > configuration changes through the server from which the > > configuration information was obtained when the client's > > assigned addresses may not be valid; for example, when > > the client reboots or loses its connection to a link > >Turns out you've pointed out redundant and conflicting text in -19. DHCPv6 >messages are defined in section 7 and each definition includes a short >description. There's no need to include a definition in section 14 as well. > >Here's the text from section 7: > > CONFIRM (4) The DHCP Confirm (or Confirm) message is used > by clients to confirm that the addresses > assigned to an IA and the lifetimes for > those addresses, as well as the current > configuration parameters assigned by the > server to the client are still valid. > >Perhaps the easiest thing to do would be to constrain the Reply to a >Confirm to be a binary response: ACK implies everything OK (no changes from >the server; everything from the client used as currently known to the >client); NAK implies client does a Request. Otherwise, we might get >conflicting responses from multiple, non-coordinating servers, as you point >out: > > >We probably need to clarify the behavior somewhat. For example, > >if a server that did not give out the addresses responds, can > >it: > >- Allocate additional addresses (to the IA)? > >- Extend the lifetimes of existing addresses? > >- Change/respond with configuration parameters? > >Perhaps we might allow extension of address lifetimes, as this has been >shown to work among multiple servers with DHCPv4 failover... > > >If the client does request (and supply) other options, what > >happens if the server's reply does not include those options > >(perhaps because the server doesn't feel it can supply them). > > > >I guess what I'm suggesting is that we indicate that allocation > >of addresses and supplying configuration parameters with a > >Confirm are problematic. And, that a client MUST NOT assume > >that the lack of a configuration parameter (option) means > >that the previous value for that option should be removed. > > > >Similar behavior might be required for Rebind - as multiple > >servers may respond? Though I think there are fewer issues > >here. > > > >Perhaps we should stress that Confirm SHOULD (MUST) only be > >used to confirm whether addresses are valid and SHOULD NOT > >(MUST NOT) be used in place of a Renew/Rebind?? Perhaps we > >should even specifically state that clients MUST NOT apply > >changes to the lifetimes or addition of new addresses received > >in a Reply to a Confirm? From owner-dhcp-v6@bucknell.edu Thu Jul 26 16:46:15 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10879; Thu, 26 Jul 2001 16:46:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QKjB812615; Thu, 26 Jul 2001 16:45:11 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QKiv811225 for ; Thu, 26 Jul 2001 16:44:58 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA26319 for ; Thu, 26 Jul 2001 16:44:32 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726162845.00b80ff8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 16:43:13 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Addresses and other parameters in Advertise and Solicit Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie Volz wrote: >1. In Section 14.3.1 (Creation and sending of Request messages), there > is no mention of using any of the "information" supplied by a > server in the Advertise message (in response to a Solicit). In > DHCPv4, the client sent information received in the Offer. We > probably should be explicit about this and perhaps even suggest > that the information received by a client in an Advertise is > basically for information purposes only to help it determine > whether this server will offer it what it needs. So, are you suggesting that the DHCPv6 client Request exactly the addresses and options from the Solicit, or no addresses or options, or ??? > Perhaps the > addresses assigned in the Advertise should even just be prefixes > (interface portion all 0's)? I don't have a strong feeling one way or the other. > If instead we want the server to assign "real" addresses, should > something be said about how long those should be valid and whether the > server should attempt to assign those same addresses to the client in > a subsequent Request/Reply exchange for the IA? Perhaps we could punt > and say this is a server implementation issue (whether it assigns real > addresses and whether those are held for some (short) time for the > client)? I take "valid" in this context to mean "reserved for this client". Has this scenario been a problem in DHCPv4? Do we need to specify any more mechanism than we have in the DHCPv4 spec? > NOTE: If real addresses are returned, perhaps a client might even > initiate DAD during the Request/Reply in which case it can do these > two items in parallel (though this would be somewhat tricky since it > would not want to Decline the addresses before receiving the Reply). Hm. I guess I had anticipated that the client would do DAD and either Request or Decline the addresses in the Advertise. It is the case that the spec does not constrain the times at which a Decline can be sent. I'm not sure it makes much sense for the client to Request a set of addresses and then Decline them later. - Ralph From owner-dhcp-v6@bucknell.edu Thu Jul 26 16:49:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11055; Thu, 26 Jul 2001 16:49:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QKoA808470; Thu, 26 Jul 2001 16:50:10 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QKo2809800 for ; Thu, 26 Jul 2001 16:50:02 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA26922 for ; Thu, 26 Jul 2001 16:49:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726164752.01e4ea88@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 16:48:28 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Tweak to text for Advertise message Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie Volz wrote: >- Section 13.4.2 (Creation and sending of Advertise messages) does not >even say anything about the ORO option that a client might have >specified. Shouldn't we indicate that the Advertise message SHOULD >include options for all OROs that were included in the Solicit if the >server is willing/capable of offering a value for that option? Right; text to be added. - Ralph From owner-dhcp-v6@bucknell.edu Thu Jul 26 16:57:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11525; Thu, 26 Jul 2001 16:57:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QKvp815613; Thu, 26 Jul 2001 16:57:51 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QKvh817678 for ; Thu, 26 Jul 2001 16:57:43 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA27935 for ; Thu, 26 Jul 2001 16:57:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726165442.01e61d18@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 16:56:08 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Tweak to text in 14.3.1 of rev -19 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie Volz wrote: >2. In Section 14.3.1, we should perhaps explicitly indicate that the > client should add an ORO option (it now says "The client adds any > appropriate options" ... but in many cases that just means an ORO > option with appropriate options specified in that option. I don't think the extra text is necessary; if you suggest some changes we can consider the specific text... - Ralph From owner-dhcp-v6@bucknell.edu Thu Jul 26 17:00:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11734; Thu, 26 Jul 2001 17:00:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QL0X816536; Thu, 26 Jul 2001 17:00:33 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QL0L813543 for ; Thu, 26 Jul 2001 17:00:21 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA28270 for ; Thu, 26 Jul 2001 17:00:05 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726165642.01e4f658@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 16:57:27 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: "Fast handshake" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie Volz wrote: > During the WG / Design Team (I forget which, if not both) we did > discuss designing a "quick" handshake for allowing a client to > assign an address. I would assume we'd define a new option that the > client could use to communicate to the server that it is doing > this. Would we use Solicit/Advertise or Request/Reply for this (in > many ways, Request/Reply seems like a better mechanism - the > Request could simply leave the "server address" field as all 0's > and that could even be the flag to the server). Perhaps we decided > to defer this for now and do it later? I suggest we defer this mechanism for now. - Ralph From owner-dhcp-v6@bucknell.edu Thu Jul 26 17:00:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11776; Thu, 26 Jul 2001 17:00:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QL0f818822; Thu, 26 Jul 2001 17:00:41 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QL0M831840 for ; Thu, 26 Jul 2001 17:00:22 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA28273 for ; Thu, 26 Jul 2001 17:00:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20010726165740.01e5d838@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 26 Jul 2001 16:58:45 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Advertising prefixes rather than addresses Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie Volz wrote: > At another time we also discussed using the server to just > advertise prefixes and allowing the client to generate the > addresses? What about adding a "P" bit (next to the "T"-temporary > bit) to indicate that this is a prefix from which the client should > generate an address (or simply allowing it to do so if the > link-identifier field is all 0's). Sounds like a reasonable idea - anyone have a strong reaction (either positive or negative)? - Ralph From owner-dhcp-v6@bucknell.edu Thu Jul 26 17:14:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12609; Thu, 26 Jul 2001 17:14:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QLEm825605; Thu, 26 Jul 2001 17:14:48 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QLEZ824509 for ; Thu, 26 Jul 2001 17:14:35 -0400 (EDT) Received: from cisco.com (dhcp-161-44-149-147.cisco.com [161.44.149.147]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA29857 for ; Thu, 26 Jul 2001 17:14:20 -0400 (EDT) Message-ID: <3B6087FC.F8B8C942@cisco.com> Date: Thu, 26 Jul 2001 17:13:33 -0400 From: Josh Littlefield Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Re: Advertising prefixes rather than addresses References: <4.3.2.7.2.20010726165740.01e5d838@funnel.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I used to think this was a reasonable idea. But I thought it was killed by this group a while ago as unnecessary. If you want stateless autoconfig, then use that and not DHCP. If the router advertisement tells you to do stateful autoconfig (DHCP), then having DHCP tell you to do stateless autoconfig on a prefix (essentially this proposal) doesn't seem right. The server can always just generate for a client the address it would generate for itself (supposedly on some subset of the allowable prefixes). Ralph Droms wrote: > Bernie Volz wrote: > > > At another time we also discussed using the server to just > > advertise prefixes and allowing the client to generate the > > addresses? What about adding a "P" bit (next to the "T"-temporary > > bit) to indicate that this is a prefix from which the client should > > generate an address (or simply allowing it to do so if the > > link-identifier field is all 0's). > > Sounds like a reasonable idea - anyone have a strong reaction (either > positive or negative)? > > - Ralph -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 From owner-dhcp-v6@bucknell.edu Thu Jul 26 17:19:08 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12907; Thu, 26 Jul 2001 17:19:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QLJK801214; Thu, 26 Jul 2001 17:19:20 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QLJ4827317 for ; Thu, 26 Jul 2001 17:19:04 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id OAA76842 for ; Thu, 26 Jul 2001 14:09:56 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Thu, 26 Jul 2001 14:09:56 -0700 (PDT) From: Bernard Aboba To: DHCPv6 discussion list Subject: Re: Advertising prefixes rather than addresses In-Reply-To: <3B6087FC.F8B8C942@cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is just duplicating functionality that is already in stateless autoconfig. Presumably you'd use DHCPv6 for addressing if you wanted to do it statefully. So I don't see the need or purpose of this. > > Bernie Volz wrote: > > > > > At another time we also discussed using the server to just > > > advertise prefixes and allowing the client to generate the > > > addresses? What about adding a "P" bit (next to the "T"-temporary > > > bit) to indicate that this is a prefix from which the client should > > > generate an address (or simply allowing it to do so if the > > > link-identifier field is all 0's). > > > > Sounds like a reasonable idea - anyone have a strong reaction (either > > positive or negative)? > > > > - Ralph From owner-dhcp-v6@bucknell.edu Thu Jul 26 17:22:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13071; Thu, 26 Jul 2001 17:22:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QLMJ802841; Thu, 26 Jul 2001 17:22:19 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QLME822374 for ; Thu, 26 Jul 2001 17:22:14 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6QLLw501516 for ; Thu, 26 Jul 2001 16:21:59 -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 f6QLLwX09700 for ; Thu, 26 Jul 2001 16:21:58 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 26 16:21:58 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 16:21:57 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3335@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Address lifetime extension and configuration changes in respo nse to Confirm (Was: RE: A few additional items re: -19 draft) Date: Thu, 26 Jul 2001 16:21:56 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11618.FFB717E0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11618.FFB717E0 Content-Type: text/plain; charset="iso-8859-1" Sorry ... I do think that a simple ACK / NAK sequence would be best. By NAK I assume we mean "NoPrefixMatch" type error. By ACK I assume we mean "the prefixes you're using are valid for the link" (no indication of whether the addresses themselves are). I think that's all the Confirm needs to say since I believe all it was intended to communicate was whether the client was still on the same link. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, July 26, 2001 4:33 PM To: DHCPv6 discussion list Cc: DHCPv6 discussion list Subject: Address lifetime extension and configuration changes in response to Confirm (Was: RE: A few additional items re: -19 draft) Bernie, you don't explicitly react to my proposal that the Reply to a Confirm should be a simple ACK/NAK. I infer that since you argue against even a simple address lifetime extension, you support the ACK/NAK model. Does my inference correctly reflect your opinion? - Ralph At 03:01 PM 7/26/2001 -0500, Bernie Volz (EUD) wrote: > >There's no need to include a definition in section 14 as well. > >Great. Guess I didn't do a throughout enough saerch. Removing redundancy >(especially when conflicting) is good. > > >Perhaps we might allow extension of address lifetimes, as this has been > >shown to work among multiple servers with DHCPv4 failover... > >Hum ... > >Failover servers are kind of special since they generally share information. > >But consider if you have multiple servers that don't communicate with each >other (and have the protections of the failover protocol), then you can't >allow one to extend the lifetimes since the original server never learns of >the extension and would potentially "reclaim" the addresses. > >So, I would say that only the server that gave out the addresses in the >first place can extend them on a Confirm. Future extensions to DHCPv6 or >special server-to-server communication protocols could alter this behavior >in the future. > >Also, if you did allow *ANY* server to extend the lifetimes on a Confirm, >does that mean the client should communicate with that new server when it >is time to Renew? Or should it go back to "old" server (that gave it the >addresses on a Request or previously Renewed)? > >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, July 26, 2001 3:31 PM >To: DHCPv6 discussion list >Cc: DHCPv6 discussion list >Subject: Re: A few additional items re: -19 draft > >At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: > > >- For the Confirm message, Section 14. states: > > > >Confirm Confirm the validity of assigned addresses and other > > configuration changes through the server from which the > > configuration information was obtained when the client's > > assigned addresses may not be valid; for example, when > > the client reboots or loses its connection to a link > >Turns out you've pointed out redundant and conflicting text in -19. DHCPv6 >messages are defined in section 7 and each definition includes a short >description. There's no need to include a definition in section 14 as well. > >Here's the text from section 7: > > CONFIRM (4) The DHCP Confirm (or Confirm) message is used > by clients to confirm that the addresses > assigned to an IA and the lifetimes for > those addresses, as well as the current > configuration parameters assigned by the > server to the client are still valid. > >Perhaps the easiest thing to do would be to constrain the Reply to a >Confirm to be a binary response: ACK implies everything OK (no changes from >the server; everything from the client used as currently known to the >client); NAK implies client does a Request. Otherwise, we might get >conflicting responses from multiple, non-coordinating servers, as you point >out: > > >We probably need to clarify the behavior somewhat. For example, > >if a server that did not give out the addresses responds, can > >it: > >- Allocate additional addresses (to the IA)? > >- Extend the lifetimes of existing addresses? > >- Change/respond with configuration parameters? > >Perhaps we might allow extension of address lifetimes, as this has been >shown to work among multiple servers with DHCPv4 failover... > > >If the client does request (and supply) other options, what > >happens if the server's reply does not include those options > >(perhaps because the server doesn't feel it can supply them). > > > >I guess what I'm suggesting is that we indicate that allocation > >of addresses and supplying configuration parameters with a > >Confirm are problematic. And, that a client MUST NOT assume > >that the lack of a configuration parameter (option) means > >that the previous value for that option should be removed. > > > >Similar behavior might be required for Rebind - as multiple > >servers may respond? Though I think there are fewer issues > >here. > > > >Perhaps we should stress that Confirm SHOULD (MUST) only be > >used to confirm whether addresses are valid and SHOULD NOT > >(MUST NOT) be used in place of a Renew/Rebind?? Perhaps we > >should even specifically state that clients MUST NOT apply > >changes to the lifetimes or addition of new addresses received > >in a Reply to a Confirm? ------_=_NextPart_001_01C11618.FFB717E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Address lifetime extension and configuration changes in = response to Confirm (Was: RE: A few additional items re: -19 = draft)

Sorry ...

I do think that a simple ACK / NAK sequence would be = best.

By NAK I assume we mean "NoPrefixMatch" = type error.

By ACK I assume we mean "the prefixes you're = using are valid for the link"
(no indication of whether the addresses themselves = are).

I think that's all the Confirm needs to say since I = believe all it was
intended to communicate was whether the client was = still on the same
link.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, July 26, 2001 4:33 PM
To: DHCPv6 discussion list
Cc: DHCPv6 discussion list
Subject: Address lifetime extension and = configuration changes in
response to Confirm (Was: RE: A few additional items = re: -19 draft)


Bernie, you don't explicitly react to my proposal = that the Reply to a
Confirm should be a simple ACK/NAK.  I infer = that since you argue against
even a simple address lifetime extension, you = support the ACK/NAK
model.  Does my inference correctly reflect = your opinion?

- Ralph

At 03:01 PM 7/26/2001 -0500, Bernie Volz (EUD) = wrote:

> >There's no need to include a definition in = section 14 as well.
>
>Great. Guess I didn't do a throughout enough = saerch. Removing redundancy
>(especially when conflicting) is good.
>
> >Perhaps we might allow extension of address = lifetimes, as this has been
> >shown to work among multiple servers with = DHCPv4 failover...
>
>Hum ...
>
>Failover servers are kind of special since they = generally share information.
>
>But consider if you have multiple servers that = don't communicate with each
>other (and have the protections of the failover = protocol), then you can't
>allow one to extend the lifetimes since the = original server never learns of
>the extension and would potentially = "reclaim" the addresses.
>
>So, I would say that only the server that gave = out the addresses in the
>first place can extend them on a Confirm. Future = extensions to DHCPv6 or
>special server-to-server communication protocols = could alter this behavior
>in the future.
>
>Also, if you did allow *ANY* server to extend = the lifetimes on a Confirm,
>does that mean the client should communicate = with that new server when it
>is time to Renew? Or should it go back to = "old" server (that gave it the
>addresses on a Request or previously = Renewed)?
>
>- Bernie
>
>-----Original Message-----
>From: Ralph Droms [<mailto:rdroms@cisco.com>mailto:rdroms@cisco.com]
>Sent: Thursday, July 26, 2001 3:31 PM
>To: DHCPv6 discussion list
>Cc: DHCPv6 discussion list
>Subject: Re: A few additional items re: -19 = draft
>
>At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) = wrote:
>
> >- For the Confirm message, Section 14. = states:
> >
> >Confirm Confirm the validity of assigned = addresses and other
> >        = configuration changes through the server from which the
> >        = configuration information was obtained when the client's
> >        = assigned addresses may not be valid; for example, when
> >        = the client reboots or loses its connection to a link
>
>Turns out you've pointed out redundant and = conflicting text in -19.  DHCPv6
>messages are defined in section 7 and each = definition includes a short
>description.  There's no need to include a = definition in section 14 as well.
>
>Here's the text from section 7:
>
>        = CONFIRM (4)          The = DHCP Confirm (or Confirm) message is used
>          = ;            = ;       by clients to confirm that the = addresses
>          = ;            = ;       assigned to an IA and the = lifetimes for
>          = ;            = ;       those addresses, as well as the = current
>          = ;            = ;       configuration parameters assigned = by the
>          = ;            = ;       server to the client are still = valid.
>
>Perhaps the easiest thing to do would be to = constrain the Reply to a
>Confirm to be a binary response: ACK implies = everything OK (no changes from
>the server; everything from the client used as = currently known to the
>client); NAK implies client does a = Request.  Otherwise, we might get
>conflicting responses from multiple, = non-coordinating servers, as you point
>out:
>
> >We probably need to clarify the behavior = somewhat. For example,
> >if a server that did not give out the = addresses responds, can
> >it:
> >- Allocate additional addresses (to the = IA)?
> >- Extend the lifetimes of existing = addresses?
> >- Change/respond with configuration = parameters?
>
>Perhaps we might allow extension of address = lifetimes, as this has been
>shown to work among multiple servers with DHCPv4 = failover...
>
> >If the client does request (and supply) = other options, what
> >happens if the server's reply does not = include those options
> >(perhaps because the server doesn't feel it = can supply them).
> >
> >I guess what I'm suggesting is that we = indicate that allocation
> >of addresses and supplying configuration = parameters with a
> >Confirm are problematic. And, that a client = MUST NOT assume
> >that the lack of a configuration parameter = (option) means
> >that the previous value for that option = should be removed.
> >
> >Similar behavior might be required for = Rebind - as multiple
> >servers may respond? Though I think there = are fewer issues
> >here.
> >
> >Perhaps we should stress that Confirm = SHOULD (MUST) only be
> >used to confirm whether addresses are valid = and SHOULD NOT
> >(MUST NOT) be used in place of a = Renew/Rebind?? Perhaps we
> >should even specifically state that clients = MUST NOT apply
> >changes to the lifetimes or addition of new = addresses received
> >in a Reply to a Confirm?

------_=_NextPart_001_01C11618.FFB717E0-- From owner-dhcp-v6@bucknell.edu Thu Jul 26 17:41:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15006; Thu, 26 Jul 2001 17:41:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QLg6815873; Thu, 26 Jul 2001 17:42:06 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QLg1812740 for ; Thu, 26 Jul 2001 17:42:01 -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 f6QLg0p18327 for ; Thu, 26 Jul 2001 16:42:01 -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 f6QLg0X17537 for ; Thu, 26 Jul 2001 16:42:00 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Thu Jul 26 16:42:00 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 16:41:59 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3336@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Advertising prefixes rather than addresses Date: Thu, 26 Jul 2001 16:41:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1161B.C9C60350" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C1161B.C9C60350 Content-Type: text/plain; charset="iso-8859-1" Well, after trying to construct a message that argued for this because: - What if you have no router but wanted stateless. - This could be used in place of stateless when you wanted some level of control as to which clients used which prefixes (for example, preventing printers from using global addresses). - ... I also ran across a problem in that servers would need to take care on how this was used since you could not tell a client to do this multiple times per prefix (in cases where a client requested multiple IAs). And then if the server is doing work anyway to answer these requests, why not have it do the address assignment as well? It shouldn't be that much more work for the server to generate an address for the client and log it. So, I think we shouldn't bother with this support now. - Bernie -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Thursday, July 26, 2001 5:10 PM To: DHCPv6 discussion list Subject: Re: Advertising prefixes rather than addresses This is just duplicating functionality that is already in stateless autoconfig. Presumably you'd use DHCPv6 for addressing if you wanted to do it statefully. So I don't see the need or purpose of this. > > Bernie Volz wrote: > > > > > At another time we also discussed using the server to just > > > advertise prefixes and allowing the client to generate the > > > addresses? What about adding a "P" bit (next to the "T"-temporary > > > bit) to indicate that this is a prefix from which the client should > > > generate an address (or simply allowing it to do so if the > > > link-identifier field is all 0's). > > > > Sounds like a reasonable idea - anyone have a strong reaction (either > > positive or negative)? > > > > - Ralph ------_=_NextPart_001_01C1161B.C9C60350 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Advertising prefixes rather than addresses

Well, after trying to construct a message that argued = for this because:
- What if you have no router but wanted = stateless.
- This could be used in place of stateless when you = wanted some level of control
as to which clients used which prefixes (for = example, preventing printers from
using global addresses).
- ...

I also ran across a problem in that servers would = need to take care on how this
was used since you could not tell a client to do = this multiple times per prefix
(in cases where a client requested multiple = IAs).

And then if the server is doing work anyway to answer = these requests, why
not have it do the address assignment as well? It = shouldn't be that much more
work for the server to generate an address for the = client and log it.

So, I think we shouldn't bother with this support = now.

- Bernie

-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Thursday, July 26, 2001 5:10 PM
To: DHCPv6 discussion list
Subject: Re: Advertising prefixes rather than = addresses


This is just duplicating functionality that is = already in stateless
autoconfig. Presumably you'd use DHCPv6 for = addressing if you wanted to do
it statefully. So I don't see the need or purpose of = this.

> > Bernie Volz wrote:
> >
> > >    At another time we = also discussed using the server to just
> > >    advertise prefixes = and allowing the client to generate the
> > >    addresses? What = about adding a "P" bit (next to the = "T"-temporary
> > >    bit) to indicate = that this is a prefix from which the client should
> > >    generate an address = (or simply allowing it to do so if the
> > >    link-identifier = field is all 0's).
> >
> > Sounds like a reasonable idea - anyone = have a strong reaction (either
> > positive or negative)?
> >
> > - Ralph

------_=_NextPart_001_01C1161B.C9C60350-- From owner-dhcp-v6@bucknell.edu Thu Jul 26 18:37:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18526; Thu, 26 Jul 2001 18:37:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QLsR815102; Thu, 26 Jul 2001 17:54:27 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QLsK814881 for ; Thu, 26 Jul 2001 17:54:20 -0400 (EDT) Received: from grosse.bisbee.fugue.com (205-140-116-226.ip.theriver.com [205.140.116.226]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6QLnmf02112 for ; Thu, 26 Jul 2001 14:49:49 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6QLs2Y00697 for ; Thu, 26 Jul 2001 14:54:02 -0700 (MST) Message-Id: <200107262154.f6QLs2Y00697@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Address lifetime extension and configuration changes in respo nse to Confirm (Was: RE: A few additional items re: -19 draft) In-Reply-To: Message from "Bernie Volz (EUD)" of "Thu, 26 Jul 2001 16:21:56 EST." <66F66129A77AD411B76200508B65AC697B3335@eambunt705.ena-east.ericsson.se> Date: Thu, 26 Jul 2001 14:54:02 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > By NAK I assume we mean "NoPrefixMatch" type error. > > By ACK I assume we mean "the prefixes you're using are valid for the link" > (no indication of whether the addresses themselves are). > > I think that's all the Confirm needs to say since I believe all it was > intended to communicate was whether the client was still on the same > link. This sounds fine, but the present language for this message needs to be clarified to make this more clear. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Jul 26 18:44:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19014; Thu, 26 Jul 2001 18:44:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QM5R815671; Thu, 26 Jul 2001 18:05:27 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QM5E807192 for ; Thu, 26 Jul 2001 18:05:14 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6QM4x516900 for ; Thu, 26 Jul 2001 17:04:59 -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 f6QM4wX26488 for ; Thu, 26 Jul 2001 17:04:59 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 26 17:04:11 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 17:04:10 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3337@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Address lifetime extension and configuration changes in respo nse to Confirm (Was: RE: A few additional items re: -19 draft) Date: Thu, 26 Jul 2001 17:03:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1161E.D44D9A10" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C1161E.D44D9A10 Content-Type: text/plain; charset="iso-8859-1" Yes, by all means we need to clean up the language. I would also suggest that we add language to state that clients do not send nor should expect to get other configuration related options (such as Domain Name, Domain Server Addresses, etc) on the Confirm/Reply sequence. We do have to be a bit careful here as there could be options that are important to send (especially in the future as new options get defined). - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, July 26, 2001 5:54 PM To: DHCPv6 discussion list Subject: Re: Address lifetime extension and configuration changes in respo nse to Confirm (Was: RE: A few additional items re: -19 draft) > By NAK I assume we mean "NoPrefixMatch" type error. > > By ACK I assume we mean "the prefixes you're using are valid for the link" > (no indication of whether the addresses themselves are). > > I think that's all the Confirm needs to say since I believe all it was > intended to communicate was whether the client was still on the same > link. This sounds fine, but the present language for this message needs to be clarified to make this more clear. _MelloN_ ------_=_NextPart_001_01C1161E.D44D9A10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Address lifetime extension and configuration changes in = respo nse to Confirm (Was: RE: A few additional items re: -19 draft) =

Yes, by all means we need to clean up the = language.

I would also suggest that we add language to state = that clients do not send
nor should expect to get other configuration related = options (such as Domain Name,
Domain Server Addresses, etc) on the Confirm/Reply = sequence.

We do have to be a bit careful here as there could be = options that are important
to send (especially in the future as new options get = defined).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Thursday, July 26, 2001 5:54 PM
To: DHCPv6 discussion list
Subject: Re: Address lifetime extension and = configuration changes in
respo nse to Confirm (Was: RE: A few additional = items re: -19 draft)



> By NAK I assume we mean = "NoPrefixMatch" type error.
>
> By ACK I assume we mean "the prefixes = you're using are valid for the link"
> (no indication of whether the addresses = themselves are).
>
> I think that's all the Confirm needs to say = since I believe all it was
> intended to communicate was whether the client = was still on the same
> link.

This sounds fine, but the present language for this = message needs to
be clarified to make this more clear.

        =         =                _MelloN_

------_=_NextPart_001_01C1161E.D44D9A10-- From owner-dhcp-v6@bucknell.edu Thu Jul 26 19:07:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20514; Thu, 26 Jul 2001 19:07:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6QMHJ817272; Thu, 26 Jul 2001 18:17:19 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6QMHF812263 for ; Thu, 26 Jul 2001 18:17:15 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6QMGx521009 for ; Thu, 26 Jul 2001 17:16: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 f6QMGx728394 for ; Thu, 26 Jul 2001 17:16:59 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Jul 26 17:16:58 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 26 Jul 2001 17:16:58 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3338@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit Date: Thu, 26 Jul 2001 17:16:53 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11620.AC8A16A0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11620.AC8A16A0 Content-Type: text/plain; charset="iso-8859-1" See comments below, prefixed by BV>. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, July 26, 2001 4:43 PM To: DHCPv6 discussion list Subject: Addresses and other parameters in Advertise and Solicit Bernie Volz wrote: >1. In Section 14.3.1 (Creation and sending of Request messages), there > is no mention of using any of the "information" supplied by a > server in the Advertise message (in response to a Solicit). In > DHCPv4, the client sent information received in the Offer. We > probably should be explicit about this and perhaps even suggest > that the information received by a client in an Advertise is > basically for information purposes only to help it determine > whether this server will offer it what it needs. So, are you suggesting that the DHCPv6 client Request exactly the addresses and options from the Solicit, or no addresses or options, or ??? BV> I'm trying to figure out exactly what you, Jim, and others were expecting. BV> Since there isn't anything in the text about exactly how this is expected BV> to work, I would like some clarification. BV> BV> I do feel that servers will have less work to do if they don't have BV> to return full addresses that clients can use. The reason for this is BV> that the server doesn't have to assign the address until it receives BV> the request. And when multiple servers are running, this is a potential BV> big win as the Request will only go to one of those servers. > Perhaps the > addresses assigned in the Advertise should even just be prefixes > (interface portion all 0's)? I don't have a strong feeling one way or the other. BV> See above as to why I feel it best that they are just the prefixes. > If instead we want the server to assign "real" addresses, should > something be said about how long those should be valid and whether the > server should attempt to assign those same addresses to the client in > a subsequent Request/Reply exchange for the IA? Perhaps we could punt > and say this is a server implementation issue (whether it assigns real > addresses and whether those are held for some (short) time for the > client)? I take "valid" in this context to mean "reserved for this client". Has this scenario been a problem in DHCPv4? Do we need to specify any more mechanism than we have in the DHCPv4 spec? BV> Yes, valid means "reserved" for that client binding (DUID/IAID). BV> Well, I think the message timeouts and retransmission might dictate BV> the total time a server should put on these lifetimes. > NOTE: If real addresses are returned, perhaps a client might even > initiate DAD during the Request/Reply in which case it can do these > two items in parallel (though this would be somewhat tricky since it > would not want to Decline the addresses before receiving the Reply). Hm. I guess I had anticipated that the client would do DAD and either Request or Decline the addresses in the Advertise. It is the case that the spec does not constrain the times at which a Decline can be sent. I'm not sure it makes much sense for the client to Request a set of addresses and then Decline them later. BV> Hm back. Doesn't this make for a bizarre client implementation? BV> Recall that a client doesn't go through the Solicit/Advertise phase BV> for all of the addresses. It can issue additional Requests at any BV> time. Also, Renews can result in additional addresses being granted. BV> Under those cases the client must DAD them as well. Just seems so BV> much easier to be consistent and have the client get some addresses BV> and before using them run DAD. If the addresses are bad, then it BV> Declines them. BV> Also, if the DHCP server is doing its job, DAD really should be an BV> extremely infrequent event - more likely caused when switching from BV> stateless to managed or if you have broken clients. BV> If you want to allow DAD after Advertise (and a Decline before a BV> Request), then we do need to make that very clear in the draft since BV> that has never been my understanding. Did I miss something in the BV> draft? - Ralph ------_=_NextPart_001_01C11620.AC8A16A0 Content-Type: text/html; charset="iso-8859-1" RE: Addresses and other parameters in Advertise and Solicit

See comments below, prefixed by BV>.

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, July 26, 2001 4:43 PM
To: DHCPv6 discussion list
Subject: Addresses and other parameters in Advertise and Solicit


Bernie Volz wrote:

>1. In Section 14.3.1 (Creation and sending of Request messages), there
>    is no mention of using any of the "information" supplied by a
>    server in the Advertise message (in response to a Solicit). In
>    DHCPv4, the client sent information received in the Offer. We
>    probably should be explicit about this and perhaps even suggest
>    that the information received by a client in an Advertise is
>    basically for information purposes only to help it determine
>    whether this server will offer it what it needs.

So, are you suggesting that the DHCPv6 client Request exactly the addresses
and options from the Solicit, or no addresses or options, or ???

BV> I'm trying to figure out exactly what you, Jim, and others were expecting.
BV> Since there isn't anything in the text about exactly how this is expected
BV> to work, I would like some clarification.
BV>
BV> I do feel that servers will have less work to do if they don't have
BV> to return full addresses that clients can use. The reason for this is
BV> that the server doesn't have to assign the address until it receives
BV> the request. And when multiple servers are running, this is a potential
BV> big win as the Request will only go to one of those servers.

>    Perhaps the
>    addresses assigned in the Advertise should even just be prefixes
>    (interface portion all 0's)?

I don't have a strong feeling one way or the other.

BV> See above as to why I feel it best that they are just the prefixes.

>    If instead we want the server to assign "real" addresses, should
>    something be said about how long those should be valid and whether the
>    server should attempt to assign those same addresses to the client in
>    a subsequent Request/Reply exchange for the IA? Perhaps we could punt
>    and say this is a server implementation issue (whether it assigns real
>    addresses and whether those are held for some (short) time for the
>    client)?

I take "valid" in this context to mean "reserved for this client".  Has
this scenario been a problem in DHCPv4?  Do we need to specify any more
mechanism than we have in the DHCPv4 spec?

BV> Yes, valid means "reserved" for that client binding (DUID/IAID).
BV> Well, I think the message timeouts and retransmission might dictate
BV> the total time a server should put on these lifetimes.

>    NOTE: If real addresses are returned, perhaps a client might even
>    initiate DAD during the Request/Reply in which case it can do these
>    two items in parallel (though this would be somewhat tricky since it
>    would not want to Decline the addresses before receiving the Reply).

Hm.  I guess I had anticipated that the client would do DAD and either
Request or Decline the addresses in the Advertise.  It is the case that the
spec does not constrain the times at which a Decline can be sent.  I'm not
sure it makes much sense for the client to Request a set of addresses and
then Decline them later.

BV> Hm back. Doesn't this make for a bizarre client implementation?
BV> Recall that a client doesn't go through the Solicit/Advertise phase
BV> for all of the addresses. It can issue additional Requests at any
BV> time. Also, Renews can result in additional addresses being granted.
BV> Under those cases the client must DAD them as well. Just seems so
BV> much easier to be consistent and have the client get some addresses
BV> and before using them run DAD. If the addresses are bad, then it
BV> Declines them.

BV> Also, if the DHCP server is doing its job, DAD really should be an
BV> extremely infrequent event - more likely caused when switching from
BV> stateless to managed or if you have broken clients.

BV> If you want to allow DAD after Advertise (and a Decline before a
BV> Request), then we do need to make that very clear in the draft since
BV> that has never been my understanding. Did I miss something in the
BV> draft?

- Ralph

------_=_NextPart_001_01C11620.AC8A16A0-- From owner-dhcp-v4@bucknell.edu Fri Jul 27 07:11:20 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07049 for ; Fri, 27 Jul 2001 07:11:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RB8d817435; Fri, 27 Jul 2001 07:08:39 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6RB8S808491 for ; Fri, 27 Jul 2001 07:08:31 -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 HAA06608; Fri, 27 Jul 2001 07:07:29 -0400 (EDT) Message-Id: <200107271107.HAA06608@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-ddns-resolution-02.txt Date: Fri, 27 Jul 2001 07:07:28 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --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 : Resolution of DNS Name Conflicts Among DHCP Clients Author(s) : M. Stapp Filename : draft-ietf-dhc-ddns-resolution-02.txt Pages : 13 Date : 26-Jul-01 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS(RFC1034[1], RFC1035[2]), and specifically updating the name to address and address to name mappings maintained in the DNS. The 'Client FQDN Option'[14] specifies the client FQDN option, through which DHCP clients and servers can exchange information about client FQDNs. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-02.txt 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-ddns-resolution-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-ddns-resolution-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: <20010726170537.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ddns-resolution-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170537.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Jul 27 07:13:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07287 for ; Fri, 27 Jul 2001 07:13:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RBCT816758; Fri, 27 Jul 2001 07:12:29 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6RB8X809263 for ; Fri, 27 Jul 2001 07:08:33 -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 HAA06620; Fri, 27 Jul 2001 07:07:33 -0400 (EDT) Message-Id: <200107271107.HAA06620@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-fqdn-option-02.txt Date: Fri, 27 Jul 2001 07:07:33 -0400 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The DHCP Client FQDN Option Author(s) : M. Stapp, Y. Rekhter Filename : draft-ietf-dhc-fqdn-option-02.txt Pages : 14 Date : 26-Jul-01 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document specifies a DHCP option which can be used to exchange information about a DHCP client's fully-qualified domain name, or 'FQDN'. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-02.txt 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-fqdn-option-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-fqdn-option-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: <20010726170546.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-fqdn-option-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-fqdn-option-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010726170546.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Fri Jul 27 09:57:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18764; Fri, 27 Jul 2001 09:57:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RDw5825481; Fri, 27 Jul 2001 09:58:05 -0400 (EDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6RDvs822579 for ; Fri, 27 Jul 2001 09:57:54 -0400 (EDT) Received: from chitha.india.hp.com (chitha.india.hp.com [15.10.43.31]) by palrel2.hp.com (Postfix) with ESMTP id 5CF1A1050 for ; Fri, 27 Jul 2001 06:57:51 -0700 (PDT) Received: (from jitesh@localhost) by chitha.india.hp.com (8.9.3 (PHNE_18979)/8.7.3 SMKit7.02) id TAA07841 for dhcp-v6@bucknell.edu; Fri, 27 Jul 2001 19:15:21 +0530 (IST) From: Jitesh N Verma Message-Id: <200107271345.TAA07841@chitha.india.hp.com> Subject: Re: Advertise when no addresses available (was: Re: A few additional items re: -19 draft) To: DHCPv6 discussion list Date: Fri, 27 Jul 2001 19:15:21 +0530 (IST) In-Reply-To: <4.3.2.7.2.20010726153220.01ef6d40@mail.bucknell.edu> from Ralph Droms at Jul "26," 2001 "03:33:49" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Ralph, If the server does not respond, client will keep sending Solicit message, flooding the network. This is particularly true when there is only one server in the network. (If there are multiple server in the network, other servers may respond. No problem in this case). Please keep in mind that lease times are not going to be just few seconds. What I mean to say is that if the IP addresses are not available currently, it may not be available for quite some time. Looking at the various options, I will opt for server responding with IA containing Unavail error. I am not in favour of server responding with num-addrs = 0 , since this sort of IA is used to indicate empty IA. Let us not mix up. Let us provide more clarity to the implementer. - Jitesh > I vote for the server to not respond if it has no addresses available. > > - Ralph > > At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: > >- When forming the Advertise in response to a Solicit, there > >isn't any clear indication of what to do if no addresses may > >be available for the client from that server at that time > >(because all available addresses are in use). In particular, > >should the server: > >- Ignore the Solicit (in the hopes that by the time a subsequent > > Solicit arrives, addresses may be available) > >- Send the Advertise but without the IA option > >- Send the Advertise with the IA option but with an error (such > > as Unavail) > >- Send the Advertise with the IA option with num-addrs = 0 > > > >Or, should a client be prepared to handle all of the above? > > -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* From owner-dhcp-v4@bucknell.edu Fri Jul 27 10:03:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19235 for ; Fri, 27 Jul 2001 10:03:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RDxZ823218; Fri, 27 Jul 2001 09:59:35 -0400 (EDT) Received: from web20103.mail.yahoo.com (web20103.mail.yahoo.com [216.136.226.40]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RDxQ821946 for ; Fri, 27 Jul 2001 09:59:26 -0400 (EDT) Message-ID: <20010727135925.22110.qmail@web20103.mail.yahoo.com> Received: from [192.146.101.11] by web20103.mail.yahoo.com; Fri, 27 Jul 2001 06:59:25 PDT Date: Fri, 27 Jul 2001 06:59:25 -0700 (PDT) From: Jimmy Bush Subject: Server initiated traffic To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: my_gyro@yahoo.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Would there ever be a case when a DHCP server would initiate traffic with a client? Perhaps if it has lost power? Or has given out all its licenses and wants to revoke one? I'm thinking that the answer is no, because I can't really see a mechanism for this within the protocol, and it doesn't really sound like something a server would do (given that it is in the business of serving.) However, if anyone has seen something like this I would love to know the context and the results. Thanks. __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ From owner-dhcp-v6@bucknell.edu Fri Jul 27 10:14:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20211; Fri, 27 Jul 2001 10:14:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6REF3823679; Fri, 27 Jul 2001 10:15:04 -0400 (EDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6REEn826783 for ; Fri, 27 Jul 2001 10:14:49 -0400 (EDT) Received: from chitha.india.hp.com (chitha.india.hp.com [15.10.43.31]) by palrel2.hp.com (Postfix) with ESMTP id 35AE31558 for ; Fri, 27 Jul 2001 07:14:47 -0700 (PDT) Received: (from jitesh@localhost) by chitha.india.hp.com (8.9.3 (PHNE_18979)/8.7.3 SMKit7.02) id TAA07919 for dhcp-v6@bucknell.edu; Fri, 27 Jul 2001 19:32:18 +0530 (IST) From: Jitesh N Verma Message-Id: <200107271402.TAA07919@chitha.india.hp.com> Subject: Re: Advertising prefixes rather than addresses To: DHCPv6 discussion list Date: Fri, 27 Jul 2001 19:32:17 +0530 (IST) In-Reply-To: from Bernard Aboba at Jul "26," 2001 "02:09:56" pm X-Mailer: ELM [$Revision: 1.17.214.3 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit What can't we have this functionality in DHCP?? 1) Stateless autoconfiguration through router advertizement has already hijacked half of the DHCP's usefulness. 2) SLP guys have hijacked the idea of Service Location from DHCP. 3) DNS guys are thinking of putting a mini DHCP in the DNS. Everybody is trying to hijack the DHCP functionality. Why can't we implement a functionality which is DHCP's own domain (The address allocation)?? I am not saying that it should be included in the next draft. It may be deferred, but it should be considered by the working group. - Jitesh > This is just duplicating functionality that is already in stateless > autoconfig. Presumably you'd use DHCPv6 for addressing if you wanted to do > it statefully. So I don't see the need or purpose of this. > > > > Bernie Volz wrote: > > > > > > > At another time we also discussed using the server to just > > > > advertise prefixes and allowing the client to generate the > > > > addresses? What about adding a "P" bit (next to the "T"-temporary > > > > bit) to indicate that this is a prefix from which the client should > > > > generate an address (or simply allowing it to do so if the > > > > link-identifier field is all 0's). > > > > > > Sounds like a reasonable idea - anyone have a strong reaction (either > > > positive or negative)? > > > > > > - Ralph > > -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* From owner-dhcp-v6@bucknell.edu Fri Jul 27 10:48:18 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA23375; Fri, 27 Jul 2001 10:48:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6REmQ801400; Fri, 27 Jul 2001 10:48:26 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6REmN826493 for ; Fri, 27 Jul 2001 10:48:24 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6REm8524774 for ; Fri, 27 Jul 2001 09:48:08 -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 f6REm8p26773 for ; Fri, 27 Jul 2001 09:48:08 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Jul 27 09:48:07 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 09:48:07 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3342@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Advertise when no addresses available (was: Re: A few additi onal items re: -19 draft) Date: Fri, 27 Jul 2001 09:48:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C116AB.25155BE0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C116AB.25155BE0 Content-Type: text/plain; charset="iso-8859-1" Jitesh/Ralph: After thinking a bit more about this, there is merit in having the server respond. This at least indicates to the client that the server does exist. And, it may be that the server can provide some useful information to the client even though it is unable to give it addresses. It may well be that some addresses are stateless and these may be of sufficient scope to allow the client to obtain other useful configuration information from the server even if it can not get addresses. So, I agree with Jitesh that the best response is IA w/Unavail error. My reason for this is: - I want the server to respond (see above). - Responding without the IA likely means to the client that the server is not willing to give out addresses (but is willing to give other configuration parameters). I do not agree with Jitesh that this will flood the network - clients are supposed to retransmit Solicits periodically and will do so if no server exists anyway. The retransmit timers are set to keep this traffic reasonable. Sure, if you had thousands of clients, you could get a fair amount of traffic. But that's not likely on most link technology in use today (to have that many clients). And, if it is a problem, we better readjust the Solicit retransmit timers anyway. I do believe we need to spell out the server behavior clearly. So, I would suggest text as follows: When responding to a Solicit, the server MUST handle client IA options as follows: - If the server is not configured to offer any addresses to the client (or link), it MUST not include the client's IA option(s) in the Advertise. - If the server is configured to offer addresses to the client (or link) but has no addresses to advertise at the moment, it MUST include the client's IA option(s) with an error of "Unavail". - If the server is configured to offer addresses and has addresses to offer, it MUST include the client's IA option(s) filled out with address information [either the prefixes or the full addresses, as is TBD]. If the above is done, a client can determine whether a server is capable of offering it addresses or not, and whether addresses are presently available or not. In this way, it can determine which server to use (if it needs addresses, use the highest preference server that has addresses available, if none, use the server that can offer addresses but has none at the moment, ...). - Bernie -----Original Message----- From: Jitesh N Verma [mailto:jitesh@india.hp.com] Sent: Friday, July 27, 2001 9:45 AM To: DHCPv6 discussion list Subject: Re: Advertise when no addresses available (was: Re: A few additional items re: -19 draft) Ralph, If the server does not respond, client will keep sending Solicit message, flooding the network. This is particularly true when there is only one server in the network. (If there are multiple server in the network, other servers may respond. No problem in this case). Please keep in mind that lease times are not going to be just few seconds. What I mean to say is that if the IP addresses are not available currently, it may not be available for quite some time. Looking at the various options, I will opt for server responding with IA containing Unavail error. I am not in favour of server responding with num-addrs = 0 , since this sort of IA is used to indicate empty IA. Let us not mix up. Let us provide more clarity to the implementer. - Jitesh > I vote for the server to not respond if it has no addresses available. > > - Ralph > > At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: > >- When forming the Advertise in response to a Solicit, there > >isn't any clear indication of what to do if no addresses may > >be available for the client from that server at that time > >(because all available addresses are in use). In particular, > >should the server: > >- Ignore the Solicit (in the hopes that by the time a subsequent > > Solicit arrives, addresses may be available) > >- Send the Advertise but without the IA option > >- Send the Advertise with the IA option but with an error (such > > as Unavail) > >- Send the Advertise with the IA option with num-addrs = 0 > > > >Or, should a client be prepared to handle all of the above? > > -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ------_=_NextPart_001_01C116AB.25155BE0 Content-Type: text/html; charset="iso-8859-1" RE: Advertise when no addresses available (was: Re: A few additional items re: -19 draft)

Jitesh/Ralph:

After thinking a bit more about this, there is merit in having the server respond.
This at least indicates to the client that the server does exist. And, it may be
that the server can provide some useful information to the client even though it
is unable to give it addresses. It may well be that some addresses are stateless
and these may be of sufficient scope to allow the client to obtain other useful
configuration information from the server even if it can not get addresses.

So, I agree with Jitesh that the best response is IA w/Unavail error. My reason for
this is:
- I want the server to respond (see above).
- Responding without the IA likely means to the client that the server is not willing
to give out addresses (but is willing to give other configuration parameters).

I do not agree with Jitesh that this will flood the network - clients are supposed
to retransmit Solicits periodically and will do so if no server exists anyway. The
retransmit timers are set to keep this traffic reasonable. Sure, if you had thousands
of clients, you could get a fair amount of traffic. But that's not likely on most
link technology in use today (to have that many clients). And, if it is a problem,
we better readjust the Solicit retransmit timers anyway.

I do believe we need to spell out the server behavior clearly. So, I would suggest
text as follows:

When responding to a Solicit, the server MUST handle client IA options as follows:
- If the server is not configured to offer any addresses to the client (or link),
it MUST not include the client's IA option(s) in the Advertise.
- If the server is configured to offer addresses to the client (or link) but has
no addresses to advertise at the moment, it MUST include the client's IA option(s)
with an error of "Unavail".
- If the server is configured to offer addresses and has addresses to offer, it
MUST include the client's IA option(s) filled out with address information [either
the prefixes or the full addresses, as is TBD].

If the above is done, a client can determine whether a server is capable of offering
it addresses or not, and whether addresses are presently available or not. In this
way, it can determine which server to use (if it needs addresses, use the highest
preference server that has addresses available, if none, use the server that can
offer addresses but has none at the moment, ...).

- Bernie


-----Original Message-----
From: Jitesh N Verma [mailto:jitesh@india.hp.com]
Sent: Friday, July 27, 2001 9:45 AM
To: DHCPv6 discussion list
Subject: Re: Advertise when no addresses available (was: Re: A few
additional items re: -19 draft)


Ralph,
        If the server does not respond, client will keep sending Solicit
message, flooding the network. This is particularly true when there is only
one server in the network. (If there are multiple server in the network, other
servers may respond. No problem in this case). Please keep in mind that lease
times are not going to be just few seconds. What I mean to say is that if the
IP addresses are not available currently, it may not be available for quite
some time.
        Looking at the various options, I will opt for server responding with
IA containing Unavail error. I am not in favour of server responding with
num-addrs = 0 , since this sort of IA is used to indicate empty IA. Let us
not mix up. Let us provide more clarity to the implementer.

- Jitesh
               


> I vote for the server to not respond if it has no addresses available.
>
> - Ralph
>
> At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote:
> >- When forming the Advertise in response to a Solicit, there
> >isn't any clear indication of what to do if no addresses may
> >be available for the client from that server at that time
> >(because all available addresses are in use). In particular,
> >should the server:
> >- Ignore the Solicit (in the hopes that by the time a subsequent
> >   Solicit arrives, addresses may be available)
> >- Send the Advertise but without the IA option
> >- Send the Advertise with the IA option but with an error (such
> >   as Unavail)
> >- Send the Advertise with the IA option with num-addrs = 0
> >
> >Or, should a client be prepared to handle all of the above?
>
>


--
-----------------------------------------------------------------------

    ~                                                             ~
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
^ Jitesh N. Verma                     Tel. 91-80-225 1554 Ext. 1424   ^
^ HEWLETT PACKARD                     Fax. 91-80-220 0196             ^
^ INDIA SOFTWARE OPERATIONS         Email. jitesh@india.hp.com        ^
^ 29, CUNNINGHAM ROAD               Pager. 9624-263608                ^
^ BANGALORE 560 052        __      Telnet. 847-1424                   ^
^                         / /                                         ^
^                        / /___ _____                                 ^
^                       / __  // __  /                                ^
^                      / / / // /_/ /                                 ^
^                     /_/ /_// ____/                                  ^
^                           / /                                       ^
^                          /_/                                        ^
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*

------_=_NextPart_001_01C116AB.25155BE0-- From owner-dhcp-v6@bucknell.edu Fri Jul 27 11:48:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29308; Fri, 27 Jul 2001 11:48:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RFmc831038; Fri, 27 Jul 2001 11:48:38 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RFmQ807003 for ; Fri, 27 Jul 2001 11:48:26 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA09648; Fri, 27 Jul 2001 11:48:26 -0400 Date: Fri, 27 Jul 2001 11:48:25 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] In-Reply-To: <66F66129A77AD411B76200508B65AC697B3325@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In IPv6 the prefixes could be deprecated to 2 hours by a router. So it could happen. Or by the dhcpv6 serverr. /jim On Thu, 26 Jul 2001, Bernie Volz (EUD) wrote: > Ralph, et al: > > The new text works for me. > > Regarding your other issue: > "In the middle of writing my previous message, I had the following thought: > suppose the link has been renumbered - the addresses in the IA will be > invalid although the client has remained connected to the same link..." > > Isn't this a violation of the address lifetimes? If the lifetimes are > maintained properly, this should never happen. > > And, what's the impact? Won't the server send a NoPrefixMatch in this case > because the client's prefixes aren't valid - though the client is still on > the same link? In that case, the client will simply either believe the > NoPrefixMatch and go through Solicit/Advertise or it will ignore the > NoPrefixMatch in which case the lifetimes will expire the address anyway. > > Note: There will probably be instances because of clock differences where > a client may still believe an address to be valid when it truely is not. > But that condition should only last for short periods of time and it is > adviseable that there be some "grace" involved in lifetimes. > > - Bernie > > -----Original Message----- > From: Droms Ralph [mailto:rdroms@cisco.com] > Sent: Thursday, July 26, 2001 8:28 AM > To: DHCPv6 discussion list > Cc: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > At 02:17 PM 7/19/2001 -0700, Ted Lemon wrote: > > > > Why should the client make a determination about moving to a new link? In > > > fact, how can it make that determination at this point, which is, I think, > > > after the point at which the client may have received an event from its > > > interface about loss of carrier, change of access point, etc.? I suggest > > > the following text: > > > >This is the multiple overlapping link layers problem - a 3G cell phone > >that is able to contact two different cell towers. The client in this > >case has information that the server does not have, and is probably > >talking to more than one server, and therefore is in a position to > >know that it can continue to use its addresses. > > OK, now I get it. I misunderstood the phrase "whether it has moved to a > different link." In some sense, if the client is communicating with > overlapping links, it has, in fact, moved to a new link. It is still on > the old link, as well... > > Is it more that the client can determine, through some other means, that > the addresses in an IA are valid although some server - through > misconfiguration, overlapping links, ??? - has indicated that the addresses > are not valid? I suggest the following text in section 14.3.5 (rev -19): > > When the client receives a NoPrefixMatch error status in the IA status > field of a Reply to a Confirm, Rebind or Renew message, if the client > can determine through some other means that the addresses in the IA > are valid for the link to which the interface is attached, the client > MAY choose to ignore the NoPrefixMatch error. Examples of ways a client > can determine the validity are: examining prefixes in router > advertisements, receipt of a Confirm message from a different server > that indicates validity of the addresses in the IA, link-layer > specific mechanisms through which the client can determine that it > is currently connected to the link for which the client previously > determined that the addresses in the IA were valid. > > After receiving a NoPrefixMatch error status in the IA status > field of a Reply to a Confirm, Rebind or Renew message, if the client > cannot independently determine that the addresses in the IA are still > valid, the client MUST NOT use any of the addresses in the IA. > > - Ralph > > > From owner-dhcp-v6@bucknell.edu Fri Jul 27 11:51:20 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA29516; Fri, 27 Jul 2001 11:51:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RFpi804393; Fri, 27 Jul 2001 11:51:44 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RFpg812337 for ; Fri, 27 Jul 2001 11:51:42 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA13332; Fri, 27 Jul 2001 11:51:41 -0400 Date: Fri, 27 Jul 2001 11:51:41 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: Advertise when no addresses available (was: Re: A few additional items re: -19 draft) In-Reply-To: <4.3.2.7.2.20010726153220.01ef6d40@mail.bucknell.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I vote no response too. /jim On Thu, 26 Jul 2001, Ralph Droms wrote: > I vote for the server to not respond if it has no addresses available. > > - Ralph > > At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: > >- When forming the Advertise in response to a Solicit, there > >isn't any clear indication of what to do if no addresses may > >be available for the client from that server at that time > >(because all available addresses are in use). In particular, > >should the server: > >- Ignore the Solicit (in the hopes that by the time a subsequent > > Solicit arrives, addresses may be available) > >- Send the Advertise but without the IA option > >- Send the Advertise with the IA option but with an error (such > > as Unavail) > >- Send the Advertise with the IA option with num-addrs = 0 > > > >Or, should a client be prepared to handle all of the above? > From owner-dhcp-v6@bucknell.edu Fri Jul 27 12:01:29 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00450; Fri, 27 Jul 2001 12:01:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RG1o817485; Fri, 27 Jul 2001 12:01:50 -0400 (EDT) Received: from inet-vrs-01.redmond.corp.microsoft.com (mail1.microsoft.com [131.107.3.125]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RG1Z818916 for ; Fri, 27 Jul 2001 12:01:36 -0400 (EDT) Received: from 157.54.9.101 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 27 Jul 2001 09:01:19 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 27 Jul 2001 09:01:08 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.82]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 27 Jul 2001 09:00:59 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 27 Jul 2001 08:59:46 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5683.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" Subject: RE: Advertise when no addresses available (was: Re: A few additional items re: -19 draft) Date: Fri, 27 Jul 2001 08:59:47 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC10191E1D3@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Advertise when no addresses available (was: Re: A few additional items re: -19 draft) Thread-Index: AcEWqz9fJUHlABdRRNK+xTO3VMdJIAACcKgQ From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 27 Jul 2001 15:59:46.0958 (UTC) FILETIME=[28A072E0:01C116B5] Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C116B5.290B6E92" ------_=_NextPart_001_01C116B5.290B6E92 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The server can remain silent if it doesn't have any addresses to offer. I don't see much upside for the client if the server says it doesn't have any addresses to offer. =20 thx =20 -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]=20 Sent: Friday, July 27, 2001 7:48 AM To: DHCPv6 discussion list Subject: RE: Advertise when no addresses available (was: Re: A few additional items re: -19 draft) =20 Jitesh/Ralph:=20 After thinking a bit more about this, there is merit in having the server respond.=20 This at least indicates to the client that the server does exist. And, it may be=20 that the server can provide some useful information to the client even though it=20 is unable to give it addresses. It may well be that some addresses are stateless=20 and these may be of sufficient scope to allow the client to obtain other useful=20 configuration information from the server even if it can not get addresses.=20 So, I agree with Jitesh that the best response is IA w/Unavail error. My reason for=20 this is:=20 - I want the server to respond (see above).=20 - Responding without the IA likely means to the client that the server is not willing=20 to give out addresses (but is willing to give other configuration parameters).=20 I do not agree with Jitesh that this will flood the network - clients are supposed=20 to retransmit Solicits periodically and will do so if no server exists anyway. The=20 retransmit timers are set to keep this traffic reasonable. Sure, if you had thousands=20 of clients, you could get a fair amount of traffic. But that's not likely on most=20 link technology in use today (to have that many clients). And, if it is a problem,=20 we better readjust the Solicit retransmit timers anyway.=20 I do believe we need to spell out the server behavior clearly. So, I would suggest=20 text as follows:=20 When responding to a Solicit, the server MUST handle client IA options as follows:=20 - If the server is not configured to offer any addresses to the client (or link),=20 it MUST not include the client's IA option(s) in the Advertise.=20 - If the server is configured to offer addresses to the client (or link) but has=20 no addresses to advertise at the moment, it MUST include the client's IA option(s)=20 with an error of "Unavail".=20 - If the server is configured to offer addresses and has addresses to offer, it=20 MUST include the client's IA option(s) filled out with address information [either=20 the prefixes or the full addresses, as is TBD].=20 If the above is done, a client can determine whether a server is capable of offering=20 it addresses or not, and whether addresses are presently available or not. In this=20 way, it can determine which server to use (if it needs addresses, use the highest=20 preference server that has addresses available, if none, use the server that can=20 offer addresses but has none at the moment, ...).=20 - Bernie=20 =20 -----Original Message-----=20 From: Jitesh N Verma [mailto:jitesh@india.hp.com]=20 Sent: Friday, July 27, 2001 9:45 AM=20 To: DHCPv6 discussion list=20 Subject: Re: Advertise when no addresses available (was: Re: A few=20 additional items re: -19 draft)=20 =20 Ralph,=20 If the server does not respond, client will keep sending Solicit message, flooding the network. This is particularly true when there is only=20 one server in the network. (If there are multiple server in the network, other=20 servers may respond. No problem in this case). Please keep in mind that lease=20 times are not going to be just few seconds. What I mean to say is that if the=20 IP addresses are not available currently, it may not be available for quite=20 some time.=20 Looking at the various options, I will opt for server responding with=20 IA containing Unavail error. I am not in favour of server responding with=20 num-addrs =3D 0 , since this sort of IA is used to indicate empty IA. = Let us=20 not mix up. Let us provide more clarity to the implementer.=20 - Jitesh=20 =20 =20 > I vote for the server to not respond if it has no addresses available. >=20 > - Ralph=20 >=20 > At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote:=20 > >- When forming the Advertise in response to a Solicit, there=20 > >isn't any clear indication of what to do if no addresses may=20 > >be available for the client from that server at that time=20 > >(because all available addresses are in use). In particular,=20 > >should the server:=20 > >- Ignore the Solicit (in the hopes that by the time a subsequent=20 > > Solicit arrives, addresses may be available)=20 > >- Send the Advertise but without the IA option=20 > >- Send the Advertise with the IA option but with an error (such=20 > > as Unavail)=20 > >- Send the Advertise with the IA option with num-addrs =3D 0=20 > >=20 > >Or, should a client be prepared to handle all of the above?=20 >=20 >=20 =20 --=20 -----------------------------------------------------------------------=20 ~ ~=20 *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*=20 ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^=20 ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^=20 ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^=20 ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^=20 ^ BANGALORE 560 052 __ Telnet. 847-1424 ^=20 ^ / / ^=20 ^ / /___ _____ ^=20 ^ / __ // __ / ^=20 ^ / / / // /_/ / ^=20 ^ /_/ /_// ____/ ^=20 ^ / / ^=20 ^ /_/ ^=20 *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*=20 ------_=_NextPart_001_01C116B5.290B6E92 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Advertise when no addresses available (was: Re: A few = additional items re: -19 draft)

The server can remain silent if it = doesn’t have any addresses to offer. I don’t see much upside for the = client if the server says it doesn’t have any addresses to = offer.

 

thx

 

-----Original = Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Friday, July 27, = 2001 7:48 AM
To: DHCPv6 discussion = list
Subject: RE: Advertise = when no addresses available (was: Re: A few additional items re: -19 = draft)

 

Jitesh/Ralph:

After thinking a bit more about this, there = is merit in having the server respond.
This at least indicates = to the client that the server does exist. And, it may be
that the server can = provide some useful information to the client even though it
is unable to give it = addresses. It may well be that some addresses are stateless
and these may be of = sufficient scope to allow the client to obtain other useful
configuration = information from the server even if it can not get addresses.

So, I agree with Jitesh that the best = response is IA w/Unavail error. My reason for
this is: =
- I want the server to = respond (see above).
- Responding without the = IA likely means to the client that the server is not willing
to give out addresses = (but is willing to give other configuration parameters).

I do not agree with Jitesh that this will = flood the network - clients are supposed
to retransmit Solicits = periodically and will do so if no server exists anyway. The
retransmit timers are = set to keep this traffic reasonable. Sure, if you had thousands
of clients, you could = get a fair amount of traffic. But that's not likely on most
link technology in use = today (to have that many clients). And, if it is a problem,
we better readjust the = Solicit retransmit timers anyway.

I do believe we need to spell out the server = behavior clearly. So, I would suggest
text as = follows:

When responding to a Solicit, the server MUST = handle client IA options as follows:
- If the server is not = configured to offer any addresses to the client (or link),
it MUST not include the = client's IA option(s) in the Advertise.
- If the server is = configured to offer addresses to the client (or link) but has
no addresses to = advertise at the moment, it MUST include the client's IA option(s)
with an error of "Unavail".
- If the server is = configured to offer addresses and has addresses to offer, it
MUST include the = client's IA option(s) filled out with address information [either
the prefixes or the full = addresses, as is TBD].

If the above is done, a client can determine = whether a server is capable of offering
it addresses or not, and = whether addresses are presently available or not. In this
way, it can determine = which server to use (if it needs addresses, use the highest
preference server that = has addresses available, if none, use the server that can
offer addresses but has = none at the moment, ...).

- Bernie

 

-----Original Message-----
From: Jitesh N Verma [mailto:jitesh@india.hp.com]
Sent: Friday, July 27, = 2001 9:45 AM
To: DHCPv6 discussion = list
Subject: Re: Advertise = when no addresses available (was: Re: A few
additional items re: -19 = draft)

 

Ralph,
        If the server does not respond, client will keep sending = Solicit
message, flooding the = network. This is particularly true when there is only
one server in the = network. (If there are multiple server in the network, other
servers may respond. No = problem in this case). Please keep in mind that lease
times are not going to = be just few seconds. What I mean to say is that if the
IP addresses are not = available currently, it may not be available for quite
some time. =
        Looking at the various options, I will opt for server responding = with
IA containing Unavail = error. I am not in favour of server responding with
num-addrs =3D 0 , since = this sort of IA is used to indicate empty IA. Let us
not mix up. Let us = provide more clarity to the implementer.

- Jitesh
               

 

> I vote for the server to not respond if = it has no addresses available.
>
> - = Ralph
>
> At 12:10 PM = 7/23/2001 -0500, Bernie Volz (EUD) wrote:
> >- When forming = the Advertise in response to a Solicit, there
> >isn't any clear = indication of what to do if no addresses may
> >be available = for the client from that server at that time
> >(because all = available addresses are in use). In particular,
> >should the = server:
> >- Ignore the = Solicit (in the hopes that by the time a subsequent
> >   = Solicit arrives, addresses may be available)
> >- Send the = Advertise but without the IA option
> >- Send the = Advertise with the IA option but with an error (such
> >   as = Unavail)
> >- Send the = Advertise with the IA option with num-addrs =3D 0
> > =
> >Or, should a = client be prepared to handle all of the above?
>
>

 

--
----------------------------------------------= -------------------------

    ~            =             &= nbsp;           &n= bsp;           &nb= sp;            ~
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~*
^ Jitesh N. Verma           &n= bsp;         Tel. 91-80-225 1554 Ext. 1424   ^
^ HEWLETT PACKARD           =           Fax. 91-80-220 0196           &nb= sp; ^
^ INDIA SOFTWARE OPERATIONS         Email. jitesh@india.hp.com        = ^
^ 29, CUNNINGHAM ROAD           &nb= sp;   Pager. 9624-263608          &n= bsp;     ^
^ BANGALORE 560 052        = __      Telnet. 847-1424           = ;        ^
^       &nb= sp;           &nbs= p;     / /            =             &= nbsp;           &n= bsp;    ^
^       &nb= sp;           &nbs= p;    / /___ _____           &n= bsp;           &nb= sp;         ^
^       &nb= sp;           &nbs= p;   / __  // __  /            =             &= nbsp;       ^
^       &nb= sp;           &nbs= p;  / / / // /_/ /            =             &= nbsp;        ^
^       &nb= sp;           &nbs= p; /_/ /_// = ____/           &n= bsp;           &nb= sp;          ^
^       &nb= sp;           &nbs= p;       / /            =             &= nbsp;           &n= bsp;  ^
^       &nb= sp;           &nbs= p;      /_/           &nbs= p;            = ;            =     ^
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~= ~~~~~~~~~~~~~~~~~~~~~~~~*

=00 ------_=_NextPart_001_01C116B5.290B6E92-- --------------InterScan_NT_MIME_Boundary-- From owner-dhcp-v6@bucknell.edu Fri Jul 27 12:07:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01132; Fri, 27 Jul 2001 12:07:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RG8A810577; Fri, 27 Jul 2001 12:08:10 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RG87820237 for ; Fri, 27 Jul 2001 12:08:07 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA12963; Fri, 27 Jul 2001 12:08:06 -0400 Date: Fri, 27 Jul 2001 12:08:06 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: Re: Advertising prefixes rather than addresses In-Reply-To: <3B6087FC.F8B8C942@cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Let me try to give supportive example of permitting bernies request. we have discussed this before too and in many places. the sysadm wants control over the entire network space and at a central location for IPv6 and to do that from servers. this means for whatever reason stateless will not be used for address configuration. The the routers set the M and O bits and the clients must use dhcpv6. but the sysadm wants to use the autoconfig benefit of ipv6 where by the client configures their address using prefix from the server. then the same code to generate an address as in stateless can be reused too as a note and DAD etc.. thats why it is reasonable. but if we want the server database to have all addresses a client has from a prefix then one of two things must happen. 1.; client sends the completed addresses back to the server with the low order bits used (we cannot hard code that is only 64bits for IPv6 fyi as that is just one addressing scheme supported today). 2. Or client must always send link-local address in dhcpv6 msg hdr as the server could use that to concatenate the address assuming all other bits are owned by the server for the prefix (I think we can assume that) for that link. OR the server only keeps prefixes for the client. /jim On Thu, 26 Jul 2001, Josh Littlefield wrote: > I used to think this was a reasonable idea. But I thought it was killed by > this group a while ago as unnecessary. If you want stateless autoconfig, > then use that and not DHCP. If the router advertisement tells you to do > stateful autoconfig (DHCP), then having DHCP tell you to do stateless > autoconfig on a prefix (essentially this proposal) doesn't seem right. The > server can always just generate for a client the address it would generate > for itself (supposedly on some subset of the allowable prefixes). > > Ralph Droms wrote: > > > Bernie Volz wrote: > > > > > At another time we also discussed using the server to just > > > advertise prefixes and allowing the client to generate the > > > addresses? What about adding a "P" bit (next to the "T"-temporary > > > bit) to indicate that this is a prefix from which the client should > > > generate an address (or simply allowing it to do so if the > > > link-identifier field is all 0's). > > > > Sounds like a reasonable idea - anyone have a strong reaction (either > > positive or negative)? > > > > - Ralph > > -- > ===================================================================== > Josh Littlefield Cisco Systems, Inc. > joshl@cisco.com 250 Apollo Drive > tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 > From owner-dhcp-v6@bucknell.edu Fri Jul 27 12:08:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01281; Fri, 27 Jul 2001 12:08:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RG94823245; Fri, 27 Jul 2001 12:09:04 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6RG8w822046 for ; Fri, 27 Jul 2001 12:08:58 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6RG8h502651 for ; Fri, 27 Jul 2001 11:08:43 -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 f6RG8hp08431 for ; Fri, 27 Jul 2001 11:08:43 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Jul 27 11:08:42 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 11:08:42 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3345@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] Date: Fri, 27 Jul 2001 11:06:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C116B6.221B2DB0" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C116B6.221B2DB0 Content-Type: text/plain; charset="iso-8859-1" If so, what does this really mean? ... that the Confirm simply tells the client whether the addresses can or can not be used and the reason may be (a) client has moved to a new link or (b) some event happened while it was "gone" and its existing addresses are no longer valid. So, doesn't this reinforce what Ted was suggesting all along ... the Reply to a Confirm that has a "NoPrefixMatch" status in the IA Option is just input to the client that it *MAY* have moved to a new link but does not necessarily mean it *HAS* moved to a new link. Anyway, the action for the client is the same ... do not use the addresses and go back to the Solicit "state" to find a server with which to communicate and Request addresses. - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Friday, July 27, 2001 11:48 AM To: DHCPv6 discussion list Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes] In IPv6 the prefixes could be deprecated to 2 hours by a router. So it could happen. Or by the dhcpv6 serverr. /jim On Thu, 26 Jul 2001, Bernie Volz (EUD) wrote: > Ralph, et al: > > The new text works for me. > > Regarding your other issue: > "In the middle of writing my previous message, I had the following thought: > suppose the link has been renumbered - the addresses in the IA will be > invalid although the client has remained connected to the same link..." > > Isn't this a violation of the address lifetimes? If the lifetimes are > maintained properly, this should never happen. > > And, what's the impact? Won't the server send a NoPrefixMatch in this case > because the client's prefixes aren't valid - though the client is still on > the same link? In that case, the client will simply either believe the > NoPrefixMatch and go through Solicit/Advertise or it will ignore the > NoPrefixMatch in which case the lifetimes will expire the address anyway. > > Note: There will probably be instances because of clock differences where > a client may still believe an address to be valid when it truely is not. > But that condition should only last for short periods of time and it is > adviseable that there be some "grace" involved in lifetimes. > > - Bernie > > -----Original Message----- > From: Droms Ralph [mailto:rdroms@cisco.com] > Sent: Thursday, July 26, 2001 8:28 AM > To: DHCPv6 discussion list > Cc: DHCPv6 discussion list > Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes] > > > At 02:17 PM 7/19/2001 -0700, Ted Lemon wrote: > > > > Why should the client make a determination about moving to a new link? In > > > fact, how can it make that determination at this point, which is, I think, > > > after the point at which the client may have received an event from its > > > interface about loss of carrier, change of access point, etc.? I suggest > > > the following text: > > > >This is the multiple overlapping link layers problem - a 3G cell phone > >that is able to contact two different cell towers. The client in this > >case has information that the server does not have, and is probably > >talking to more than one server, and therefore is in a position to > >know that it can continue to use its addresses. > > OK, now I get it. I misunderstood the phrase "whether it has moved to a > different link." In some sense, if the client is communicating with > overlapping links, it has, in fact, moved to a new link. It is still on > the old link, as well... > > Is it more that the client can determine, through some other means, that > the addresses in an IA are valid although some server - through > misconfiguration, overlapping links, ??? - has indicated that the addresses > are not valid? I suggest the following text in section 14.3.5 (rev -19): > > When the client receives a NoPrefixMatch error status in the IA status > field of a Reply to a Confirm, Rebind or Renew message, if the client > can determine through some other means that the addresses in the IA > are valid for the link to which the interface is attached, the client > MAY choose to ignore the NoPrefixMatch error. Examples of ways a client > can determine the validity are: examining prefixes in router > advertisements, receipt of a Confirm message from a different server > that indicates validity of the addresses in the IA, link-layer > specific mechanisms through which the client can determine that it > is currently connected to the link for which the client previously > determined that the addresses in the IA were valid. > > After receiving a NoPrefixMatch error status in the IA status > field of a Reply to a Confirm, Rebind or Renew message, if the client > cannot independently determine that the addresses in the IA are still > valid, the client MUST NOT use any of the addresses in the IA. > > - Ralph ------_=_NextPart_001_01C116B6.221B2DB0 Content-Type: text/html; charset="iso-8859-1" RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]

If so, what does this really mean?

... that the Confirm simply tells the client whether the addresses can
or can not be used and the reason may be (a) client has moved to a new
link or (b) some event happened while it was "gone" and its existing
addresses are no longer valid.

So, doesn't this reinforce what Ted was suggesting all along ... the
Reply to a Confirm that has a "NoPrefixMatch" status in the IA Option is just
input to the client that it *MAY* have moved to a new link but does not
necessarily mean it *HAS* moved to a new link.

Anyway, the action for the client is the same ... do not use the addresses
and go back to the Solicit "state" to find a server with which to communicate
and Request addresses.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Friday, July 27, 2001 11:48 AM
To: DHCPv6 discussion list
Subject: RE: DHCPNACK for DHCPv6 [Proposed Draft Changes]


In IPv6 the prefixes could be deprecated to 2 hours by a router. So it
could happen.  Or by the dhcpv6 serverr.


/jim


On Thu, 26 Jul 2001, Bernie Volz (EUD) wrote:

> Ralph, et al:
>
> The new text works for me.
>
> Regarding your other issue:
> "In the middle of writing my previous message, I had the following thought:
> suppose the link has been renumbered - the addresses in the IA will be
> invalid although the client has remained connected to the same link..."
>
> Isn't this a violation of the address lifetimes? If the lifetimes are
> maintained properly, this should never happen.
>
> And, what's the impact? Won't the server send a NoPrefixMatch in this case
> because the client's prefixes aren't valid - though the client is still on
> the same link? In that case, the client will simply either believe the
> NoPrefixMatch and go through Solicit/Advertise or it will ignore the
> NoPrefixMatch in which case the lifetimes will expire the address anyway.
>
> Note: There will probably be instances because of clock differences where
> a client may still believe an address to be valid when it truely is not.
> But that condition should only last for short periods of time and it is
> adviseable that there be some "grace" involved in lifetimes.
>
> - Bernie
>
> -----Original Message-----
> From: Droms Ralph [mailto:rdroms@cisco.com]
> Sent: Thursday, July 26, 2001 8:28 AM
> To: DHCPv6 discussion list
> Cc: DHCPv6 discussion list
> Subject: Re: DHCPNACK for DHCPv6 [Proposed Draft Changes]
>
>
> At 02:17 PM 7/19/2001 -0700, Ted Lemon wrote:
>
> > > Why should the client make a determination about moving to a new link?  In
> > > fact, how can it make that determination at this point, which is, I think,
> > > after the point at which the client may have received an event from its
> > > interface about loss of carrier, change of access point, etc.?  I suggest
> > > the following text:
> >
> >This is the multiple overlapping link layers problem - a 3G cell phone
> >that is able to contact two different cell towers.  The client in this
> >case has information that the server does not have, and is probably
> >talking to more than one server, and therefore is in a position to
> >know that it can continue to use its addresses.
>
> OK, now I get it.  I misunderstood the phrase "whether it has moved to a
> different link."  In some sense, if the client is communicating with
> overlapping links, it has, in fact, moved to a new link.  It is still on
> the old link, as well...
>
> Is it more that the client can determine, through some other means, that
> the addresses in an IA are valid although some server - through
> misconfiguration, overlapping links, ??? - has indicated that the addresses
> are not valid?  I suggest the following text in section 14.3.5 (rev -19):
>
>     When the client receives a NoPrefixMatch error status in the IA status
>     field of a Reply to a Confirm, Rebind or Renew message, if the client
>     can determine through some other means that the addresses in the IA
>     are valid for the link to which the interface is attached, the client
>     MAY choose to ignore the NoPrefixMatch error.  Examples of ways a client
>     can determine the validity are: examining prefixes in router
>     advertisements, receipt of a Confirm message from a different server
>     that indicates validity of the addresses in the IA, link-layer
>     specific mechanisms through which the client can determine that it
>     is currently connected to the link for which the client previously
>     determined that the addresses in the IA were valid.
>
>     After receiving a NoPrefixMatch error status in the IA status
>     field of a Reply to a Confirm, Rebind or Renew message, if the client
>     cannot independently determine that the addresses in the IA are still
>     valid, the client MUST NOT use any of the addresses in the IA.
>
> - Ralph

------_=_NextPart_001_01C116B6.221B2DB0-- From owner-dhcp-v6@bucknell.edu Fri Jul 27 12:09:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01385; Fri, 27 Jul 2001 12:09:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RGAD827914; Fri, 27 Jul 2001 12:10:13 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RGA7812149 for ; Fri, 27 Jul 2001 12:10:07 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA14839; Fri, 27 Jul 2001 12:10:07 -0400 Date: Fri, 27 Jul 2001 12:10:07 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Advertising prefixes rather than addresses In-Reply-To: <66F66129A77AD411B76200508B65AC697B3336@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I am fine with that too. I don't care either way. I was just providing abstraction of why it might be needed and ramifications to the protocol. /jim On Thu, 26 Jul 2001, Bernie Volz (EUD) wrote: > Well, after trying to construct a message that argued for this because: > - What if you have no router but wanted stateless. > - This could be used in place of stateless when you wanted some level of control > as to which clients used which prefixes (for example, preventing printers from > using global addresses). > - ... > > I also ran across a problem in that servers would need to take care on how this > was used since you could not tell a client to do this multiple times per prefix > (in cases where a client requested multiple IAs). > > And then if the server is doing work anyway to answer these requests, why > not have it do the address assignment as well? It shouldn't be that much more > work for the server to generate an address for the client and log it. > > So, I think we shouldn't bother with this support now. > > - Bernie > > -----Original Message----- > From: Bernard Aboba [mailto:aboba@internaut.com] > Sent: Thursday, July 26, 2001 5:10 PM > To: DHCPv6 discussion list > Subject: Re: Advertising prefixes rather than addresses > > > This is just duplicating functionality that is already in stateless > autoconfig. Presumably you'd use DHCPv6 for addressing if you wanted to do > it statefully. So I don't see the need or purpose of this. > > > > Bernie Volz wrote: > > > > > > > At another time we also discussed using the server to just > > > > advertise prefixes and allowing the client to generate the > > > > addresses? What about adding a "P" bit (next to the "T"-temporary > > > > bit) to indicate that this is a prefix from which the client should > > > > generate an address (or simply allowing it to do so if the > > > > link-identifier field is all 0's). > > > > > > Sounds like a reasonable idea - anyone have a strong reaction (either > > > positive or negative)? > > > > > > - Ralph > From owner-dhcp-v6@bucknell.edu Fri Jul 27 12:11:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01580; Fri, 27 Jul 2001 12:11:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RGBr814995; Fri, 27 Jul 2001 12:11:53 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RGBm820338 for ; Fri, 27 Jul 2001 12:11:48 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA15172; Fri, 27 Jul 2001 12:11:47 -0400 Date: Fri, 27 Jul 2001 12:11:47 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Address lifetime extension and configuration changes in respo nse to Confirm (Was: RE: A few additional items re: -19 draft) In-Reply-To: <66F66129A77AD411B76200508B65AC697B3337@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN good point. we want to do this for the list you sent but tomorrow we may want to send an option that is not relative to address configuration though I can't think of one right now. /jim On Thu, 26 Jul 2001, Bernie Volz (EUD) wrote: > Yes, by all means we need to clean up the language. > > I would also suggest that we add language to state that clients do not send > nor should expect to get other configuration related options (such as Domain Name, > Domain Server Addresses, etc) on the Confirm/Reply sequence. > > We do have to be a bit careful here as there could be options that are important > to send (especially in the future as new options get defined). > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Thursday, July 26, 2001 5:54 PM > To: DHCPv6 discussion list > Subject: Re: Address lifetime extension and configuration changes in > respo nse to Confirm (Was: RE: A few additional items re: -19 draft) > > > > > By NAK I assume we mean "NoPrefixMatch" type error. > > > > By ACK I assume we mean "the prefixes you're using are valid for the link" > > (no indication of whether the addresses themselves are). > > > > I think that's all the Confirm needs to say since I believe all it was > > intended to communicate was whether the client was still on the same > > link. > > This sounds fine, but the present language for this message needs to > be clarified to make this more clear. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Fri Jul 27 12:12:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01818; Fri, 27 Jul 2001 12:12:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RGDH804839; Fri, 27 Jul 2001 12:13:17 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6RGDC822959 for ; Fri, 27 Jul 2001 12:13:12 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f6RGCu504491 for ; Fri, 27 Jul 2001 11:12:57 -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 f6RGCug10312 for ; Fri, 27 Jul 2001 11:12:56 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Jul 27 11:12:47 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 11:12:47 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3346@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Advertise when no addresses available (was: Re: A few additi onal items re: -19 draft) Date: Fri, 27 Jul 2001 11:12:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C116B6.F8759940" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C116B6.F8759940 Content-Type: text/plain; charset="iso-8859-1" You're assuming that all the server does is offer addresses. It may offer other resources and configuration information. Also, don't assume that the ONLY address assignment mechanism is DHCP. Some addresses may well be available via stateless and these could easily be all the client may need. Consider that case where all addesses are autoconfigured by the managed address flag is still set. In that case, perhaps there are cases where most clients won't be given additional addresses but there are some that will be. Do you want those clients to be sending Solicits forever? Perhaps we should consider a new error code to tell the clients that they don't need any addresses. Or perhaps that should be done via a returned IA option with num-addrs of 0. Again, in any case the client is given other configuration information. - Bernie -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@windows.microsoft.com] Sent: Friday, July 27, 2001 12:00 PM To: DHCPv6 discussion list Subject: RE: Advertise when no addresses available (was: Re: A few additional items re: -19 draft) The server can remain silent if it doesn't have any addresses to offer. I don't see much upside for the client if the server says it doesn't have any addresses to offer. thx -----Original Message----- From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se] Sent: Friday, July 27, 2001 7:48 AM To: DHCPv6 discussion list Subject: RE: Advertise when no addresses available (was: Re: A few additional items re: -19 draft) Jitesh/Ralph: After thinking a bit more about this, there is merit in having the server respond. This at least indicates to the client that the server does exist. And, it may be that the server can provide some useful information to the client even though it is unable to give it addresses. It may well be that some addresses are stateless and these may be of sufficient scope to allow the client to obtain other useful configuration information from the server even if it can not get addresses. So, I agree with Jitesh that the best response is IA w/Unavail error. My reason for this is: - I want the server to respond (see above). - Responding without the IA likely means to the client that the server is not willing to give out addresses (but is willing to give other configuration parameters). I do not agree with Jitesh that this will flood the network - clients are supposed to retransmit Solicits periodically and will do so if no server exists anyway. The retransmit timers are set to keep this traffic reasonable. Sure, if you had thousands of clients, you could get a fair amount of traffic. But that's not likely on most link technology in use today (to have that many clients). And, if it is a problem, we better readjust the Solicit retransmit timers anyway. I do believe we need to spell out the server behavior clearly. So, I would suggest text as follows: When responding to a Solicit, the server MUST handle client IA options as follows: - If the server is not configured to offer any addresses to the client (or link), it MUST not include the client's IA option(s) in the Advertise. - If the server is configured to offer addresses to the client (or link) but has no addresses to advertise at the moment, it MUST include the client's IA option(s) with an error of "Unavail". - If the server is configured to offer addresses and has addresses to offer, it MUST include the client's IA option(s) filled out with address information [either the prefixes or the full addresses, as is TBD]. If the above is done, a client can determine whether a server is capable of offering it addresses or not, and whether addresses are presently available or not. In this way, it can determine which server to use (if it needs addresses, use the highest preference server that has addresses available, if none, use the server that can offer addresses but has none at the moment, ...). - Bernie -----Original Message----- From: Jitesh N Verma [ mailto:jitesh@india.hp.com ] Sent: Friday, July 27, 2001 9:45 AM To: DHCPv6 discussion list Subject: Re: Advertise when no addresses available (was: Re: A few additional items re: -19 draft) Ralph, If the server does not respond, client will keep sending Solicit message, flooding the network. This is particularly true when there is only one server in the network. (If there are multiple server in the network, other servers may respond. No problem in this case). Please keep in mind that lease times are not going to be just few seconds. What I mean to say is that if the IP addresses are not available currently, it may not be available for quite some time. Looking at the various options, I will opt for server responding with IA containing Unavail error. I am not in favour of server responding with num-addrs = 0 , since this sort of IA is used to indicate empty IA. Let us not mix up. Let us provide more clarity to the implementer. - Jitesh > I vote for the server to not respond if it has no addresses available. > > - Ralph > > At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote: > >- When forming the Advertise in response to a Solicit, there > >isn't any clear indication of what to do if no addresses may > >be available for the client from that server at that time > >(because all available addresses are in use). In particular, > >should the server: > >- Ignore the Solicit (in the hopes that by the time a subsequent > > Solicit arrives, addresses may be available) > >- Send the Advertise but without the IA option > >- Send the Advertise with the IA option but with an error (such > > as Unavail) > >- Send the Advertise with the IA option with num-addrs = 0 > > > >Or, should a client be prepared to handle all of the above? > > -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ------_=_NextPart_001_01C116B6.F8759940 Content-Type: text/html; charset="iso-8859-1" RE: Advertise when no addresses available (was: Re: A few additional items re: -19 draft)
You're assuming that all the server does is offer addresses. It may offer other resources and configuration information. Also, don't
assume that the ONLY address assignment mechanism is DHCP. Some addresses may well be available via stateless and
these could easily be all the client may need.
 
Consider that case where all addesses are autoconfigured by the managed address flag is still set. In that case, perhaps there
are cases where most clients won't be given additional addresses but there are some that will be. Do you want those clients
to be sending Solicits forever?
 
Perhaps we should consider a new error code to tell the clients that they don't need any addresses. Or perhaps that should be
done via a returned IA option with num-addrs of 0.
 
Again, in any case the client is given other configuration information.
 
- Bernie 
-----Original Message-----
From: Thirumalesh Bhat [mailto:thirub@windows.microsoft.com]
Sent: Friday, July 27, 2001 12:00 PM
To: DHCPv6 discussion list
Subject: RE: Advertise when no addresses available (was: Re: A few additional items re: -19 draft)

The server can remain silent if it doesn’t have any addresses to offer. I don’t see much upside for the client if the server says it doesn’t have any addresses to offer.

 

thx

 

-----Original Message-----
From: Bernie Volz (EUD) [mailto:Bernie.Volz@am1.ericsson.se]
Sent: Friday, July 27, 2001 7:48 AM
To: DHCPv6 discussion list
Subject: RE: Advertise when no addresses available (was: Re: A few additional items re: -19 draft)

 

Jitesh/Ralph:

After thinking a bit more about this, there is merit in having the server respond.
This at least indicates to the client that the server does exist. And, it may be
that the server can provide some useful information to the client even though it
is unable to give it addresses. It may well be that some addresses are stateless
and these may be of sufficient scope to allow the client to obtain other useful
configuration information from the server even if it can not get addresses.

So, I agree with Jitesh that the best response is IA w/Unavail error. My reason for
this is:
- I want the server to respond (see above).
- Responding without the IA likely means to the client that the server is not willing
to give out addresses (but is willing to give other configuration parameters).

I do not agree with Jitesh that this will flood the network - clients are supposed
to retransmit Solicits periodically and will do so if no server exists anyway. The
retransmit timers are set to keep this traffic reasonable. Sure, if you had thousands
of clients, you could get a fair amount of traffic. But that's not likely on most
link technology in use today (to have that many clients). And, if it is a problem,
we better readjust the Solicit retransmit timers anyway.

I do believe we need to spell out the server behavior clearly. So, I would suggest
text as follows:

When responding to a Solicit, the server MUST handle client IA options as follows:
- If the server is not configured to offer any addresses to the client (or link),
it MUST not include the client's IA option(s) in the Advertise.
- If the server is configured to offer addresses to the client (or link) but has
no addresses to advertise at the moment, it MUST include the client's IA option(s)
with an error of "Unavail".
- If the server is configured to offer addresses and has addresses to offer, it
MUST include the client's IA option(s) filled out with address information [either
the prefixes or the full addresses, as is TBD].

If the above is done, a client can determine whether a server is capable of offering
it addresses or not, and whether addresses are presently available or not. In this
way, it can determine which server to use (if it needs addresses, use the highest
preference server that has addresses available, if none, use the server that can
offer addresses but has none at the moment, ...).

- Bernie

 

-----Original Message-----
From: Jitesh N Verma [mailto:jitesh@india.hp.com]
Sent: Friday, July 27, 2001 9:45 AM
To: DHCPv6 discussion list
Subject: Re: Advertise when no addresses available (was: Re: A few
additional items re: -19 draft)

 

Ralph,
        If the server does not respond, client will keep sending Solicit
message, flooding the network. This is particularly true when there is only
one server in the network. (If there are multiple server in the network, other
servers may respond. No problem in this case). Please keep in mind that lease
times are not going to be just few seconds. What I mean to say is that if the
IP addresses are not available currently, it may not be available for quite
some time.
        Looking at the various options, I will opt for server responding with
IA containing Unavail error. I am not in favour of server responding with
num-addrs = 0 , since this sort of IA is used to indicate empty IA. Let us
not mix up. Let us provide more clarity to the implementer.

- Jitesh
               

 

> I vote for the server to not respond if it has no addresses available.
>
> - Ralph
>
> At 12:10 PM 7/23/2001 -0500, Bernie Volz (EUD) wrote:
> >- When forming the Advertise in response to a Solicit, there
> >isn't any clear indication of what to do if no addresses may
> >be available for the client from that server at that time
> >(because all available addresses are in use). In particular,
> >should the server:
> >- Ignore the Solicit (in the hopes that by the time a subsequent
> >   Solicit arrives, addresses may be available)
> >- Send the Advertise but without the IA option
> >- Send the Advertise with the IA option but with an error (such
> >   as Unavail)
> >- Send the Advertise with the IA option with num-addrs = 0
> >
> >Or, should a client be prepared to handle all of the above?
>
>

 

--
-----------------------------------------------------------------------

    ~                                                             ~
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*
^ Jitesh N. Verma                     Tel. 91-80-225 1554 Ext. 1424   ^
^ HEWLETT PACKARD                     Fax. 91-80-220 0196             ^
^ INDIA SOFTWARE OPERATIONS         Email. jitesh@india.hp.com        ^
^ 29, CUNNINGHAM ROAD               Pager. 9624-263608                ^
^ BANGALORE 560 052        __      Telnet. 847-1424                   ^
^                         / /                                         ^
^                        / /___ _____                                 ^
^                       / __  // __  /                                ^
^                      / / / // /_/ /                                 ^
^                     /_/ /_// ____/                                  ^
^                           / /                                       ^
^                          /_/                                        ^
*~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~*

------_=_NextPart_001_01C116B6.F8759940-- From owner-dhcp-v6@bucknell.edu Fri Jul 27 12:30:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03872; Fri, 27 Jul 2001 12:30:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RGV8829617; Fri, 27 Jul 2001 12:31:08 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6RGUu825994 for ; Fri, 27 Jul 2001 12:30:57 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA03439; Fri, 27 Jul 2001 09:30:41 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id f6RGUfB26556; Fri, 27 Jul 2001 09:30:41 -0700 X-mProtect: Fri, 27 Jul 2001 09:30:41 -0700 Nokia Silicon Valley Messaging Protection Received: from charliep.iprg.nokia.com (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com(P1.5 smtpdnnDNuA; Fri, 27 Jul 2001 09:30:39 PDT Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3B61972F.AF33B03F@iprg.nokia.com> Date: Fri, 27 Jul 2001 09:30:39 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list CC: dhcp-v6@bucknell.edu Subject: Re: Advertising prefixes rather than addresses References: <200107271402.TAA07919@chitha.india.hp.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: charliep@iprg.nokia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello, As I was one of the SLP guys, I have to point out that this is a totally inaccurate characterization. SLP works a lot different than DHCP, we didn't steal anything from DHCP and there was never any Service Location feature in DHCP. Maybe instead you were thinking of some specific options for things like DNS server addresses. That is a lot different. Charlie P. Jitesh N Verma wrote: > > What can't we have this functionality in DHCP?? > 1) Stateless autoconfiguration through router advertizement has already > hijacked half of the DHCP's usefulness. > 2) SLP guys have hijacked the idea of Service Location from DHCP. > 3) DNS guys are thinking of putting a mini DHCP in the DNS. From owner-dhcp-v6@bucknell.edu Fri Jul 27 12:42:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05204; Fri, 27 Jul 2001 12:42:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RGgI803738; Fri, 27 Jul 2001 12:42:18 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RGgA808461 for ; Fri, 27 Jul 2001 12:42:10 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA13920; Fri, 27 Jul 2001 12:42:10 -0400 Date: Fri, 27 Jul 2001 12:42:10 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit In-Reply-To: <66F66129A77AD411B76200508B65AC697B3338@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN what my understanding of this is as follows. 1. we removed the design center/model that clients request specific number of addresses. that I think has consensus and I hope we don't revisit that again. 2. we would like an optimization in dhcpv6 that a client be able to get addresses to use from solicit. we knew we needed more words here and ralph and I assumed draft 20 for this per discussion which we are having so that is great. thats how we got there and where we are for continuity. what were we thinking question? first keep it simple (ergo cheap to implement and for the network traffic esp mobile nodes). client can use ORO with solicit say for IA and addresses? but can a server know the IA from solicit with just ORO? No. should we fix the above ? if we can avoid anythink but ORO thats a good thing for the protocol design is my thought so I think not is my input. so the server when giving address back to client on advertise means the server must be able to maintain it did this (thats why its only an option not mainstream). I think this is doable but we should not specify in detail now. leave it to implementaiton defined after we are in PS and get some practical running code experience we can re discuss this aspect. the client would be able to send addresses back in the advertise (ignoring the prefix stateless debate for now). the client should do DAD on the addresses. if tehy fail a decline should be sent and the server will know how to determine which client declined (implementaiton defined above). if success at the client then a request is generated and the server kills the temp cache (or whatever) from the advertise and builds complete database set for those client addresses. would this work for everyone to go to last call? if so ralph and I can go built the wordage for next spec version for last call? [note - whether to permit prefixes only to clients emulating stateless should be transparent to this answer] thanks /jim On Thu, 26 Jul 2001, Bernie Volz (EUD) wrote: > See comments below, prefixed by BV>. > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, July 26, 2001 4:43 PM > To: DHCPv6 discussion list > Subject: Addresses and other parameters in Advertise and Solicit > > > Bernie Volz wrote: > > >1. In Section 14.3.1 (Creation and sending of Request messages), there > > is no mention of using any of the "information" supplied by a > > server in the Advertise message (in response to a Solicit). In > > DHCPv4, the client sent information received in the Offer. We > > probably should be explicit about this and perhaps even suggest > > that the information received by a client in an Advertise is > > basically for information purposes only to help it determine > > whether this server will offer it what it needs. > > So, are you suggesting that the DHCPv6 client Request exactly the addresses > and options from the Solicit, or no addresses or options, or ??? > > BV> I'm trying to figure out exactly what you, Jim, and others were expecting. > BV> Since there isn't anything in the text about exactly how this is expected > BV> to work, I would like some clarification. > BV> > BV> I do feel that servers will have less work to do if they don't have > BV> to return full addresses that clients can use. The reason for this is > BV> that the server doesn't have to assign the address until it receives > BV> the request. And when multiple servers are running, this is a potential > BV> big win as the Request will only go to one of those servers. > > > Perhaps the > > addresses assigned in the Advertise should even just be prefixes > > (interface portion all 0's)? > > I don't have a strong feeling one way or the other. > > BV> See above as to why I feel it best that they are just the prefixes. > > > If instead we want the server to assign "real" addresses, should > > something be said about how long those should be valid and whether the > > server should attempt to assign those same addresses to the client in > > a subsequent Request/Reply exchange for the IA? Perhaps we could punt > > and say this is a server implementation issue (whether it assigns real > > addresses and whether those are held for some (short) time for the > > client)? > > I take "valid" in this context to mean "reserved for this client". Has > this scenario been a problem in DHCPv4? Do we need to specify any more > mechanism than we have in the DHCPv4 spec? > > BV> Yes, valid means "reserved" for that client binding (DUID/IAID). > BV> Well, I think the message timeouts and retransmission might dictate > BV> the total time a server should put on these lifetimes. > > > NOTE: If real addresses are returned, perhaps a client might even > > initiate DAD during the Request/Reply in which case it can do these > > two items in parallel (though this would be somewhat tricky since it > > would not want to Decline the addresses before receiving the Reply). > > Hm. I guess I had anticipated that the client would do DAD and either > Request or Decline the addresses in the Advertise. It is the case that the > spec does not constrain the times at which a Decline can be sent. I'm not > sure it makes much sense for the client to Request a set of addresses and > then Decline them later. > > BV> Hm back. Doesn't this make for a bizarre client implementation? > BV> Recall that a client doesn't go through the Solicit/Advertise phase > BV> for all of the addresses. It can issue additional Requests at any > BV> time. Also, Renews can result in additional addresses being granted. > BV> Under those cases the client must DAD them as well. Just seems so > BV> much easier to be consistent and have the client get some addresses > BV> and before using them run DAD. If the addresses are bad, then it > BV> Declines them. > > BV> Also, if the DHCP server is doing its job, DAD really should be an > BV> extremely infrequent event - more likely caused when switching from > BV> stateless to managed or if you have broken clients. > > BV> If you want to allow DAD after Advertise (and a Decline before a > BV> Request), then we do need to make that very clear in the draft since > BV> that has never been my understanding. Did I miss something in the > BV> draft? > > - Ralph > From owner-dhcp-v6@bucknell.edu Fri Jul 27 14:10:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14978; Fri, 27 Jul 2001 14:10:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RIAW823405; Fri, 27 Jul 2001 14:10:32 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6RIAH827340 for ; Fri, 27 Jul 2001 14:10:17 -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 f6RIAGp09338 for ; Fri, 27 Jul 2001 13:10:16 -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 f6RIAGb09798 for ; Fri, 27 Jul 2001 13:10:16 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Fri Jul 27 13:10:15 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 13:10:15 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3347@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit Date: Fri, 27 Jul 2001 13:10:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C116C7.6181BD00" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C116C7.6181BD00 Content-Type: text/plain; charset="iso-8859-1" Jim: I do feel differently about this. >From what I recall, the *ORIGINAL* model was that Solicit would *ONLY* be used to find servers (based on Advertise) and no addresses or parameters would be provided, I don't see why we have this major shift. The *PROBLEM* that we had with not sending back anything about addresses in the Advertise was how does a client know when there are multiple servers which might be able to give it addresses (this was basically how to pick a "good" server rather than just simply the highest preference). So, I think you are changing the rules significantly and I for one don't think it is a good idea to do DAD on information (addresses) in the Advertise. There are also issues with this: - DAD isn't done consistently (as I pointed out below). It's done before Request in some cases but not in all. Seems kind of weird to me. - During the Solicit/Advertise, DAD, Request/Reply phase, does the client have to honor the lifetimes in the addresses? Thus, if a server sends back short lifetimes and the client doesn't complete the process (get a Reply), does it have to abort? Or, does it now send a Renew even before it has requested the addresses? Now, this hopefully won't happen because servers will return reasonable lifetimes, but ... - What if a client only wants to use an address for a short time. Does it every have to Request the address? Perhaps the lifetime it gets from the server in the Advertise is sufficient for its purposes. Let's use Advertise for what it was intended - to allow a client to find a reasonable server. Let's use Request/Reply to do the address allocation. - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Friday, July 27, 2001 12:42 PM To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit what my understanding of this is as follows. 1. we removed the design center/model that clients request specific number of addresses. that I think has consensus and I hope we don't revisit that again. 2. we would like an optimization in dhcpv6 that a client be able to get addresses to use from solicit. we knew we needed more words here and ralph and I assumed draft 20 for this per discussion which we are having so that is great. thats how we got there and where we are for continuity. what were we thinking question? first keep it simple (ergo cheap to implement and for the network traffic esp mobile nodes). client can use ORO with solicit say for IA and addresses? but can a server know the IA from solicit with just ORO? No. should we fix the above ? if we can avoid anythink but ORO thats a good thing for the protocol design is my thought so I think not is my input. so the server when giving address back to client on advertise means the server must be able to maintain it did this (thats why its only an option not mainstream). I think this is doable but we should not specify in detail now. leave it to implementaiton defined after we are in PS and get some practical running code experience we can re discuss this aspect. the client would be able to send addresses back in the advertise (ignoring the prefix stateless debate for now). the client should do DAD on the addresses. if tehy fail a decline should be sent and the server will know how to determine which client declined (implementaiton defined above). if success at the client then a request is generated and the server kills the temp cache (or whatever) from the advertise and builds complete database set for those client addresses. would this work for everyone to go to last call? if so ralph and I can go built the wordage for next spec version for last call? [note - whether to permit prefixes only to clients emulating stateless should be transparent to this answer] thanks /jim On Thu, 26 Jul 2001, Bernie Volz (EUD) wrote: > See comments below, prefixed by BV>. > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Thursday, July 26, 2001 4:43 PM > To: DHCPv6 discussion list > Subject: Addresses and other parameters in Advertise and Solicit > > > Bernie Volz wrote: > > >1. In Section 14.3.1 (Creation and sending of Request messages), there > > is no mention of using any of the "information" supplied by a > > server in the Advertise message (in response to a Solicit). In > > DHCPv4, the client sent information received in the Offer. We > > probably should be explicit about this and perhaps even suggest > > that the information received by a client in an Advertise is > > basically for information purposes only to help it determine > > whether this server will offer it what it needs. > > So, are you suggesting that the DHCPv6 client Request exactly the addresses > and options from the Solicit, or no addresses or options, or ??? > > BV> I'm trying to figure out exactly what you, Jim, and others were expecting. > BV> Since there isn't anything in the text about exactly how this is expected > BV> to work, I would like some clarification. > BV> > BV> I do feel that servers will have less work to do if they don't have > BV> to return full addresses that clients can use. The reason for this is > BV> that the server doesn't have to assign the address until it receives > BV> the request. And when multiple servers are running, this is a potential > BV> big win as the Request will only go to one of those servers. > > > Perhaps the > > addresses assigned in the Advertise should even just be prefixes > > (interface portion all 0's)? > > I don't have a strong feeling one way or the other. > > BV> See above as to why I feel it best that they are just the prefixes. > > > If instead we want the server to assign "real" addresses, should > > something be said about how long those should be valid and whether the > > server should attempt to assign those same addresses to the client in > > a subsequent Request/Reply exchange for the IA? Perhaps we could punt > > and say this is a server implementation issue (whether it assigns real > > addresses and whether those are held for some (short) time for the > > client)? > > I take "valid" in this context to mean "reserved for this client". Has > this scenario been a problem in DHCPv4? Do we need to specify any more > mechanism than we have in the DHCPv4 spec? > > BV> Yes, valid means "reserved" for that client binding (DUID/IAID). > BV> Well, I think the message timeouts and retransmission might dictate > BV> the total time a server should put on these lifetimes. > > > NOTE: If real addresses are returned, perhaps a client might even > > initiate DAD during the Request/Reply in which case it can do these > > two items in parallel (though this would be somewhat tricky since it > > would not want to Decline the addresses before receiving the Reply). > > Hm. I guess I had anticipated that the client would do DAD and either > Request or Decline the addresses in the Advertise. It is the case that the > spec does not constrain the times at which a Decline can be sent. I'm not > sure it makes much sense for the client to Request a set of addresses and > then Decline them later. > > BV> Hm back. Doesn't this make for a bizarre client implementation? > BV> Recall that a client doesn't go through the Solicit/Advertise phase > BV> for all of the addresses. It can issue additional Requests at any > BV> time. Also, Renews can result in additional addresses being granted. > BV> Under those cases the client must DAD them as well. Just seems so > BV> much easier to be consistent and have the client get some addresses > BV> and before using them run DAD. If the addresses are bad, then it > BV> Declines them. > > BV> Also, if the DHCP server is doing its job, DAD really should be an > BV> extremely infrequent event - more likely caused when switching from > BV> stateless to managed or if you have broken clients. > > BV> If you want to allow DAD after Advertise (and a Decline before a > BV> Request), then we do need to make that very clear in the draft since > BV> that has never been my understanding. Did I miss something in the > BV> draft? > > - Ralph > ------_=_NextPart_001_01C116C7.6181BD00 Content-Type: text/html; charset="iso-8859-1" RE: Addresses and other parameters in Advertise and Solicit

Jim:

I do feel differently about this.

From what I recall, the *ORIGINAL* model was that Solicit would *ONLY* be
used to find servers (based on Advertise) and no addresses or parameters
would be provided, I don't see why we have this major shift. The *PROBLEM*
that we had with not sending back anything about addresses in the Advertise
was how does a client know when there are multiple servers which might be
able to give it addresses (this was basically how to pick a "good" server
rather than just simply the highest preference).

So, I think you are changing the rules significantly and I for one don't think
it is a good idea to do DAD on information (addresses) in the Advertise.

There are also issues with this:
- DAD isn't done consistently (as I pointed out below). It's done before
Request in some cases but not in all. Seems kind of weird to me.
- During the Solicit/Advertise, DAD, Request/Reply phase, does the client
have to honor the lifetimes in the addresses? Thus, if a server sends back
short lifetimes and the client doesn't complete the process (get a Reply),
does it have to abort? Or, does it now send a Renew even before it has
requested the addresses? Now, this hopefully won't happen because servers
will return reasonable lifetimes, but ...
- What if a client only wants to use an address for a short time. Does it
every have to Request the address? Perhaps the lifetime it gets from the
server in the Advertise is sufficient for its purposes.

Let's use Advertise for what it was intended - to allow a client to find a
reasonable server. Let's use Request/Reply to do the address allocation.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Friday, July 27, 2001 12:42 PM
To: DHCPv6 discussion list
Subject: RE: Addresses and other parameters in Advertise and Solicit


what my understanding of this is as follows.

1.  we removed the design center/model that clients request specific
number of addresses.  that I think has consensus and I hope we don't
revisit that again.

2. we would like an optimization in dhcpv6 that a client be able to get
addresses to use from solicit.  we knew we needed more words here and
ralph and I assumed draft 20 for this per discussion which we are having
so that is great.

thats how we got there and where we are for continuity.

what were we thinking question?

first keep it simple (ergo cheap to implement and for the network
traffic esp mobile nodes).

client can use ORO with solicit say for IA and addresses?

but can a server know the IA from solicit with just ORO? No.

should we fix the above ?  if we can avoid anythink but ORO thats a good
thing for the protocol design is my thought so I think not is my input.

so the server when giving address back to client on advertise means the
server must be able to maintain it did this (thats why its only an option
not mainstream).  I think this is doable but we should not specify in
detail now.  leave it to implementaiton defined after we are in PS and get
some practical running code experience we can re discuss this aspect.

the client would be able to send addresses back in the advertise (ignoring
the prefix stateless debate for now).

the client should do DAD on the addresses.

if tehy fail a decline should be sent and the server will know how to
determine which client declined (implementaiton defined above).

if success at the client then a request is generated and the server kills
the temp cache (or whatever) from the advertise and builds complete
database set for those client addresses.

would this work for everyone to go to last call?

if so ralph and I can go built the wordage for next spec version for last
call?

[note - whether to permit prefixes only to clients emulating stateless
should be transparent to this answer]

thanks


/jim


On Thu, 26 Jul 2001, Bernie Volz (EUD) wrote:

> See comments below, prefixed by BV>.
>
> -----Original Message-----
> From: Ralph Droms [mailto:rdroms@cisco.com]
> Sent: Thursday, July 26, 2001 4:43 PM
> To: DHCPv6 discussion list
> Subject: Addresses and other parameters in Advertise and Solicit
>
>
> Bernie Volz wrote:
>
> >1. In Section 14.3.1 (Creation and sending of Request messages), there
> >    is no mention of using any of the "information" supplied by a
> >    server in the Advertise message (in response to a Solicit). In
> >    DHCPv4, the client sent information received in the Offer. We
> >    probably should be explicit about this and perhaps even suggest
> >    that the information received by a client in an Advertise is
> >    basically for information purposes only to help it determine
> >    whether this server will offer it what it needs.
>
> So, are you suggesting that the DHCPv6 client Request exactly the addresses
> and options from the Solicit, or no addresses or options, or ???
>
> BV> I'm trying to figure out exactly what you, Jim, and others were expecting.
> BV> Since there isn't anything in the text about exactly how this is expected
> BV> to work, I would like some clarification.
> BV>
> BV> I do feel that servers will have less work to do if they don't have
> BV> to return full addresses that clients can use. The reason for this is
> BV> that the server doesn't have to assign the address until it receives
> BV> the request. And when multiple servers are running, this is a potential
> BV> big win as the Request will only go to one of those servers.
>
> >    Perhaps the
> >    addresses assigned in the Advertise should even just be prefixes
> >    (interface portion all 0's)?
>
> I don't have a strong feeling one way or the other.
>
> BV> See above as to why I feel it best that they are just the prefixes.
>
> >    If instead we want the server to assign "real" addresses, should
> >    something be said about how long those should be valid and whether the
> >    server should attempt to assign those same addresses to the client in
> >    a subsequent Request/Reply exchange for the IA? Perhaps we could punt
> >    and say this is a server implementation issue (whether it assigns real
> >    addresses and whether those are held for some (short) time for the
> >    client)?
>
> I take "valid" in this context to mean "reserved for this client".  Has
> this scenario been a problem in DHCPv4?  Do we need to specify any more
> mechanism than we have in the DHCPv4 spec?
>
> BV> Yes, valid means "reserved" for that client binding (DUID/IAID).
> BV> Well, I think the message timeouts and retransmission might dictate
> BV> the total time a server should put on these lifetimes.
>
> >    NOTE: If real addresses are returned, perhaps a client might even
> >    initiate DAD during the Request/Reply in which case it can do these
> >    two items in parallel (though this would be somewhat tricky since it
> >    would not want to Decline the addresses before receiving the Reply).
>
> Hm.  I guess I had anticipated that the client would do DAD and either
> Request or Decline the addresses in the Advertise.  It is the case that the
> spec does not constrain the times at which a Decline can be sent.  I'm not
> sure it makes much sense for the client to Request a set of addresses and
> then Decline them later.
>
> BV> Hm back. Doesn't this make for a bizarre client implementation?
> BV> Recall that a client doesn't go through the Solicit/Advertise phase
> BV> for all of the addresses. It can issue additional Requests at any
> BV> time. Also, Renews can result in additional addresses being granted.
> BV> Under those cases the client must DAD them as well. Just seems so
> BV> much easier to be consistent and have the client get some addresses
> BV> and before using them run DAD. If the addresses are bad, then it
> BV> Declines them.
>
> BV> Also, if the DHCP server is doing its job, DAD really should be an
> BV> extremely infrequent event - more likely caused when switching from
> BV> stateless to managed or if you have broken clients.
>
> BV> If you want to allow DAD after Advertise (and a Decline before a
> BV> Request), then we do need to make that very clear in the draft since
> BV> that has never been my understanding. Did I miss something in the
> BV> draft?
>
> - Ralph
>

------_=_NextPart_001_01C116C7.6181BD00-- From owner-dhcp-v6@bucknell.edu Fri Jul 27 15:03:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20376; Fri, 27 Jul 2001 15:03:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RIvg802299; Fri, 27 Jul 2001 14:57:42 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RIvd801119 for ; Fri, 27 Jul 2001 14:57:39 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA20652; Fri, 27 Jul 2001 14:57:38 -0400 Date: Fri, 27 Jul 2001 14:57:38 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit In-Reply-To: <66F66129A77AD411B76200508B65AC697B3347@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie, Not my idea I am the messenger here trying to get to PS. Mark was the first one to suggest this as optimization on Ralph's very 1st design team con call over a year ago. So I am just reiterating my understanding not my wishes. More comments below. Don't shoot the messenger. Or the co-author trying to achieve consensus. On Fri, 27 Jul 2001, Bernie Volz (EUD) wrote: > Jim: > > I do feel differently about this. > > >From what I recall, the *ORIGINAL* model was that Solicit would *ONLY* be > used to find servers (based on Advertise) and no addresses or parameters > would be provided, I don't see why we have this major shift. The *PROBLEM* > that we had with not sending back anything about addresses in the Advertise > was how does a client know when there are multiple servers which might be > able to give it addresses (this was basically how to pick a "good" server > rather than just simply the highest preference). That is addressed in the current draft by statements what the client can do with multiple advertisements. Clearly a server will timeout their advertize cache to see if client sends addresses and no request comes back. I for one don't think we need to say this in an IETF spec either so I disagree with a lot of the wordy input you want for clarification. An implementor should see there is no NAK to the server code base and realize a timeout is needed to end the state to maintain the information. We could provide a suggestion for that time and should be configurable by the sys admin. > So, I think you are changing the rules significantly and I for one don't think > it is a good idea to do DAD on information (addresses) in the Advertise. > DAD is not an issue here at all. Its the communications btw the client and the server that we are working on and IPv6 is fine behind that (meaning DAD works. > There are also issues with this: > - DAD isn't done consistently (as I pointed out below). It's done before > Request in some cases but not in all. Seems kind of weird to me. I was suggesting (if we do this) that we make it consistent after an advertise and when the client has selected the server. Why is that weird. You just enter the code thread on your platform where you build DAD, Usolicited Mcastaddr, and do the DAD thing. That code all exists. If it doesn't then IPv6 won't work on the platform anyway. Then just set up the reply from the function you call into your DAD module. Why is that weird? thanks or are you making another point I am missing? > - During the Solicit/Advertise, DAD, Request/Reply phase, does the client > have to honor the lifetimes in the addresses? Thus, if a server sends back > short lifetimes and the client doesn't complete the process (get a Reply), > does it have to abort? Or, does it now send a Renew even before it has > requested the addresses? Now, this hopefully won't happen because servers > will return reasonable lifetimes, but ... WOW. DAD is like nanoseconds. Lets put it this way when IPv6 comes up on our platforms it happens during boot phase so fast we could not dump it during AD of IPv6 to see it. Had to hack around it. So if an admin says an address is on 5 minutes good then thats just stupid and they should suffer from being incompetent. But seriously I don't think this will happen in practice even as exception but if it did the client should never do a renew without a request. That is asking for to much state in the server for this optimization. > - What if a client only wants to use an address for a short time. Does it > every have to Request the address? Perhaps the lifetime it gets from the > server in the Advertise is sufficient for its purposes. Yes the client has to do this because in our model the server owns the addresses, times, and everything about the address. The client must request the address after the advertise. Its the right way to tell the server I am now keeping this and by the way Mr. server I got pass DAD too (indirectly of course). > > Let's use Advertise for what it was intended - to allow a client to find a > reasonable server. Let's use Request/Reply to do the address allocation. Hmmm. I have no comment on this as co-author for now. I am merely explaining a way this can be done. What you ask is WG consensus questioins. I was assuming we wanted to do what Mark suggested maybe I am wrong. Comments from others please.............. thanks /jim From owner-dhcp-v6@bucknell.edu Fri Jul 27 15:26:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22662; Fri, 27 Jul 2001 15:26:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6RJOn828874; Fri, 27 Jul 2001 15:24:49 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6RJOg812022 for ; Fri, 27 Jul 2001 15:24:42 -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 f6RJOfp14954 for ; Fri, 27 Jul 2001 14:24: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 f6RJOfb16280 for ; Fri, 27 Jul 2001 14:24:41 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Fri Jul 27 14:24:41 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 27 Jul 2001 14:24:41 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3349@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit Date: Fri, 27 Jul 2001 14:24:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C116D1.C620AA50" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C116D1.C620AA50 Content-Type: text/plain; charset="iso-8859-1" Jim: Sorry to appear to be shooting the messenger. Just trying to get this worked out. >Why is that weird. You just enter the code thread on your platform where >you build DAD, Usolicited Mcastaddr, and do the DAD thing. That code all >exists. If it doesn't then IPv6 won't work on the platform anyway. Then >just set up the reply from the function you call into your DAD module. >Why is that weird? thanks or are you making another point I am missing? The reason it is weird is that in other cases you're basically using DAD once you have a "provisional" address. Yet, in this case, you don't yet have this address "assigned" - it was just advertised. Are you intending to allow the client to use the address once DAD is done? Or, MUST the client wait until it receives a Reply from the server? While under normal cases this would be relatively quick, there can be times when it is not - such as if several hops are required to reach a server and you have a short term link failure somewhere in that path. And, what happens if the server went down and you're unable to Request the addresses. If you've installed them at the client already, you'd be in trouble with connections that might have used them. So, basically you have this interval between when DAD was complete and until you receive the Reply that the address can not be used, but you must still respond to DAD messages (since otherwise if two clients were Advertised the same address - hopefully by different servers - then the client must respond). This seems to imply that you require a new "state" for an address - post DAD but before it's OK to use. If you wait until after the Request/Reply, you don't have this issue. You can just do what you do for stateless ... install the address as "provisional" and once DAD is done, you're good to go. The address can be used. And, let me again point out that what you must do anyway should the server assign more addresses or you get addresses from additional Requests. So, once again if you do Advertised addresses differently, the client must remember "oh, I've already run DAD on this so I don't need to do it again". I am trying to keep the implementation simple. That's exactly why I suggest we defer DAD until after Reply. - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Friday, July 27, 2001 2:58 PM To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit Bernie, Not my idea I am the messenger here trying to get to PS. Mark was the first one to suggest this as optimization on Ralph's very 1st design team con call over a year ago. So I am just reiterating my understanding not my wishes. More comments below. Don't shoot the messenger. Or the co-author trying to achieve consensus. On Fri, 27 Jul 2001, Bernie Volz (EUD) wrote: > Jim: > > I do feel differently about this. > > >From what I recall, the *ORIGINAL* model was that Solicit would *ONLY* be > used to find servers (based on Advertise) and no addresses or parameters > would be provided, I don't see why we have this major shift. The *PROBLEM* > that we had with not sending back anything about addresses in the Advertise > was how does a client know when there are multiple servers which might be > able to give it addresses (this was basically how to pick a "good" server > rather than just simply the highest preference). That is addressed in the current draft by statements what the client can do with multiple advertisements. Clearly a server will timeout their advertize cache to see if client sends addresses and no request comes back. I for one don't think we need to say this in an IETF spec either so I disagree with a lot of the wordy input you want for clarification. An implementor should see there is no NAK to the server code base and realize a timeout is needed to end the state to maintain the information. We could provide a suggestion for that time and should be configurable by the sys admin. > So, I think you are changing the rules significantly and I for one don't think > it is a good idea to do DAD on information (addresses) in the Advertise. > DAD is not an issue here at all. Its the communications btw the client and the server that we are working on and IPv6 is fine behind that (meaning DAD works. > There are also issues with this: > - DAD isn't done consistently (as I pointed out below). It's done before > Request in some cases but not in all. Seems kind of weird to me. I was suggesting (if we do this) that we make it consistent after an advertise and when the client has selected the server. Why is that weird. You just enter the code thread on your platform where you build DAD, Usolicited Mcastaddr, and do the DAD thing. That code all exists. If it doesn't then IPv6 won't work on the platform anyway. Then just set up the reply from the function you call into your DAD module. Why is that weird? thanks or are you making another point I am missing? > - During the Solicit/Advertise, DAD, Request/Reply phase, does the client > have to honor the lifetimes in the addresses? Thus, if a server sends back > short lifetimes and the client doesn't complete the process (get a Reply), > does it have to abort? Or, does it now send a Renew even before it has > requested the addresses? Now, this hopefully won't happen because servers > will return reasonable lifetimes, but ... WOW. DAD is like nanoseconds. Lets put it this way when IPv6 comes up on our platforms it happens during boot phase so fast we could not dump it during AD of IPv6 to see it. Had to hack around it. So if an admin says an address is on 5 minutes good then thats just stupid and they should suffer from being incompetent. But seriously I don't think this will happen in practice even as exception but if it did the client should never do a renew without a request. That is asking for to much state in the server for this optimization. > - What if a client only wants to use an address for a short time. Does it > every have to Request the address? Perhaps the lifetime it gets from the > server in the Advertise is sufficient for its purposes. Yes the client has to do this because in our model the server owns the addresses, times, and everything about the address. The client must request the address after the advertise. Its the right way to tell the server I am now keeping this and by the way Mr. server I got pass DAD too (indirectly of course). > > Let's use Advertise for what it was intended - to allow a client to find a > reasonable server. Let's use Request/Reply to do the address allocation. Hmmm. I have no comment on this as co-author for now. I am merely explaining a way this can be done. What you ask is WG consensus questioins. I was assuming we wanted to do what Mark suggested maybe I am wrong. Comments from others please.............. thanks /jim ------_=_NextPart_001_01C116D1.C620AA50 Content-Type: text/html; charset="iso-8859-1" RE: Addresses and other parameters in Advertise and Solicit

Jim:

Sorry to appear to be shooting the messenger. Just trying to get this worked
out.

>Why is that weird.  You just enter the code thread on your platform where
>you build DAD, Usolicited Mcastaddr, and do the DAD thing.  That code all
>exists.  If it doesn't then IPv6 won't work on the platform anyway.  Then
>just set up the reply from the function you call into your DAD module.
>Why is that weird?  thanks  or are you making another point I am missing?

The reason it is weird is that in other cases you're basically using DAD
once you have a "provisional" address. Yet, in this case, you don't yet
have this address "assigned" - it was just advertised.

Are you intending to allow the client to use the address once DAD is done?
Or, MUST the client wait until it receives a Reply from the server? While
under normal cases this would be relatively quick, there can be times when
it is not - such as if several hops are required to reach a server and you
have a short term link failure somewhere in that path.

And, what happens if the server went down and you're unable to Request the
addresses. If you've installed them at the client already, you'd be in
trouble with connections that might have used them.

So, basically you have this interval between when DAD was complete and until
you receive the Reply that the address can not be used, but you must still
respond to DAD messages (since otherwise if two clients were Advertised
the same address - hopefully by different servers - then the client must
respond).

This seems to imply that you require a new "state" for an address - post
DAD but before it's OK to use.

If you wait until after the Request/Reply, you don't have this issue. You
can just do what you do for stateless ... install the address as "provisional"
and once DAD is done, you're good to go. The address can be used.

And, let me again point out that what you must do anyway should the server
assign more addresses or you get addresses from additional Requests. So,
once again if you do Advertised addresses differently, the client must
remember "oh, I've already run DAD on this so I don't need to do it again".

I am trying to keep the implementation simple. That's exactly why I suggest
we defer DAD until after Reply.

- Bernie


-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Friday, July 27, 2001 2:58 PM
To: DHCPv6 discussion list
Subject: RE: Addresses and other parameters in Advertise and Solicit


Bernie,

Not my idea I am the messenger here trying to get to PS.  Mark was the
first one to suggest this as optimization on Ralph's very 1st design team
con call over a year ago.  So I am just reiterating my understanding not
my wishes.

More comments below.

Don't shoot the messenger.  Or the co-author trying to achieve consensus.


On Fri, 27 Jul 2001, Bernie Volz (EUD) wrote:

> Jim:
>
> I do feel differently about this.
>
> >From what I recall, the *ORIGINAL* model was that Solicit would *ONLY* be
> used to find servers (based on Advertise) and no addresses or parameters
> would be provided, I don't see why we have this major shift. The *PROBLEM*
> that we had with not sending back anything about addresses in the Advertise
> was how does a client know when there are multiple servers which might be
> able to give it addresses (this was basically how to pick a "good" server
> rather than just simply the highest preference).

That is addressed in the current draft by statements what the client can
do with multiple advertisements.  Clearly a server will timeout their
advertize cache to see if client sends addresses and no request comes
back.  I for one don't think we need to say this in an IETF spec either so
I disagree with a lot of the wordy input you want for clarification.  An
implementor should see there is no NAK to the server code base and realize
a timeout is needed to end the state to maintain the information.  We
could provide a suggestion for that time and should be configurable by the
sys admin.
 
> So, I think you are changing the rules significantly and I for one don't think
> it is a good idea to do DAD on information (addresses) in the Advertise.
>
 DAD is not an issue here at all.  Its the communications btw the client
and the server that we are working on and IPv6 is fine behind that
(meaning DAD works.

> There are also issues with this:
> - DAD isn't done consistently (as I pointed out below). It's done before
> Request in some cases but not in all. Seems kind of weird to me.

I was suggesting (if we do this) that we make it consistent after an
advertise and when the client has selected the server.

Why is that weird.  You just enter the code thread on your platform where
you build DAD, Usolicited Mcastaddr, and do the DAD thing.  That code all
exists.  If it doesn't then IPv6 won't work on the platform anyway.  Then
just set up the reply from the function you call into your DAD module.
Why is that weird?  thanks  or are you making another point I am missing?

> - During the Solicit/Advertise, DAD, Request/Reply phase, does the client
> have to honor the lifetimes in the addresses? Thus, if a server sends back
> short lifetimes and the client doesn't complete the process (get a Reply),
> does it have to abort? Or, does it now send a Renew even before it has
> requested the addresses? Now, this hopefully won't happen because servers
> will return reasonable lifetimes, but ...

WOW. DAD is like nanoseconds.  Lets put it this way when IPv6 comes up on
our platforms it happens during boot phase so fast we could not dump it
during AD of IPv6 to see it.  Had to hack around it. 

So if an admin says an address is on 5 minutes good then thats just stupid
and they should suffer from being incompetent.  But seriously I don't
think this will happen in practice even as exception but if it did the
client should never do a renew without a request.  That is asking for to
much state in the server for this optimization.

> - What if a client only wants to use an address for a short time. Does it
> every have to Request the address? Perhaps the lifetime it gets from the
> server in the Advertise is sufficient for its purposes.

Yes the client has to do this because in our model the server owns the
addresses, times, and everything about the address.  The client must
request the address after the advertise.  Its the right way to tell the
server I am now keeping this and by the way Mr. server I got pass DAD too
(indirectly of course).

>
> Let's use Advertise for what it was intended - to allow a client to find a
> reasonable server. Let's use Request/Reply to do the address allocation.

Hmmm.  I have no comment on this as co-author for now.  I am merely
explaining a way this can be done.  What you ask is WG consensus
questioins. I was assuming we wanted to do what Mark suggested maybe I am
wrong.

Comments from others please..............

thanks
/jim

------_=_NextPart_001_01C116D1.C620AA50-- From owner-dhcp-v6@BUCKNELL.EDU Sat Jul 28 20:26:39 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA09271; Sat, 28 Jul 2001 20:26:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6S45J822454; Sat, 28 Jul 2001 00:05:19 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6S457811879 for ; Sat, 28 Jul 2001 00:05:07 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA03145; Sat, 28 Jul 2001 00:05:07 -0400 Date: Sat, 28 Jul 2001 00:05:07 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit In-Reply-To: <66F66129A77AD411B76200508B65AC697B3349@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@BUCKNELL.EDU Sender: owner-dhcp-v6@BUCKNELL.EDU X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie, > Sorry to appear to be shooting the messenger. Just trying to get this worked > out. OK. Just checking we are all pioneers with dhcpv6 and lots of those folks got shot...:----) > >Why is that weird. You just enter the code thread on your platform where > >you build DAD, Usolicited Mcastaddr, and do the DAD thing. That code all > >exists. If it doesn't then IPv6 won't work on the platform anyway. Then > >just set up the reply from the function you call into your DAD module. > >Why is that weird? thanks or are you making another point I am missing? > > The reason it is weird is that in other cases you're basically using DAD > once you have a "provisional" address. Yet, in this case, you don't yet > have this address "assigned" - it was just advertised. Yes that is true. But I view it as optimization for a request I thought had some consensus. But I have been wrong on that before. > Are you intending to allow the client to use the address once DAD is done? Just a nit. "I" the id of Jim intends nothing, but I a co-author am working with Ralph and our other co-authors to try to move this spec to consensus, so unless this feature has that I would assume it will get put on hold. I do suggest for discussion that the client should not use this address until a request reply has taken place except on the local link or within the nodes IPv6 site for that interface. There could be damage for the site but it would be minimal if incorrect and if we do this the gain from it for those wanting to do it would be worth the risk to permit it. I am assuming is the logic???? > Or, MUST the client wait until it receives a Reply from the server? While > under normal cases this would be relatively quick, there can be times when > it is not - such as if several hops are required to reach a server and you > have a short term link failure somewhere in that path. To use the address beyond the site this should be the case. > > And, what happens if the server went down and you're unable to Request the > addresses. If you've installed them at the client already, you'd be in > trouble with connections that might have used them. If that happens the client should delete the address and enter solicit phase again after all the uses of that address within the site or local-link have ended. > So, basically you have this interval between when DAD was complete and until > you receive the Reply that the address can not be used, but you must still > respond to DAD messages (since otherwise if two clients were Advertised > the same address - hopefully by different servers - then the client must > respond). Yes once the client has the address no one else can use it. But the client can use it as I said for link and site communications is my belief. > > This seems to imply that you require a new "state" for an address - post > DAD but before it's OK to use. I would not implement it this way or spec it this way. DAD has happened thats over. The client needs to recall the state of the address as the server has not completed the transaction yet though. But DAD was done and completed or failed. > If you wait until after the Request/Reply, you don't have this issue. You > can just do what you do for stateless ... install the address as "provisional" > and once DAD is done, you're good to go. The address can be used. If we do it this way yes it will work. But why bother with the optimization then? Whats was the reason? I don't see one? Thats why I suggest it may be useful for link/site prior to the request/reply phase. Either way I see no reason to implement a "state" DAD is done. Your not going to have to do DAD again after the Reply. But you can use it for greater-than site communications if it has such scope. > And, let me again point out that what you must do anyway should the server > assign more addresses or you get addresses from additional Requests. So, > once again if you do Advertised addresses differently, the client must > remember "oh, I've already run DAD on this so I don't need to do it again". Thats not the way it will work. We require the client verify all addresses are not duplicated on a link. Thats all we say. We don't say how you must do that. IPv6 stateless is the reference for that. That is DAD. After the client gets the prefix from the reply it does not have to process the same prefix with DAD. If its a new prefix then DAD will have to run. The client does have to keep track of which/when for the addresses now to support this optimization. > I am trying to keep the implementation simple. That's exactly why I suggest > we defer DAD until after Reply. > I see that. But if we do this what does the optimization buy the end user? I don't see it? thanks /jim > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Friday, July 27, 2001 2:58 PM > To: DHCPv6 discussion list > Subject: RE: Addresses and other parameters in Advertise and Solicit > > > Bernie, > > Not my idea I am the messenger here trying to get to PS. Mark was the > first one to suggest this as optimization on Ralph's very 1st design team > con call over a year ago. So I am just reiterating my understanding not > my wishes. > > More comments below. > > Don't shoot the messenger. Or the co-author trying to achieve consensus. > > > On Fri, 27 Jul 2001, Bernie Volz (EUD) wrote: > > > Jim: > > > > I do feel differently about this. > > > > >From what I recall, the *ORIGINAL* model was that Solicit would *ONLY* be > > used to find servers (based on Advertise) and no addresses or parameters > > would be provided, I don't see why we have this major shift. The *PROBLEM* > > that we had with not sending back anything about addresses in the Advertise > > was how does a client know when there are multiple servers which might be > > able to give it addresses (this was basically how to pick a "good" server > > rather than just simply the highest preference). > > That is addressed in the current draft by statements what the client can > do with multiple advertisements. Clearly a server will timeout their > advertize cache to see if client sends addresses and no request comes > back. I for one don't think we need to say this in an IETF spec either so > I disagree with a lot of the wordy input you want for clarification. An > implementor should see there is no NAK to the server code base and realize > a timeout is needed to end the state to maintain the information. We > could provide a suggestion for that time and should be configurable by the > sys admin. > > > So, I think you are changing the rules significantly and I for one don't think > > it is a good idea to do DAD on information (addresses) in the Advertise. > > > DAD is not an issue here at all. Its the communications btw the client > and the server that we are working on and IPv6 is fine behind that > (meaning DAD works. > > > There are also issues with this: > > - DAD isn't done consistently (as I pointed out below). It's done before > > Request in some cases but not in all. Seems kind of weird to me. > > I was suggesting (if we do this) that we make it consistent after an > advertise and when the client has selected the server. > > Why is that weird. You just enter the code thread on your platform where > you build DAD, Usolicited Mcastaddr, and do the DAD thing. That code all > exists. If it doesn't then IPv6 won't work on the platform anyway. Then > just set up the reply from the function you call into your DAD module. > Why is that weird? thanks or are you making another point I am missing? > > > - During the Solicit/Advertise, DAD, Request/Reply phase, does the client > > have to honor the lifetimes in the addresses? Thus, if a server sends back > > short lifetimes and the client doesn't complete the process (get a Reply), > > does it have to abort? Or, does it now send a Renew even before it has > > requested the addresses? Now, this hopefully won't happen because servers > > will return reasonable lifetimes, but ... > > WOW. DAD is like nanoseconds. Lets put it this way when IPv6 comes up on > our platforms it happens during boot phase so fast we could not dump it > during AD of IPv6 to see it. Had to hack around it. > > So if an admin says an address is on 5 minutes good then thats just stupid > and they should suffer from being incompetent. But seriously I don't > think this will happen in practice even as exception but if it did the > client should never do a renew without a request. That is asking for to > much state in the server for this optimization. > > > - What if a client only wants to use an address for a short time. Does it > > every have to Request the address? Perhaps the lifetime it gets from the > > server in the Advertise is sufficient for its purposes. > > Yes the client has to do this because in our model the server owns the > addresses, times, and everything about the address. The client must > request the address after the advertise. Its the right way to tell the > server I am now keeping this and by the way Mr. server I got pass DAD too > (indirectly of course). > > > > > Let's use Advertise for what it was intended - to allow a client to find a > > reasonable server. Let's use Request/Reply to do the address allocation. > > Hmmm. I have no comment on this as co-author for now. I am merely > explaining a way this can be done. What you ask is WG consensus > questioins. I was assuming we wanted to do what Mark suggested maybe I am > wrong. > > Comments from others please.............. > > thanks > /jim > From owner-dhcp-v6@bucknell.edu Sun Jul 29 20:54:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08189; Sun, 29 Jul 2001 20:54:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6U0sR322150; Sun, 29 Jul 2001 20:54:27 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6U0sF322125 for ; Sun, 29 Jul 2001 20:54:15 -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 f6U0sEp08321 for ; Sun, 29 Jul 2001 19:54:14 -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 f6U0sEg29277 for ; Sun, 29 Jul 2001 19:54:14 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Sun Jul 29 19:54:13 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 29 Jul 2001 19:54:13 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3352@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit Date: Sun, 29 Jul 2001 19:54:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11892.25717950" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C11892.25717950 Content-Type: text/plain; charset="iso-8859-1" Jim: Hopefully some others will comment ... Again, I feel that the Solicit/Advertise sequence ONLY be used to locate a server. Not to assign addresses or start the "DAD" phase, etc. The idea behind sending some information in the Advertise was to let the client chose a server that will give it what it wants. Otherwise, a higher preference server that doesn't allocate addresses would be used instead of the a lower preference server that would. I don't recall the discussion I believe you are referring to - early design team meeting, suggested by Mark? I believe you are saying that Mark (or someone else) suggested that DAD could be done on the Advertised addresses. I feel that is a bad idea for the reasons already discussed. - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Saturday, July 28, 2001 12:05 AM To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit Bernie, > Sorry to appear to be shooting the messenger. Just trying to get this worked > out. OK. Just checking we are all pioneers with dhcpv6 and lots of those folks got shot...:----) > >Why is that weird. You just enter the code thread on your platform where > >you build DAD, Usolicited Mcastaddr, and do the DAD thing. That code all > >exists. If it doesn't then IPv6 won't work on the platform anyway. Then > >just set up the reply from the function you call into your DAD module. > >Why is that weird? thanks or are you making another point I am missing? > > The reason it is weird is that in other cases you're basically using DAD > once you have a "provisional" address. Yet, in this case, you don't yet > have this address "assigned" - it was just advertised. Yes that is true. But I view it as optimization for a request I thought had some consensus. But I have been wrong on that before. > Are you intending to allow the client to use the address once DAD is done? Just a nit. "I" the id of Jim intends nothing, but I a co-author am working with Ralph and our other co-authors to try to move this spec to consensus, so unless this feature has that I would assume it will get put on hold. I do suggest for discussion that the client should not use this address until a request reply has taken place except on the local link or within the nodes IPv6 site for that interface. There could be damage for the site but it would be minimal if incorrect and if we do this the gain from it for those wanting to do it would be worth the risk to permit it. I am assuming is the logic???? > Or, MUST the client wait until it receives a Reply from the server? While > under normal cases this would be relatively quick, there can be times when > it is not - such as if several hops are required to reach a server and you > have a short term link failure somewhere in that path. To use the address beyond the site this should be the case. > > And, what happens if the server went down and you're unable to Request the > addresses. If you've installed them at the client already, you'd be in > trouble with connections that might have used them. If that happens the client should delete the address and enter solicit phase again after all the uses of that address within the site or local-link have ended. > So, basically you have this interval between when DAD was complete and until > you receive the Reply that the address can not be used, but you must still > respond to DAD messages (since otherwise if two clients were Advertised > the same address - hopefully by different servers - then the client must > respond). Yes once the client has the address no one else can use it. But the client can use it as I said for link and site communications is my belief. > > This seems to imply that you require a new "state" for an address - post > DAD but before it's OK to use. I would not implement it this way or spec it this way. DAD has happened thats over. The client needs to recall the state of the address as the server has not completed the transaction yet though. But DAD was done and completed or failed. > If you wait until after the Request/Reply, you don't have this issue. You > can just do what you do for stateless ... install the address as "provisional" > and once DAD is done, you're good to go. The address can be used. If we do it this way yes it will work. But why bother with the optimization then? Whats was the reason? I don't see one? Thats why I suggest it may be useful for link/site prior to the request/reply phase. Either way I see no reason to implement a "state" DAD is done. Your not going to have to do DAD again after the Reply. But you can use it for greater-than site communications if it has such scope. > And, let me again point out that what you must do anyway should the server > assign more addresses or you get addresses from additional Requests. So, > once again if you do Advertised addresses differently, the client must > remember "oh, I've already run DAD on this so I don't need to do it again". Thats not the way it will work. We require the client verify all addresses are not duplicated on a link. Thats all we say. We don't say how you must do that. IPv6 stateless is the reference for that. That is DAD. After the client gets the prefix from the reply it does not have to process the same prefix with DAD. If its a new prefix then DAD will have to run. The client does have to keep track of which/when for the addresses now to support this optimization. > I am trying to keep the implementation simple. That's exactly why I suggest > we defer DAD until after Reply. > I see that. But if we do this what does the optimization buy the end user? I don't see it? thanks /jim > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Friday, July 27, 2001 2:58 PM > To: DHCPv6 discussion list > Subject: RE: Addresses and other parameters in Advertise and Solicit > > > Bernie, > > Not my idea I am the messenger here trying to get to PS. Mark was the > first one to suggest this as optimization on Ralph's very 1st design team > con call over a year ago. So I am just reiterating my understanding not > my wishes. > > More comments below. > > Don't shoot the messenger. Or the co-author trying to achieve consensus. > > > On Fri, 27 Jul 2001, Bernie Volz (EUD) wrote: > > > Jim: > > > > I do feel differently about this. > > > > >From what I recall, the *ORIGINAL* model was that Solicit would *ONLY* be > > used to find servers (based on Advertise) and no addresses or parameters > > would be provided, I don't see why we have this major shift. The *PROBLEM* > > that we had with not sending back anything about addresses in the Advertise > > was how does a client know when there are multiple servers which might be > > able to give it addresses (this was basically how to pick a "good" server > > rather than just simply the highest preference). > > That is addressed in the current draft by statements what the client can > do with multiple advertisements. Clearly a server will timeout their > advertize cache to see if client sends addresses and no request comes > back. I for one don't think we need to say this in an IETF spec either so > I disagree with a lot of the wordy input you want for clarification. An > implementor should see there is no NAK to the server code base and realize > a timeout is needed to end the state to maintain the information. We > could provide a suggestion for that time and should be configurable by the > sys admin. > > > So, I think you are changing the rules significantly and I for one don't think > > it is a good idea to do DAD on information (addresses) in the Advertise. > > > DAD is not an issue here at all. Its the communications btw the client > and the server that we are working on and IPv6 is fine behind that > (meaning DAD works. > > > There are also issues with this: > > - DAD isn't done consistently (as I pointed out below). It's done before > > Request in some cases but not in all. Seems kind of weird to me. > > I was suggesting (if we do this) that we make it consistent after an > advertise and when the client has selected the server. > > Why is that weird. You just enter the code thread on your platform where > you build DAD, Usolicited Mcastaddr, and do the DAD thing. That code all > exists. If it doesn't then IPv6 won't work on the platform anyway. Then > just set up the reply from the function you call into your DAD module. > Why is that weird? thanks or are you making another point I am missing? > > > - During the Solicit/Advertise, DAD, Request/Reply phase, does the client > > have to honor the lifetimes in the addresses? Thus, if a server sends back > > short lifetimes and the client doesn't complete the process (get a Reply), > > does it have to abort? Or, does it now send a Renew even before it has > > requested the addresses? Now, this hopefully won't happen because servers > > will return reasonable lifetimes, but ... > > WOW. DAD is like nanoseconds. Lets put it this way when IPv6 comes up on > our platforms it happens during boot phase so fast we could not dump it > during AD of IPv6 to see it. Had to hack around it. > > So if an admin says an address is on 5 minutes good then thats just stupid > and they should suffer from being incompetent. But seriously I don't > think this will happen in practice even as exception but if it did the > client should never do a renew without a request. That is asking for to > much state in the server for this optimization. > > > - What if a client only wants to use an address for a short time. Does it > > every have to Request the address? Perhaps the lifetime it gets from the > > server in the Advertise is sufficient for its purposes. > > Yes the client has to do this because in our model the server owns the > addresses, times, and everything about the address. The client must > request the address after the advertise. Its the right way to tell the > server I am now keeping this and by the way Mr. server I got pass DAD too > (indirectly of course). > > > > > Let's use Advertise for what it was intended - to allow a client to find a > > reasonable server. Let's use Request/Reply to do the address allocation. > > Hmmm. I have no comment on this as co-author for now. I am merely > explaining a way this can be done. What you ask is WG consensus > questioins. I was assuming we wanted to do what Mark suggested maybe I am > wrong. > > Comments from others please.............. > > thanks > /jim > ------_=_NextPart_001_01C11892.25717950 Content-Type: text/html; charset="iso-8859-1" RE: Addresses and other parameters in Advertise and Solicit

Jim:

Hopefully some others will comment ...

Again, I feel that the Solicit/Advertise sequence ONLY be used to locate a server.
Not to assign addresses or start the "DAD" phase, etc. The idea behind sending some
information in the Advertise was to let the client chose a server that will give it
what it wants. Otherwise, a higher preference server that doesn't allocate addresses
would be used instead of the a lower preference server that would.

I don't recall the discussion I believe you are referring to - early design team
meeting, suggested by Mark? I believe you are saying that Mark (or someone else)
suggested that DAD could be done on the Advertised addresses. I feel that is a bad
idea for the reasons already discussed.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Saturday, July 28, 2001 12:05 AM
To: DHCPv6 discussion list
Subject: RE: Addresses and other parameters in Advertise and Solicit


Bernie,

> Sorry to appear to be shooting the messenger. Just trying to get this worked
> out.

OK.  Just checking we are all pioneers with dhcpv6 and lots of those folks
got shot...:----)

> >Why is that weird.  You just enter the code thread on your platform where
> >you build DAD, Usolicited Mcastaddr, and do the DAD thing.  That code all
> >exists.  If it doesn't then IPv6 won't work on the platform anyway.  Then
> >just set up the reply from the function you call into your DAD module.
> >Why is that weird?  thanks  or are you making another point I am missing?
>
> The reason it is weird is that in other cases you're basically using DAD
> once you have a "provisional" address. Yet, in this case, you don't yet
> have this address "assigned" - it was just advertised.

Yes that is true.  But I view it as optimization for a request I thought
had some consensus.  But I have been wrong on that before.
 
> Are you intending to allow the client to use the address once DAD is done?

Just a nit. "I" the id of Jim intends nothing, but I a co-author am
working with Ralph and our other co-authors to try to move this spec to
consensus, so unless this feature has that I would assume it will get put
on hold.

I do suggest for discussion that the client should not use this address
until a request reply has taken place except on the local link or within
the nodes IPv6 site for that interface.

There could be damage for the site but it would be minimal if incorrect
and if we do this the gain from it for those wanting to do it would be
worth the risk to permit it.  I am assuming is the logic????

> Or, MUST the client wait until it receives a Reply from the server? While
> under normal cases this would be relatively quick, there can be times when
> it is not - such as if several hops are required to reach a server and you
> have a short term link failure somewhere in that path.

To use the address beyond the site this should be the case.

>
> And, what happens if the server went down and you're unable to Request the
> addresses. If you've installed them at the client already, you'd be in
> trouble with connections that might have used them.

If that happens the client should delete the address and enter solicit
phase again after all the uses of that address within the site or
local-link have ended.
 
> So, basically you have this interval between when DAD was complete and until
> you receive the Reply that the address can not be used, but you must still
> respond to DAD messages (since otherwise if two clients were Advertised
> the same address - hopefully by different servers - then the client must
> respond).

Yes once the client has the address no one else can use it.  But the
client can use it as I said for link and site communications is my belief.

>
> This seems to imply that you require a new "state" for an address - post
> DAD but before it's OK to use.

I would not implement it this way or spec it this way.  DAD has happened
thats over.  The client needs to recall the state of the address as the
server has not completed the transaction yet though.  But DAD was done and
completed or failed.
 
> If you wait until after the Request/Reply, you don't have this issue. You
> can just do what you do for stateless ... install the address as "provisional"
> and once DAD is done, you're good to go. The address can be used.

If we do it this way yes it will work.  But why bother with the
optimization then?  Whats was the reason?  I don't see one?
Thats why I suggest it may be useful for link/site prior to the
request/reply phase. 

Either way I see no reason to implement a "state" DAD is done.  Your not
going to have to do DAD again after the Reply.  But you can use it for
greater-than site communications if it has such scope.
 
> And, let me again point out that what you must do anyway should the server
> assign more addresses or you get addresses from additional Requests. So,
> once again if you do Advertised addresses differently, the client must
> remember "oh, I've already run DAD on this so I don't need to do it again".

Thats not the way it will work.  We require the client verify all
addresses are not duplicated on a link.  Thats all we say. We don't say
how you must do that.  IPv6 stateless is the reference for that.  That is
DAD.  After the client gets the prefix from the reply it does not have to
process the same prefix with DAD.  If its a new prefix then DAD will have
to run.  The client does have to keep track of which/when for the
addresses now to support this optimization.
 
> I am trying to keep the implementation simple. That's exactly why I suggest
> we defer DAD until after Reply.
>

I see that.  But if we do this what does the optimization buy the end
user?  I don't see it?

thanks
/jim
 
>
> -----Original Message-----
> From: Jim Bound [mailto:seamus@bit-net.com]
> Sent: Friday, July 27, 2001 2:58 PM
> To: DHCPv6 discussion list
> Subject: RE: Addresses and other parameters in Advertise and Solicit
>
>
> Bernie,
>
> Not my idea I am the messenger here trying to get to PS.  Mark was the
> first one to suggest this as optimization on Ralph's very 1st design team
> con call over a year ago.  So I am just reiterating my understanding not
> my wishes.
>
> More comments below.
>
> Don't shoot the messenger.  Or the co-author trying to achieve consensus.
>
>
> On Fri, 27 Jul 2001, Bernie Volz (EUD) wrote:
>
> > Jim:
> >
> > I do feel differently about this.
> >
> > >From what I recall, the *ORIGINAL* model was that Solicit would *ONLY* be
> > used to find servers (based on Advertise) and no addresses or parameters
> > would be provided, I don't see why we have this major shift. The *PROBLEM*
> > that we had with not sending back anything about addresses in the Advertise
> > was how does a client know when there are multiple servers which might be
> > able to give it addresses (this was basically how to pick a "good" server
> > rather than just simply the highest preference).
>
> That is addressed in the current draft by statements what the client can
> do with multiple advertisements.  Clearly a server will timeout their
> advertize cache to see if client sends addresses and no request comes
> back.  I for one don't think we need to say this in an IETF spec either so
> I disagree with a lot of the wordy input you want for clarification.  An
> implementor should see there is no NAK to the server code base and realize
> a timeout is needed to end the state to maintain the information.  We
> could provide a suggestion for that time and should be configurable by the
> sys admin.
> 
> > So, I think you are changing the rules significantly and I for one don't think
> > it is a good idea to do DAD on information (addresses) in the Advertise.
> >
>  DAD is not an issue here at all.  Its the communications btw the client
> and the server that we are working on and IPv6 is fine behind that
> (meaning DAD works.
>
> > There are also issues with this:
> > - DAD isn't done consistently (as I pointed out below). It's done before
> > Request in some cases but not in all. Seems kind of weird to me.
>
> I was suggesting (if we do this) that we make it consistent after an
> advertise and when the client has selected the server.
>
> Why is that weird.  You just enter the code thread on your platform where
> you build DAD, Usolicited Mcastaddr, and do the DAD thing.  That code all
> exists.  If it doesn't then IPv6 won't work on the platform anyway.  Then
> just set up the reply from the function you call into your DAD module.
> Why is that weird?  thanks  or are you making another point I am missing?
>
> > - During the Solicit/Advertise, DAD, Request/Reply phase, does the client
> > have to honor the lifetimes in the addresses? Thus, if a server sends back
> > short lifetimes and the client doesn't complete the process (get a Reply),
> > does it have to abort? Or, does it now send a Renew even before it has
> > requested the addresses? Now, this hopefully won't happen because servers
> > will return reasonable lifetimes, but ...
>
> WOW. DAD is like nanoseconds.  Lets put it this way when IPv6 comes up on
> our platforms it happens during boot phase so fast we could not dump it
> during AD of IPv6 to see it.  Had to hack around it. 
>
> So if an admin says an address is on 5 minutes good then thats just stupid
> and they should suffer from being incompetent.  But seriously I don't
> think this will happen in practice even as exception but if it did the
> client should never do a renew without a request.  That is asking for to
> much state in the server for this optimization.
>
> > - What if a client only wants to use an address for a short time. Does it
> > every have to Request the address? Perhaps the lifetime it gets from the
> > server in the Advertise is sufficient for its purposes.
>
> Yes the client has to do this because in our model the server owns the
> addresses, times, and everything about the address.  The client must
> request the address after the advertise.  Its the right way to tell the
> server I am now keeping this and by the way Mr. server I got pass DAD too
> (indirectly of course).
>
> >
> > Let's use Advertise for what it was intended - to allow a client to find a
> > reasonable server. Let's use Request/Reply to do the address allocation.
>
> Hmmm.  I have no comment on this as co-author for now.  I am merely
> explaining a way this can be done.  What you ask is WG consensus
> questioins. I was assuming we wanted to do what Mark suggested maybe I am
> wrong.
>
> Comments from others please..............
>
> thanks
> /jim
>

------_=_NextPart_001_01C11892.25717950-- From owner-dhcp-v4@bucknell.edu Mon Jul 30 07:23:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA17147 for ; Mon, 30 Jul 2001 07:23:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6UBKn312928; Mon, 30 Jul 2001 07:20:49 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6UBKl316880 for ; Mon, 30 Jul 2001 07:20:47 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-3.cisco.com [10.21.96.3]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA05968; Mon, 30 Jul 2001 07:20:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20010729164202.035b5768@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Jul 2001 07:15:56 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Server initiated traffic Cc: DHCPv4 discussion list In-Reply-To: <20010727135925.22110.qmail@web20103.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 06:59 AM 7/27/2001 -0700, Jimmy Bush wrote: >Would there ever be a case when a DHCP server would >initiate traffic with a client? Perhaps if it has >lost power? Or has given out all its licenses and >wants to revoke one? Based on the spec in RFC2131, the server never initiates a message exchange with a client. If the server loses power, the DHCP server recovers its lease information from its permanent record. The server has no mechanism for revoking an existing lease. There is a new DHCP message, proposed in draft-ietf-dhc-pv4-reconfigure-06.txt (expected to become an RFC soon), that allows a server to send a message to a client that causes the client to recontact the server for updated configuration information. - Ralph Droms From owner-dhcp-v6@bucknell.edu Mon Jul 30 09:29:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA21325; Mon, 30 Jul 2001 09:29:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6UDTA303140; Mon, 30 Jul 2001 09:29:10 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6UDT5328901 for ; Mon, 30 Jul 2001 09:29:05 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA32709; Mon, 30 Jul 2001 09:29:04 -0400 Date: Mon, 30 Jul 2001 09:29:04 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit In-Reply-To: <66F66129A77AD411B76200508B65AC697B3352@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie, thanks for the input I knew that this was your view. But Mark said nothing about DAD. He said and also at the San Diego meeting it would be good if we could optimize the protocol to support this jaundra. So your recollection is not mine. thanks Would others comment on this please. thanks /jim On Sun, 29 Jul 2001, Bernie Volz (EUD) wrote: > Jim: > > Hopefully some others will comment ... > > Again, I feel that the Solicit/Advertise sequence ONLY be used to locate a server. > Not to assign addresses or start the "DAD" phase, etc. The idea behind sending some > information in the Advertise was to let the client chose a server that will give it > what it wants. Otherwise, a higher preference server that doesn't allocate addresses > would be used instead of the a lower preference server that would. > > I don't recall the discussion I believe you are referring to - early design team > meeting, suggested by Mark? I believe you are saying that Mark (or someone else) > suggested that DAD could be done on the Advertised addresses. I feel that is a bad > idea for the reasons already discussed. > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Saturday, July 28, 2001 12:05 AM > To: DHCPv6 discussion list > Subject: RE: Addresses and other parameters in Advertise and Solicit > > > Bernie, > > > Sorry to appear to be shooting the messenger. Just trying to get this worked > > out. > > OK. Just checking we are all pioneers with dhcpv6 and lots of those folks > got shot...:----) > > > >Why is that weird. You just enter the code thread on your platform where > > >you build DAD, Usolicited Mcastaddr, and do the DAD thing. That code all > > >exists. If it doesn't then IPv6 won't work on the platform anyway. Then > > >just set up the reply from the function you call into your DAD module. > > >Why is that weird? thanks or are you making another point I am missing? > > > > The reason it is weird is that in other cases you're basically using DAD > > once you have a "provisional" address. Yet, in this case, you don't yet > > have this address "assigned" - it was just advertised. > > Yes that is true. But I view it as optimization for a request I thought > had some consensus. But I have been wrong on that before. > > > Are you intending to allow the client to use the address once DAD is done? > > Just a nit. "I" the id of Jim intends nothing, but I a co-author am > working with Ralph and our other co-authors to try to move this spec to > consensus, so unless this feature has that I would assume it will get put > on hold. > > I do suggest for discussion that the client should not use this address > until a request reply has taken place except on the local link or within > the nodes IPv6 site for that interface. > > There could be damage for the site but it would be minimal if incorrect > and if we do this the gain from it for those wanting to do it would be > worth the risk to permit it. I am assuming is the logic???? > > > Or, MUST the client wait until it receives a Reply from the server? While > > under normal cases this would be relatively quick, there can be times when > > it is not - such as if several hops are required to reach a server and you > > have a short term link failure somewhere in that path. > > To use the address beyond the site this should be the case. > > > > > And, what happens if the server went down and you're unable to Request the > > addresses. If you've installed them at the client already, you'd be in > > trouble with connections that might have used them. > > If that happens the client should delete the address and enter solicit > phase again after all the uses of that address within the site or > local-link have ended. > > > So, basically you have this interval between when DAD was complete and until > > you receive the Reply that the address can not be used, but you must still > > respond to DAD messages (since otherwise if two clients were Advertised > > the same address - hopefully by different servers - then the client must > > respond). > > Yes once the client has the address no one else can use it. But the > client can use it as I said for link and site communications is my belief. > > > > > This seems to imply that you require a new "state" for an address - post > > DAD but before it's OK to use. > > I would not implement it this way or spec it this way. DAD has happened > thats over. The client needs to recall the state of the address as the > server has not completed the transaction yet though. But DAD was done and > completed or failed. > > > If you wait until after the Request/Reply, you don't have this issue. You > > can just do what you do for stateless ... install the address as "provisional" > > and once DAD is done, you're good to go. The address can be used. > > If we do it this way yes it will work. But why bother with the > optimization then? Whats was the reason? I don't see one? > Thats why I suggest it may be useful for link/site prior to the > request/reply phase. > > Either way I see no reason to implement a "state" DAD is done. Your not > going to have to do DAD again after the Reply. But you can use it for > greater-than site communications if it has such scope. > > > And, let me again point out that what you must do anyway should the server > > assign more addresses or you get addresses from additional Requests. So, > > once again if you do Advertised addresses differently, the client must > > remember "oh, I've already run DAD on this so I don't need to do it again". > > Thats not the way it will work. We require the client verify all > addresses are not duplicated on a link. Thats all we say. We don't say > how you must do that. IPv6 stateless is the reference for that. That is > DAD. After the client gets the prefix from the reply it does not have to > process the same prefix with DAD. If its a new prefix then DAD will have > to run. The client does have to keep track of which/when for the > addresses now to support this optimization. > > > I am trying to keep the implementation simple. That's exactly why I suggest > > we defer DAD until after Reply. > > > > I see that. But if we do this what does the optimization buy the end > user? I don't see it? > > thanks > /jim > > > > > -----Original Message----- > > From: Jim Bound [mailto:seamus@bit-net.com] > > Sent: Friday, July 27, 2001 2:58 PM > > To: DHCPv6 discussion list > > Subject: RE: Addresses and other parameters in Advertise and Solicit > > > > > > Bernie, > > > > Not my idea I am the messenger here trying to get to PS. Mark was the > > first one to suggest this as optimization on Ralph's very 1st design team > > con call over a year ago. So I am just reiterating my understanding not > > my wishes. > > > > More comments below. > > > > Don't shoot the messenger. Or the co-author trying to achieve consensus. > > > > > > On Fri, 27 Jul 2001, Bernie Volz (EUD) wrote: > > > > > Jim: > > > > > > I do feel differently about this. > > > > > > >From what I recall, the *ORIGINAL* model was that Solicit would *ONLY* be > > > used to find servers (based on Advertise) and no addresses or parameters > > > would be provided, I don't see why we have this major shift. The *PROBLEM* > > > that we had with not sending back anything about addresses in the Advertise > > > was how does a client know when there are multiple servers which might be > > > able to give it addresses (this was basically how to pick a "good" server > > > rather than just simply the highest preference). > > > > That is addressed in the current draft by statements what the client can > > do with multiple advertisements. Clearly a server will timeout their > > advertize cache to see if client sends addresses and no request comes > > back. I for one don't think we need to say this in an IETF spec either so > > I disagree with a lot of the wordy input you want for clarification. An > > implementor should see there is no NAK to the server code base and realize > > a timeout is needed to end the state to maintain the information. We > > could provide a suggestion for that time and should be configurable by the > > sys admin. > > > > > So, I think you are changing the rules significantly and I for one don't think > > > it is a good idea to do DAD on information (addresses) in the Advertise. > > > > > DAD is not an issue here at all. Its the communications btw the client > > and the server that we are working on and IPv6 is fine behind that > > (meaning DAD works. > > > > > There are also issues with this: > > > - DAD isn't done consistently (as I pointed out below). It's done before > > > Request in some cases but not in all. Seems kind of weird to me. > > > > I was suggesting (if we do this) that we make it consistent after an > > advertise and when the client has selected the server. > > > > Why is that weird. You just enter the code thread on your platform where > > you build DAD, Usolicited Mcastaddr, and do the DAD thing. That code all > > exists. If it doesn't then IPv6 won't work on the platform anyway. Then > > just set up the reply from the function you call into your DAD module. > > Why is that weird? thanks or are you making another point I am missing? > > > > > - During the Solicit/Advertise, DAD, Request/Reply phase, does the client > > > have to honor the lifetimes in the addresses? Thus, if a server sends back > > > short lifetimes and the client doesn't complete the process (get a Reply), > > > does it have to abort? Or, does it now send a Renew even before it has > > > requested the addresses? Now, this hopefully won't happen because servers > > > will return reasonable lifetimes, but ... > > > > WOW. DAD is like nanoseconds. Lets put it this way when IPv6 comes up on > > our platforms it happens during boot phase so fast we could not dump it > > during AD of IPv6 to see it. Had to hack around it. > > > > So if an admin says an address is on 5 minutes good then thats just stupid > > and they should suffer from being incompetent. But seriously I don't > > think this will happen in practice even as exception but if it did the > > client should never do a renew without a request. That is asking for to > > much state in the server for this optimization. > > > > > - What if a client only wants to use an address for a short time. Does it > > > every have to Request the address? Perhaps the lifetime it gets from the > > > server in the Advertise is sufficient for its purposes. > > > > Yes the client has to do this because in our model the server owns the > > addresses, times, and everything about the address. The client must > > request the address after the advertise. Its the right way to tell the > > server I am now keeping this and by the way Mr. server I got pass DAD too > > (indirectly of course). > > > > > > > > Let's use Advertise for what it was intended - to allow a client to find a > > > reasonable server. Let's use Request/Reply to do the address allocation. > > > > Hmmm. I have no comment on this as co-author for now. I am merely > > explaining a way this can be done. What you ask is WG consensus > > questioins. I was assuming we wanted to do what Mark suggested maybe I am > > wrong. > > > > Comments from others please.............. > > > > thanks > > /jim > > > From owner-dhcp-v6@bucknell.edu Mon Jul 30 17:42:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27421; Mon, 30 Jul 2001 17:42:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6ULgc324478; Mon, 30 Jul 2001 17:42:38 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6ULgS306161; Mon, 30 Jul 2001 17:42:28 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21232; Mon, 30 Jul 2001 17:42:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20010730173901.03bdc788@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Jul 2001 17:40:46 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Draft agenda for WG meeting in London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here's the draft agenda for the WG meeting in London. If I've overlooked a promised or requested slot, please let me know by noon EDT, 7/31. I'll have more details on the DHCPv6 discussion within a day or so. - Ralph DHC WG activities update: Ralph Droms, 10 minutes * Failover protocol spec * Classless static routes, long option encoding specs to WG last call * FQDN option, conflict resolution specs to WG last call * Reconfigure option reviewed by IESG and revised by authors * Domain search option ready for WG last call * Relay agent option subnet selection ready for WG last call Wireless Key Management using DHCP Bill Arbaugh, 10 minutes DHCP mDNS Enable Option Erik Guttman, 10 minutes LDAP Schema for DHCP Mark Meredith, Vijay Nanjundaswamy, Mark Hinckley, 15 minutes Dynamic Host Configuration Protocol Jim Bound for IPv6 (DHCPv6) Ralph Droms, 60 minutes From owner-dhcp-v4@bucknell.edu Mon Jul 30 17:46:09 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA27626 for ; Mon, 30 Jul 2001 17:46:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6ULgc329023; Mon, 30 Jul 2001 17:42:38 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6ULgS306161; Mon, 30 Jul 2001 17:42:28 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21232; Mon, 30 Jul 2001 17:42:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20010730173901.03bdc788@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 30 Jul 2001 17:40:46 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Draft agenda for WG meeting in London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here's the draft agenda for the WG meeting in London. If I've overlooked a promised or requested slot, please let me know by noon EDT, 7/31. I'll have more details on the DHCPv6 discussion within a day or so. - Ralph DHC WG activities update: Ralph Droms, 10 minutes * Failover protocol spec * Classless static routes, long option encoding specs to WG last call * FQDN option, conflict resolution specs to WG last call * Reconfigure option reviewed by IESG and revised by authors * Domain search option ready for WG last call * Relay agent option subnet selection ready for WG last call Wireless Key Management using DHCP Bill Arbaugh, 10 minutes DHCP mDNS Enable Option Erik Guttman, 10 minutes LDAP Schema for DHCP Mark Meredith, Vijay Nanjundaswamy, Mark Hinckley, 15 minutes Dynamic Host Configuration Protocol Jim Bound for IPv6 (DHCPv6) Ralph Droms, 60 minutes From owner-dhcp-v6@bucknell.edu Tue Jul 31 09:54:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15956; Tue, 31 Jul 2001 09:54:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VDsG316036; Tue, 31 Jul 2001 09:54:16 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6VDs3315737; Tue, 31 Jul 2001 09:54:03 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA15703; Tue, 31 Jul 2001 09:53:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20010731095149.03891a10@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Jul 2001 09:52:26 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Revised WG meeting agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've published a revised agenda at http://www.dhcp.org/0108-meeting.html - Ralph From owner-dhcp-v4@bucknell.edu Tue Jul 31 09:56:43 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16012 for ; Tue, 31 Jul 2001 09:56:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VDsG314858; Tue, 31 Jul 2001 09:54:16 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6VDs3315737; Tue, 31 Jul 2001 09:54:03 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA15703; Tue, 31 Jul 2001 09:53:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20010731095149.03891a10@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Jul 2001 09:52:26 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Revised WG meeting agenda Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've published a revised agenda at http://www.dhcp.org/0108-meeting.html - Ralph From owner-dhcp-v6@bucknell.edu Tue Jul 31 10:51:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19172; Tue, 31 Jul 2001 10:51:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VEpR324618; Tue, 31 Jul 2001 10:51:27 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6VEpI327117 for ; Tue, 31 Jul 2001 10:51:18 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2inic2j.dialup.mindspring.com [165.121.48.83]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f6VEkXf13585 for ; Tue, 31 Jul 2001 07:46:34 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f6UJjq900427 for ; Mon, 30 Jul 2001 12:45:52 -0700 (MST) Message-Id: <200107301945.f6UJjq900427@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Addresses and other parameters in Advertise and Solicit In-Reply-To: Message from Jim Bound of "Mon, 30 Jul 2001 09:29:04 -0400." Date: Mon, 30 Jul 2001 12:45:52 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > thanks for the input I knew that this was your view. But Mark said > nothing about DAD. He said and also at the San Diego meeting it would be > good if we could optimize the protocol to support this jaundra. So your > recollection is not mine. thanks Blech. If Solicit/Advertise doesn't say what the merchandise is, it's easy to imagine a server that's broken in a way that would prevent a client from ever getting an address. We have been over this ground before. Jim is right. Please let's leave it that advertise says "I'll try to give you these addresses if you choose me." I.e., pretty much like DHCPOFFER in DHCPv4. _MelloN_ From owner-dhcp-v6@bucknell.edu Tue Jul 31 11:08:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA20304; Tue, 31 Jul 2001 11:08:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VF7x331379; Tue, 31 Jul 2001 11:07:59 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6VF7u327126 for ; Tue, 31 Jul 2001 11:07: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 f6VF7tp05098 for ; Tue, 31 Jul 2001 10:07:55 -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 f6VF7te24467 for ; Tue, 31 Jul 2001 10:07:55 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jul 31 10:07:54 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 10:07:55 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3372@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit Date: Tue, 31 Jul 2001 10:07:54 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C119D2.933DC510" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C119D2.933DC510 Content-Type: text/plain; charset="iso-8859-1" Ted: I don't understand your argument. A broken server is just that, broken. What it will and will not allow a client to do is not an issue - fix the server. In fact, I believe having the actual assignment of addresses deferred until the Reply is received is far more likely to result in non-broken servers. A server, in the Advertise, just needs to tell the client that it is willing to assign address. The questions are: - Is Advertise a contract to give the client those addresses? - And, if it is a contract then MAY, SHOULD, or MUST the client perform DAD before doing the Request. And, when can a client start using an address? After Advertise? After Reply? Please also note that there are some other properties of DHCPv4's offer behavoir that are not currently specified in DHCPv6. Such as: - In DHCPv4, other servers listen to the broadcast of the DHCPREQUEST to learn that their offer has been DECLINED (see Section 3.1). If we do what you and Jim propose, do we need this? - In DHCPv4, the address is not checked until *AFTER* the DHCPREQUEST/DHCPACK sequence and a DHCPDECLINE is not valid until after the REQUEST/ACK sequence. - In DHCPv4, the offered address is included in the DHCPREQUEST to the server. If we're going to follow that convention, we need the client to send the IA option it received from the server in the REQUEST? - In DHCPv4, the server always has the ability to DHCPNACK the address received in the DHCPREQUEST. We've had a dicussion about NACKs before. But we would need to have a mechanism for the server to tell the client, gee sorry, that address isn't available now. Perhaps the mechanism is simply for the server not to include that address in the IA in the Reply. But again, this behavoir would not be needed if the addresses in the Advertise are just informational (I will assign you addresses similar to these). - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Monday, July 30, 2001 3:46 PM To: DHCPv6 discussion list Subject: Re: Addresses and other parameters in Advertise and Solicit > thanks for the input I knew that this was your view. But Mark said > nothing about DAD. He said and also at the San Diego meeting it would be > good if we could optimize the protocol to support this jaundra. So your > recollection is not mine. thanks Blech. If Solicit/Advertise doesn't say what the merchandise is, it's easy to imagine a server that's broken in a way that would prevent a client from ever getting an address. We have been over this ground before. Jim is right. Please let's leave it that advertise says "I'll try to give you these addresses if you choose me." I.e., pretty much like DHCPOFFER in DHCPv4. _MelloN_ ------_=_NextPart_001_01C119D2.933DC510 Content-Type: text/html; charset="iso-8859-1" RE: Addresses and other parameters in Advertise and Solicit

Ted:

I don't understand your argument. A broken server is just that, broken. What it will
and will not allow a client to do is not an issue - fix the server.

In fact, I believe having the actual assignment of addresses deferred until the Reply
is received is far more likely to result in non-broken servers. A server, in the
Advertise, just needs to tell the client that it is willing to assign address.

The questions are:
- Is Advertise a contract to give the client those addresses?
- And, if it is a contract then MAY, SHOULD, or MUST the client perform DAD before
doing the Request. And, when can a client start using an address? After Advertise?
After Reply?

Please also note that there are some other properties of DHCPv4's offer behavoir that
are not currently specified in DHCPv6. Such as:
- In DHCPv4, other servers listen to the broadcast of the DHCPREQUEST to learn that
their offer has been DECLINED (see Section 3.1). If we do what you and Jim propose,
do we need this?
- In DHCPv4, the address is not checked until *AFTER* the DHCPREQUEST/DHCPACK sequence
and a DHCPDECLINE is not valid until after the REQUEST/ACK sequence.
- In DHCPv4, the offered address is included in the DHCPREQUEST to the server. If
we're going to follow that convention, we need the client to send the IA option it
received from the server in the REQUEST?
- In DHCPv4, the server always has the ability to DHCPNACK the address received
in the DHCPREQUEST. We've had a dicussion about NACKs before. But we would need
to have a mechanism for the server to tell the client, gee sorry, that address isn't
available now. Perhaps the mechanism is simply for the server not to include that
address in the IA in the Reply. But again, this behavoir would not be needed if the
addresses in the Advertise are just informational (I will assign you addresses similar
to these).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Monday, July 30, 2001 3:46 PM
To: DHCPv6 discussion list
Subject: Re: Addresses and other parameters in Advertise and Solicit



> thanks for the input I knew that this was your view.  But Mark said
> nothing about DAD.  He said and also at the San Diego meeting it would be
> good if we could optimize the protocol to support this jaundra.  So your
> recollection is not mine.  thanks

Blech.   If Solicit/Advertise doesn't say what the merchandise is,
it's easy to imagine a server that's broken in a way that would
prevent a client from ever getting an address.   We have been over
this ground before.   Jim is right.   Please let's leave it that
advertise says "I'll try to give you these addresses if you choose
me."   I.e., pretty much like DHCPOFFER in DHCPv4.

                               _MelloN_

------_=_NextPart_001_01C119D2.933DC510-- From owner-dhcp-v6@bucknell.edu Tue Jul 31 11:22:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA21096; Tue, 31 Jul 2001 11:22:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VFMt307042; Tue, 31 Jul 2001 11:22:55 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VFMq306441 for ; Tue, 31 Jul 2001 11:22:52 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA15109; Tue, 31 Jul 2001 11:22:52 -0400 Date: Tue, 31 Jul 2001 11:22:51 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit In-Reply-To: <66F66129A77AD411B76200508B65AC697B3372@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie, DAD has nothing to do with this at all. Its transparent. I will leave it to my colleagues on the list to respond to other comments. thanks /jim On Tue, 31 Jul 2001, Bernie Volz (EUD) wrote: > Ted: > > I don't understand your argument. A broken server is just that, broken. What it will > and will not allow a client to do is not an issue - fix the server. > > In fact, I believe having the actual assignment of addresses deferred until the Reply > is received is far more likely to result in non-broken servers. A server, in the > Advertise, just needs to tell the client that it is willing to assign address. > > The questions are: > - Is Advertise a contract to give the client those addresses? > - And, if it is a contract then MAY, SHOULD, or MUST the client perform DAD before > doing the Request. And, when can a client start using an address? After Advertise? > After Reply? > > Please also note that there are some other properties of DHCPv4's offer behavoir that > are not currently specified in DHCPv6. Such as: > - In DHCPv4, other servers listen to the broadcast of the DHCPREQUEST to learn that > their offer has been DECLINED (see Section 3.1). If we do what you and Jim propose, > do we need this? > - In DHCPv4, the address is not checked until *AFTER* the DHCPREQUEST/DHCPACK sequence > and a DHCPDECLINE is not valid until after the REQUEST/ACK sequence. > - In DHCPv4, the offered address is included in the DHCPREQUEST to the server. If > we're going to follow that convention, we need the client to send the IA option it > received from the server in the REQUEST? > - In DHCPv4, the server always has the ability to DHCPNACK the address received > in the DHCPREQUEST. We've had a dicussion about NACKs before. But we would need > to have a mechanism for the server to tell the client, gee sorry, that address isn't > available now. Perhaps the mechanism is simply for the server not to include that > address in the IA in the Reply. But again, this behavoir would not be needed if the > addresses in the Advertise are just informational (I will assign you addresses similar > to these). > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Monday, July 30, 2001 3:46 PM > To: DHCPv6 discussion list > Subject: Re: Addresses and other parameters in Advertise and Solicit > > > > > thanks for the input I knew that this was your view. But Mark said > > nothing about DAD. He said and also at the San Diego meeting it would be > > good if we could optimize the protocol to support this jaundra. So your > > recollection is not mine. thanks > > Blech. If Solicit/Advertise doesn't say what the merchandise is, > it's easy to imagine a server that's broken in a way that would > prevent a client from ever getting an address. We have been over > this ground before. Jim is right. Please let's leave it that > advertise says "I'll try to give you these addresses if you choose > me." I.e., pretty much like DHCPOFFER in DHCPv4. > > _MelloN_ > From owner-dhcp-v6@bucknell.edu Tue Jul 31 11:45:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22378; Tue, 31 Jul 2001 11:45:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VFiw315418; Tue, 31 Jul 2001 11:44:58 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6VFiq311547 for ; Tue, 31 Jul 2001 11:44: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 f6VFiqp25175 for ; Tue, 31 Jul 2001 10:44:52 -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 f6VFiqY08186 for ; Tue, 31 Jul 2001 10:44:52 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Jul 31 10:44:48 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 31 Jul 2001 10:44:49 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3373@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit Date: Tue, 31 Jul 2001 10:44:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C119D7.BADC3020" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN 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_01C119D7.BADC3020 Content-Type: text/plain; charset="iso-8859-1" Jim: Agreed, DAD itself has little to do with this. However, when DAD is done does - because that determines when the client begins to claim some ownership of that address (whether it uses it is another issue) and it impacts when a Decline might be done. If the conclusion is that Advertise is just an advertisement of service (which is what I'm arguing for and which was the original purpose of Advertise) and not a "contract" of the actual addresses (which is the opposing view), DAD can't be done until later (after Reply received) and so is not an issue. However, as you specified it earlier, DAD was done on the Advertised addresses and that has implications on what Advertise means. - Bernie -----Original Message----- From: Jim Bound [mailto:seamus@bit-net.com] Sent: Tuesday, July 31, 2001 11:23 AM To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit Bernie, DAD has nothing to do with this at all. Its transparent. I will leave it to my colleagues on the list to respond to other comments. thanks /jim On Tue, 31 Jul 2001, Bernie Volz (EUD) wrote: > Ted: > > I don't understand your argument. A broken server is just that, broken. What it will > and will not allow a client to do is not an issue - fix the server. > > In fact, I believe having the actual assignment of addresses deferred until the Reply > is received is far more likely to result in non-broken servers. A server, in the > Advertise, just needs to tell the client that it is willing to assign address. > > The questions are: > - Is Advertise a contract to give the client those addresses? > - And, if it is a contract then MAY, SHOULD, or MUST the client perform DAD before > doing the Request. And, when can a client start using an address? After Advertise? > After Reply? > > Please also note that there are some other properties of DHCPv4's offer behavoir that > are not currently specified in DHCPv6. Such as: > - In DHCPv4, other servers listen to the broadcast of the DHCPREQUEST to learn that > their offer has been DECLINED (see Section 3.1). If we do what you and Jim propose, > do we need this? > - In DHCPv4, the address is not checked until *AFTER* the DHCPREQUEST/DHCPACK sequence > and a DHCPDECLINE is not valid until after the REQUEST/ACK sequence. > - In DHCPv4, the offered address is included in the DHCPREQUEST to the server. If > we're going to follow that convention, we need the client to send the IA option it > received from the server in the REQUEST? > - In DHCPv4, the server always has the ability to DHCPNACK the address received > in the DHCPREQUEST. We've had a dicussion about NACKs before. But we would need > to have a mechanism for the server to tell the client, gee sorry, that address isn't > available now. Perhaps the mechanism is simply for the server not to include that > address in the IA in the Reply. But again, this behavoir would not be needed if the > addresses in the Advertise are just informational (I will assign you addresses similar > to these). > > - Bernie > > -----Original Message----- > From: Ted Lemon [mailto:mellon@nominum.com] > Sent: Monday, July 30, 2001 3:46 PM > To: DHCPv6 discussion list > Subject: Re: Addresses and other parameters in Advertise and Solicit > > > > > thanks for the input I knew that this was your view. But Mark said > > nothing about DAD. He said and also at the San Diego meeting it would be > > good if we could optimize the protocol to support this jaundra. So your > > recollection is not mine. thanks > > Blech. If Solicit/Advertise doesn't say what the merchandise is, > it's easy to imagine a server that's broken in a way that would > prevent a client from ever getting an address. We have been over > this ground before. Jim is right. Please let's leave it that > advertise says "I'll try to give you these addresses if you choose > me." I.e., pretty much like DHCPOFFER in DHCPv4. > > _MelloN_ > ------_=_NextPart_001_01C119D7.BADC3020 Content-Type: text/html; charset="iso-8859-1" RE: Addresses and other parameters in Advertise and Solicit

Jim:

Agreed, DAD itself has little to do with this.

However, when DAD is done does - because that determines when the client begins
to claim some ownership of that address (whether it uses it is another issue)
and it impacts when a Decline might be done.

If the conclusion is that Advertise is just an advertisement of service (which
is what I'm arguing for and which was the original purpose of Advertise) and not
a "contract" of the actual addresses (which is the opposing view), DAD can't be
done until later (after Reply received) and so is not an issue. However, as you
specified it earlier, DAD was done on the Advertised addresses and that has
implications on what Advertise means.

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Tuesday, July 31, 2001 11:23 AM
To: DHCPv6 discussion list
Subject: RE: Addresses and other parameters in Advertise and Solicit


Bernie,

DAD has nothing to do with this at all.  Its transparent.  I will leave it
to my colleagues on the list to respond to other comments.

thanks


/jim


On Tue, 31 Jul 2001, Bernie Volz (EUD) wrote:

> Ted:
>
> I don't understand your argument. A broken server is just that, broken. What it will
> and will not allow a client to do is not an issue - fix the server.
>
> In fact, I believe having the actual assignment of addresses deferred until the Reply
> is received is far more likely to result in non-broken servers. A server, in the
> Advertise, just needs to tell the client that it is willing to assign address.
>
> The questions are:
> - Is Advertise a contract to give the client those addresses?
> - And, if it is a contract then MAY, SHOULD, or MUST the client perform DAD before
> doing the Request. And, when can a client start using an address? After Advertise?
> After Reply?
>
> Please also note that there are some other properties of DHCPv4's offer behavoir that
> are not currently specified in DHCPv6. Such as:
> - In DHCPv4, other servers listen to the broadcast of the DHCPREQUEST to learn that
> their offer has been DECLINED (see Section 3.1). If we do what you and Jim propose,
> do we need this?
> - In DHCPv4, the address is not checked until *AFTER* the DHCPREQUEST/DHCPACK sequence
> and a DHCPDECLINE is not valid until after the REQUEST/ACK sequence.
> - In DHCPv4, the offered address is included in the DHCPREQUEST to the server. If
> we're going to follow that convention, we need the client to send the IA option it
> received from the server in the REQUEST?
> - In DHCPv4, the server always has the ability to DHCPNACK the address received
> in the DHCPREQUEST. We've had a dicussion about NACKs before. But we would need
> to have a mechanism for the server to tell the client, gee sorry, that address isn't
> available now. Perhaps the mechanism is simply for the server not to include that
> address in the IA in the Reply. But again, this behavoir would not be needed if the
> addresses in the Advertise are just informational (I will assign you addresses similar
> to these).
>
> - Bernie
>
> -----Original Message-----
> From: Ted Lemon [mailto:mellon@nominum.com]
> Sent: Monday, July 30, 2001 3:46 PM
> To: DHCPv6 discussion list
> Subject: Re: Addresses and other parameters in Advertise and Solicit
>
>
>
> > thanks for the input I knew that this was your view.  But Mark said
> > nothing about DAD.  He said and also at the San Diego meeting it would be
> > good if we could optimize the protocol to support this jaundra.  So your
> > recollection is not mine.  thanks
>
> Blech.   If Solicit/Advertise doesn't say what the merchandise is,
> it's easy to imagine a server that's broken in a way that would
> prevent a client from ever getting an address.   We have been over
> this ground before.   Jim is right.   Please let's leave it that
> advertise says "I'll try to give you these addresses if you choose
> me."   I.e., pretty much like DHCPOFFER in DHCPv4.
>
>                              _MelloN_
>

------_=_NextPart_001_01C119D7.BADC3020-- From owner-dhcp-v6@bucknell.edu Tue Jul 31 15:34:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14125; Tue, 31 Jul 2001 15:34:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VJYj304120; Tue, 31 Jul 2001 15:34:45 -0400 (EDT) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VJYU302388 for ; Tue, 31 Jul 2001 15:34:31 -0400 (EDT) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA24524; Tue, 31 Jul 2001 15:34:30 -0400 Date: Tue, 31 Jul 2001 15:34:30 -0400 (EDT) From: Jim Bound To: DHCPv6 discussion list Subject: RE: Addresses and other parameters in Advertise and Solicit In-Reply-To: <66F66129A77AD411B76200508B65AC697B3373@eambunt705.ena-east.ericsson.se> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie, Yes we are in synch. I will support either decision as my individual WG input. So I am amoral on this one. thx /jim On Tue, 31 Jul 2001, Bernie Volz (EUD) wrote: > Jim: > > Agreed, DAD itself has little to do with this. > > However, when DAD is done does - because that determines when the client begins > to claim some ownership of that address (whether it uses it is another issue) > and it impacts when a Decline might be done. > > If the conclusion is that Advertise is just an advertisement of service (which > is what I'm arguing for and which was the original purpose of Advertise) and not > a "contract" of the actual addresses (which is the opposing view), DAD can't be > done until later (after Reply received) and so is not an issue. However, as you > specified it earlier, DAD was done on the Advertised addresses and that has > implications on what Advertise means. > > - Bernie > > -----Original Message----- > From: Jim Bound [mailto:seamus@bit-net.com] > Sent: Tuesday, July 31, 2001 11:23 AM > To: DHCPv6 discussion list > Subject: RE: Addresses and other parameters in Advertise and Solicit > > > Bernie, > > DAD has nothing to do with this at all. Its transparent. I will leave it > to my colleagues on the list to respond to other comments. > > thanks > > > /jim > > > On Tue, 31 Jul 2001, Bernie Volz (EUD) wrote: > > > Ted: > > > > I don't understand your argument. A broken server is just that, broken. What it will > > and will not allow a client to do is not an issue - fix the server. > > > > In fact, I believe having the actual assignment of addresses deferred until the Reply > > is received is far more likely to result in non-broken servers. A server, in the > > Advertise, just needs to tell the client that it is willing to assign address. > > > > The questions are: > > - Is Advertise a contract to give the client those addresses? > > - And, if it is a contract then MAY, SHOULD, or MUST the client perform DAD before > > doing the Request. And, when can a client start using an address? After Advertise? > > After Reply? > > > > Please also note that there are some other properties of DHCPv4's offer behavoir that > > are not currently specified in DHCPv6. Such as: > > - In DHCPv4, other servers listen to the broadcast of the DHCPREQUEST to learn that > > their offer has been DECLINED (see Section 3.1). If we do what you and Jim propose, > > do we need this? > > - In DHCPv4, the address is not checked until *AFTER* the DHCPREQUEST/DHCPACK sequence > > and a DHCPDECLINE is not valid until after the REQUEST/ACK sequence. > > - In DHCPv4, the offered address is included in the DHCPREQUEST to the server. If > > we're going to follow that convention, we need the client to send the IA option it > > received from the server in the REQUEST? > > - In DHCPv4, the server always has the ability to DHCPNACK the address received > > in the DHCPREQUEST. We've had a dicussion about NACKs before. But we would need > > to have a mechanism for the server to tell the client, gee sorry, that address isn't > > available now. Perhaps the mechanism is simply for the server not to include that > > address in the IA in the Reply. But again, this behavoir would not be needed if the > > addresses in the Advertise are just informational (I will assign you addresses similar > > to these). > > > > - Bernie > > > > -----Original Message----- > > From: Ted Lemon [mailto:mellon@nominum.com] > > Sent: Monday, July 30, 2001 3:46 PM > > To: DHCPv6 discussion list > > Subject: Re: Addresses and other parameters in Advertise and Solicit > > > > > > > > > thanks for the input I knew that this was your view. But Mark said > > > nothing about DAD. He said and also at the San Diego meeting it would be > > > good if we could optimize the protocol to support this jaundra. So your > > > recollection is not mine. thanks > > > > Blech. If Solicit/Advertise doesn't say what the merchandise is, > > it's easy to imagine a server that's broken in a way that would > > prevent a client from ever getting an address. We have been over > > this ground before. Jim is right. Please let's leave it that > > advertise says "I'll try to give you these addresses if you choose > > me." I.e., pretty much like DHCPOFFER in DHCPv4. > > > > _MelloN_ > > > From owner-dhcp-v6@bucknell.edu Tue Jul 31 16:11:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17735; Tue, 31 Jul 2001 16:11:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VKBd308187; Tue, 31 Jul 2001 16:11:39 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6VKBT311997; Tue, 31 Jul 2001 16:11:29 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA08525; Tue, 31 Jul 2001 16:10:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20010731154535.00b51320@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Jul 2001 16:08:52 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: DHC WG agenda for London Cc: dhcp-v6@bucknell.edu, dhcp-v4@bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN DHC WG activities update: Ralph Droms, 10 minutes Reviewed by IESG; revised and resubmitted: DHCP reconfigure extension Revisions published; ready for WG last call: The Classless Static Route Option for DHCP Encoding Long DHCP Options The DHCP Client FQDN Option Resolution of DNS Name Conflicts Among DHCP Clients DHCP Domain Search Option Subnet Selection sub-option for the Relay Agent Information Option Addition of Device Class to Agent Options Revision published; ready for wg last call? DHCP Failover Protocol (310279 bytes) Wireless Key Management using DHCP Bill Arbaugh, 10 minutes DHCP mDNS Enable Option Erik Guttman, 10 minutes LDAP Schema for DHCP Mark Meredith, Vijay Nanjundaswamy, Mark Hinckley, 15 minutes VPN Identifier sub-option for the Relay Agent Information Option DHCP VPN Information option Mark Stapp, 10 minutes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Jim Bound Ralph Droms, 60 minutes From owner-dhcp-v4@bucknell.edu Tue Jul 31 16:14:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18020 for ; Tue, 31 Jul 2001 16:14:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f6VKBd311277; Tue, 31 Jul 2001 16:11:39 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f6VKBT311997; Tue, 31 Jul 2001 16:11:29 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-191.cisco.com [161.44.149.191]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA08525; Tue, 31 Jul 2001 16:10:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20010731154535.00b51320@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 31 Jul 2001 16:08:52 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: DHC WG agenda for London Cc: dhcp-v6@bucknell.edu, dhcp-v4@bucknell.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN DHC WG activities update: Ralph Droms, 10 minutes Reviewed by IESG; revised and resubmitted: DHCP reconfigure extension Revisions published; ready for WG last call: The Classless Static Route Option for DHCP Encoding Long DHCP Options The DHCP Client FQDN Option Resolution of DNS Name Conflicts Among DHCP Clients DHCP Domain Search Option Subnet Selection sub-option for the Relay Agent Information Option Addition of Device Class to Agent Options Revision published; ready for wg last call? DHCP Failover Protocol (310279 bytes) Wireless Key Management using DHCP Bill Arbaugh, 10 minutes DHCP mDNS Enable Option Erik Guttman, 10 minutes LDAP Schema for DHCP Mark Meredith, Vijay Nanjundaswamy, Mark Hinckley, 15 minutes VPN Identifier sub-option for the Relay Agent Information Option DHCP VPN Information option Mark Stapp, 10 minutes Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Jim Bound Ralph Droms, 60 minutes