From owner-dhcp-v6@bucknell.edu Tue Nov 7 11:05:09 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13107; Tue, 7 Nov 2000 11:05:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eA7G1sb01750; Tue, 7 Nov 2000 11:01:54 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eA7G1lb14430; Tue, 7 Nov 2000 11:01:47 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA20556; Tue, 7 Nov 2000 11:01:28 -0500 (EST) Message-Id: <4.3.1.2.20001107104924.00b3e910@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 07 Nov 2000 10:59:24 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Meeting in San Diego 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 Remember that the cutoff for acceptance of I-Ds to be published before the San Diego IETF is 11/24 (rev -00 docs must be submitted by 11/17)... As is our custom, I have scheduled two DHC WG sessions - one for DHCPv4 issues (Monday, 12/11, 0930-1100) and one for DHCPv6 issues (Tuesday, 12/12. 0930-1100). If you have an agenda item for either meeting, please forward it to me so I can put together schedules for the two meetings. - Ralph From owner-dhcp-v6@bucknell.edu Fri Nov 10 16:42:09 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17680; Fri, 10 Nov 2000 16:42:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAALcwb09336; Fri, 10 Nov 2000 16:38:58 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAALcnb13224 for ; Fri, 10 Nov 2000 16:38:49 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA11827 for ; Fri, 10 Nov 2000 16:38:33 -0500 (EST) Message-Id: <4.3.1.2.20001107110830.00acae50@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 10 Nov 2000 16:38:45 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Update on status of 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 Mike, Jim and I have been working diligently to complete a revision of the DHCPv6 spec in time for the IETF meeting in San Diego. Our plan is to: * publish the draft before the 11/24 deadline * hold a design team teleconference early during the week of 12/4 to work through as many open issues as possible * bring the draft and the results of the design team teleconference to the WG for review at the IETF meeting in San Diego I will announce availability of the revised draft and details of the design team teleconference early next week. - Ralph From owner-dhcp-v6@bucknell.edu Fri Nov 10 21:43:32 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA29440; Fri, 10 Nov 2000 21:43:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAB2exb30872; Fri, 10 Nov 2000 21:40:59 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAB2ehb06779 for ; Fri, 10 Nov 2000 21:40:43 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Fri, 10 Nov 2000 21:40:28 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86036072CE@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: Update on status of DHCPv6 spec Date: Fri, 10 Nov 2000 21:40:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 Ralph: Thanks for the update and thanks to you, Mike, and Jim for working on the draft! - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, November 10, 2000 4:39 PM To: DHCPv6 discussion list Subject: Update on status of DHCPv6 spec Mike, Jim and I have been working diligently to complete a revision of the DHCPv6 spec in time for the IETF meeting in San Diego. Our plan is to: * publish the draft before the 11/24 deadline * hold a design team teleconference early during the week of 12/4 to work through as many open issues as possible * bring the draft and the results of the design team teleconference to the WG for review at the IETF meeting in San Diego I will announce availability of the revised draft and details of the design team teleconference early next week. - Ralph From owner-dhcp-v6@bucknell.edu Thu Nov 23 21:10:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17421; Thu, 23 Nov 2000 21:10:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAO273O23727; Thu, 23 Nov 2000 21:07:03 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAO26oO10915 for ; Thu, 23 Nov 2000 21:06:50 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id SAA00781 for ; Thu, 23 Nov 2000 18:06:35 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eAO26iA03021 for ; Thu, 23 Nov 2000 18:06:44 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id SAA20322 for ; Thu, 23 Nov 2000 18:06:33 -0800 (PST) Message-Id: <4.3.1.2.20001122120109.00bcd520@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 23 Nov 2000 21:06:32 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: -16 rev of DHCPv6 spec; design team teleconference 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 the -16 rev of the DHCPv6 spec later today. The changes to this document are based primarily on the results of the design team teleconference of 8/31 and subsequent WG mailing list discussion. I've included a summary of changes at the end of this message. I am planning another design team teleconference for 12/5, 12noon-3PM EST. The purpose for this teleconference is to discuss the changes in the -16 rev, with the goal of identifying and resolving as many outstanding issues as possible. The results of the teleconference will be reported at the WG meeting in San Diego. Any unresolved issues from the teleconference will be discussed during the WG meeting. Cisco Systems is happy to host the design team teleconference in Chelmsford, MA. In addition to a conference room in Chelmsford, we will have conference call capability to accommodate those who can't attend in person. and will be happy to reimburse those outside the U.S. for their calls. If you want to participate in the call on 12/5, please contact me for the phone number and conference ID. More details will follow next week. - Ralph PS If you're just *dying* to get a copy of the -16 rev, try ftp://ftp.eg.bucknell.edu/pub/draft-ietf-dhc-dhcpv6-16.txt ===== 23. Changes in this draft This section describes the changes between this version of the DHCPv6 specification and draft-ietf-dhc-dhcpv6-15.txt. 23.1. Order of sections New sections have been added at the end of this document to minimize changes in section numbering. Those sections will be rearranged in a future revision. 23.2. Reconfigure message DHCP Reconfigure and Reconfigure-reply messages and the associated mechanisms have been removed from this draft of the specification. 23.3. Releasable resources ``Releasable resources'' have been removed from this draft. 23.4. DHCP message header A common fixed DHCP message header has been defined. Not all fields are used in all messages. 23.5. Design goals The second sentence in the 8th design goal bullet has been removed. 23.6. Overview Section 8.2 (DHCP agents) has been removed. DHCP clients no longer need to know about specific DHCP agents. Section 8.3 has been modified to reflect the new encapsulating mechanism through which relays forward client messages to servers. Section 8.6 and 8.7 have been modified to describe ``identity associations''. Section 8.8 has been modified to reflect the deletion of ``reconfigure'' and ``reconfigure-reply'' messages. 23.7. Message formats, 9 Message formats have been changed. All messages share a common fixed message header followed by options. 23.8. Solicit and Advertise messages, (section 10) The description of the message exchanges have been changed to reflect: - New relay behavior - encapsulated client messages - Use of IAs 23.9. Prefix advertisement Servers no longer advertise prefixes. 23.10. Identity Associations Section 9.11 describes IAs in detail. A definition of ``IA'' has been added to section 2. The description of messages exchanges have been extended to include IAs. The IA option is defined in section 22.2 23.11. Extensions renamed options; defined in this document ``extensions'' are now called ``options''; the options referenced in this document are defined in section 22. 23.12. Transaction-ID ranges Solicit, Advertise, Request, Reply, Release and Reconfigure-init messages all use an unsigned 16-bit integer ``Transaction-ID''. Transaction-IDs generated by clients are considered to be chosen from a different namespace than those chosen by servers. There is no need to restrict clients and servers to select Transaction-IDs from specific ranges to avoid conflicts. 23.13. Release messages and relays Release/Reply messages are forwarded through relays. This mechanism eliminates the need for an 'R' bit. 23.14. Discovering relay agents Clients no longer learn the identity of relay agents. When the client only has a link-local address (e.g., the client has no assigned addresses), it now multicasts Request message, which is then forwarded by a relay agent on the same link. From owner-dhcp-v6@bucknell.edu Mon Nov 27 08:34:25 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08605; Mon, 27 Nov 2000 08:34:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eARDVCO02781; Mon, 27 Nov 2000 08:31:13 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eARDUkO28391 for ; Mon, 27 Nov 2000 08:30:46 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id FAA23565 for ; Mon, 27 Nov 2000 05:30:29 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id eARDUbA12834 for ; Mon, 27 Nov 2000 05:30:37 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id FAA04225 for ; Mon, 27 Nov 2000 05:30:26 -0800 (PST) Message-Id: <4.3.1.2.20001127082938.00bdde60@localhost> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 27 Nov 2000 08:30:06 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: -16 rev of DHCPv6 spec; design team teleconference 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 (This is a resend in case the original got lost in your flood of vacation e-mail... - RD) I've published the -16 rev of the DHCPv6 spec later today. The changes to this document are based primarily on the results of the design team teleconference of 8/31 and subsequent WG mailing list discussion. I've included a summary of changes at the end of this message. I am planning another design team teleconference for 12/5, 12noon-3PM EST. The purpose for this teleconference is to discuss the changes in the -16 rev, with the goal of identifying and resolving as many outstanding issues as possible. The results of the teleconference will be reported at the WG meeting in San Diego. Any unresolved issues from the teleconference will be discussed during the WG meeting. Cisco Systems is happy to host the design team teleconference in Chelmsford, MA. In addition to a conference room in Chelmsford, we will have conference call capability to accommodate those who can't attend in person. and will be happy to reimburse those outside the U.S. for their calls. If you want to participate in the call on 12/5, please contact me for the phone number and conference ID. More details will follow next week. - Ralph PS If you're just *dying* to get a copy of the -16 rev, try ftp://ftp.eg.bucknell.edu/pub/draft-ietf-dhc-dhcpv6-16.txt ===== 23. Changes in this draft This section describes the changes between this version of the DHCPv6 specification and draft-ietf-dhc-dhcpv6-15.txt. 23.1. Order of sections New sections have been added at the end of this document to minimize changes in section numbering. Those sections will be rearranged in a future revision. 23.2. Reconfigure message DHCP Reconfigure and Reconfigure-reply messages and the associated mechanisms have been removed from this draft of the specification. 23.3. Releasable resources ``Releasable resources'' have been removed from this draft. 23.4. DHCP message header A common fixed DHCP message header has been defined. Not all fields are used in all messages. 23.5. Design goals The second sentence in the 8th design goal bullet has been removed. 23.6. Overview Section 8.2 (DHCP agents) has been removed. DHCP clients no longer need to know about specific DHCP agents. Section 8.3 has been modified to reflect the new encapsulating mechanism through which relays forward client messages to servers. Section 8.6 and 8.7 have been modified to describe ``identity associations''. Section 8.8 has been modified to reflect the deletion of ``reconfigure'' and ``reconfigure-reply'' messages. 23.7. Message formats, 9 Message formats have been changed. All messages share a common fixed message header followed by options. 23.8. Solicit and Advertise messages, (section 10) The description of the message exchanges have been changed to reflect: - New relay behavior - encapsulated client messages - Use of IAs 23.9. Prefix advertisement Servers no longer advertise prefixes. 23.10. Identity Associations Section 9.11 describes IAs in detail. A definition of ``IA'' has been added to section 2. The description of messages exchanges have been extended to include IAs. The IA option is defined in section 22.2 23.11. Extensions renamed options; defined in this document ``extensions'' are now called ``options''; the options referenced in this document are defined in section 22. 23.12. Transaction-ID ranges Solicit, Advertise, Request, Reply, Release and Reconfigure-init messages all use an unsigned 16-bit integer ``Transaction-ID''. Transaction-IDs generated by clients are considered to be chosen from a different namespace than those chosen by servers. There is no need to restrict clients and servers to select Transaction-IDs from specific ranges to avoid conflicts. 23.13. Release messages and relays Release/Reply messages are forwarded through relays. This mechanism eliminates the need for an 'R' bit. 23.14. Discovering relay agents Clients no longer learn the identity of relay agents. When the client only has a link-local address (e.g., the client has no assigned addresses), it now multicasts Request message, which is then forwarded by a relay agent on the same link. From owner-dhcp-v6@bucknell.edu Tue Nov 28 10:42:11 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26732; Tue, 28 Nov 2000 10:42:10 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eASFanO26551; Tue, 28 Nov 2000 10:36:49 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eASFaPO02974 for ; Tue, 28 Nov 2000 10:36:26 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 10:36:10 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86036073D2@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Date: Tue, 28 Nov 2000 10:36:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 Ralph and others ... here's some comments on the -16 spec. In general, this looks GREAT! Excellent job! Sorry that these comments are in no particular order. - In most of the message headers, there is the 16-byte client-link-local address. What about dropping the first 64-bits of this (the prefix)? It would save 8-bytes/packet. This is just a thought - there might be good reasons NOT to do this. But on the other hand, it would remove the need for servers/relays to validate that the prefix is the link local - instead, they pre-append the prefix when they need to use it as a link-local address. So, if we were to do this, we'd call this 64-bit field "interface ID" or something similar (at least based on RFC 2373 terminology). >From RFC 2373, it appears that link local doesn't really consume the full 64-bits before the interface-id, instead only the first 10 bits are really specified (with the next 54-bits being zero, though it is not clear that is REQUIRED). | 10 | | bits | 54 bits | 64 bits | +----------+-------------------------+----------------------------+ |1111111010| 0 | interface ID | +----------+-------------------------+----------------------------+ - Section 9.10 calls the message "Server-forward" message. Yet most of the text uses "Relay-reply". Please fix. Relay-reply is used almost exclusively in the rest of the text. - Section 22.2's diagram has a "pref. len". Yet this field is not defined anywhere in the list of fields. Was this an error in the diagram? Or was this to be the "prefix length"? If pref. len is prefix length, you might want to consider what to use as an abbreviation since then pref. could be "prefix" or "preferred" (as in preferred lifetime). Also, if this is "prefix length", then the format of address/prefix length is REVERSED from that used in the Relay-Forward/Server-Forward (see sections 9.9 and 9.10). Might be nice to have it consistent in always having prefix length/address (or address/prefix length). In RFC 2461, for prefix advertisements, the prefix appears before the address. - In section 23.7, the claim is made that "add messages share a comment fixed message header followed by options." This is not true (unless one assumes that the fixed message header is the 1-byte msg-type field). See Section 9.9 and 9.10 as they don't share the common message header. Might is be wise to consider changing the Relay-forward/Server-forward messages to use the common header? Though likely most of the fields would be 0's so it may be a waste. - In section 9.2 and 9.4, it might be best to move the "See sections 14.4 and 15.3 for information ..." under the "preference" definition text. Also, perhaps some indication that higher values indicate "more" preference to the server are worth nothing in these descriptions? - In section 9.5, there is a "P (unused) MUST be 0" in the definitions that doesn't belong. - In section 9.9, shouldn't there be some more details around the "relay-address"? This address must be carefully chosen by the relay to reflect the network on which the client is located. As most interfaces are bound to have many addresses, picking the proper address may be a bit involved. This will likely be a major issue for relays and the configuration of DHCP in IPv6 networks. For example, use of the relay's link-local address for the interface is no good. But, are locally scoped address potentially legal? Or must this be a fully routable (Internet-routable) address? - It is not clear why section 9.11 is where it is. Section 9 does say it is "Message Formats and Identity Associations" but I would think it best to put the Identity Association in a separate section. - In section 10.3.1, setting a transaction id is not specified. Implied action is to set it to 0 (The client sets all other fields to zero). - In section 10.3.3, there are several mentions of "advertising availability of IP address" ... how is this done (perhaps there will or is an option that will provide this information?). Also, if this capability DOES exist, isn't Ted's Discussion point in section 10.5.2 null and void? - Finally, there are a bunch of minor typos and like errors. But I've ignored those for now as I think most of those will get addressed in the -17 draft. If you want me to send my list sometime, let me know. And I still need to more carefully review section 11 to 17 and thus may have further comments. But, again, nice job and I think we're making excellent progress. - Bernie Volz Ericsson DNS & DHCP Development Unit From owner-dhcp-v6@bucknell.edu Tue Nov 28 12:18:24 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06135; Tue, 28 Nov 2000 12:18:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eASHF3O16561; Tue, 28 Nov 2000 12:15:03 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eASHEoO28345 for ; Tue, 28 Nov 2000 12:14:50 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Tue, 28 Nov 2000 12:14:34 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86036073D6@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec (Part 2) Date: Tue, 28 Nov 2000 12:14:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" 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 Ralph and others: Had some more time to finish the document review. Here's some additional comments: - In section 8.3, "Relays receive the Solicit and Request messages ...", they also receive Release messages (and perhaps others in the future). - In section 11.4.2, if the client fails to get a response from Request messages, should it fall back to the Solicit state or perhaps use any 'cached' information from previous Solicits to contact a lower preference server? I would think that the clients should not "stop" requesting addresses just because they can't contact a server. If an application requests an address, it should have a means to specify some timeout or other means to abort the request. If the client has just booted and is trying to get addresses, it should continue to try forever (perhaps backing off in how frequently it does Solicit / Request sequences). - In section 11.4.3, where is this 'status' field? Isn't this to be carried in an option? Also, if the request is successful, does a status need to be sent (if in an option)? Also, what's the impact if there are multiple IAs specified in the request and some are successful and others aren't (for whatever reason?)? - In section 11.4.4, what's the "(The client always forwards Release messages to the server through a relay; see section 11.5)" all about? 11.5 provides no useful information in this regard. Also, what if there is no relay? Also, should a client always use a link local address when sending a release? If so that should be stated (in that case a relay is required if the server is not on the link). - In section 11.4.5 and 11.4.6, it should state clearly that a client MUST stop using the addresses when sending a Release (whether or not a Reply is received). - In section 11.4.8, add 'send' ... "it may [send] a Request message". And, drop 'to' in "The server returns [to] IA(s)...". - In section 11.4.9, what if the 'old' server is not reachable (such as it was reached via a link-local address and you're now on a different link)? Or perhaps the server was a scoped address? Shouldn't there be some more thoughts about this? I think this needs some more consideration about what the best mechanism to determine what to do is. For example, if there are Router Advertisements, perhaps the client can determine whether its 'current' addresses are still valid and base a decision on that? If there are no Router Advertisements, perhaps the client should start at Solicit. If the same server responds, it can continue using it (regardless of the preference values)? Microsoft's Windows 2000 client uses the router address - it 'pings' the router address (with a hop limit of 1 I suspect) and if it gets a response, it assumes it is still on the same subnet. This is a nice approach and generally works very well. - In section 11.4.10, add 'may' ... "The server [may] remove addresses from the IA ...". Also, "If the server does not assign an explicit value to T1 or T2 ...". How is that done? The option has fixed fields for T1 and T2. Perhaps you're allowing these to have some magic value (such as 0 or all bits 1?)? If so, that isn't mentioned in the option text (section 22.2). - In section 11.5.1, some thought might be needed regarding the address issue (see previous set of comments). For example, depending on the server the request is forwarded to, the relay-address / prefix length might need to be different. So, the text is probably a bit too simplistic. Again, we should discuss this issue. - In section 11.6.3, again the 'status' field is discussed. Where is it in the message? An option? Also, the forward (relay) message names here don't match other sections. - In section 12, I think you should be staying if new prefixes are added to a link. As you indicating, adding new links is meaningless (if a client gets a new link, it would need to start IPv6 on that link and hence would do DHCP if so specified). The issue for servers and Reconfigures is if new prefixes are added (or old ones removed or depreciated). - In section 12.4.4, some text should be added about having the server 'pace' unicast Reconfigure-Init messages. If there are 100's of clients on a link, the server should send the 100's of reconfigure-init messages 'slowly' (perhaps 10/second or some such number). Also, using the transaction-id from the Reconfigure-Init message in Request messages can cause problems (collisions) with client generated values. While you might argue that it doesn't matter, it may in some instances and therefore we should be careful about this. One solution might be to have a 'Reconfigure-Init Transaction ID' option to carry that transaction ID and thus the number space between client and server don't collide. Also, this aids the server in understanding that this Request was generated by a 'Reconfigure-Init'. - In section 12.4.5, what about Multicast implications? If the Reconfigure-Init is multicast, should a server retransmit it? If so, clients might need to remember recent Reconfigure-Init transaction ids so they know if they've received a duplicate? Or is the server restricted to ONE multicast message and then needs to switch to unicast? This also applies to section 12.5.1 - check for duplicates? - In section 12.5.2, does the client need to pause under all cases before sending the Request? Or just if multicast received. - In section 12.5.4, isn't this just the usual Reply processing? - In section 14.2, more details on what is and is not cachable should be added. - In section 14.3, I see there being 3 sources of values: - Defaults (per RFC) - Server (per option) - Client configuration How do these interact? Which as priority over the other. I think it is clear that the Defaults are lowest on the food chain. But, should a client's configuration prevent using server supplied values? Perhaps this is a client policy issue? - In section 14, would an additional section on how to generate IAs be useful? We had long discussions about this on the mailing list and there really isn't much said about this in the specification. - In section 15, would an additional section on how to assign addresses be appropriate? I'm not saying we should force servers to adhere to a convention, but what about providing some guidelines? Are servers supposed to use the EUI-64 identifier or not when generating addresses? ... - In sectin 17.4, what about considering an option to carry this information? That way, servers MAY use it to change their behavoir but they need not rely on it. Clients MAY supply it if they want servers to consider this? I'm happy if the discussion decides that this is a REQUIRED piece of information (but then I'd still put it in an option). Thats it for now. - Bernie Volz Ericsson DNS & DHCP Development Unit From owner-dhcp-v6@bucknell.edu Tue Nov 28 13:16:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA24743; Tue, 28 Nov 2000 13:16:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eASIDjO23752; Tue, 28 Nov 2000 13:13:45 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eASIDTO18046 for ; Tue, 28 Nov 2000 13:13:29 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11285 for ; Tue, 28 Nov 2000 10:13:24 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.89.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id KAA23660 for ; Tue, 28 Nov 2000 10:13:20 -0800 (PST) Received: from lillen (lillen.Eng.Sun.COM [129.146.86.161]) by jurassic.eng.sun.com (8.11.2.Beta1+Sun/8.11.2.Beta1) with SMTP id eASIDKj836304 for ; Tue, 28 Nov 2000 10:13:20 -0800 (PST) Date: Tue, 28 Nov 2000 10:12:55 -0800 (PST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: Re: -16 rev of DHCPv6 spec; design team teleconference To: DHCPv6 discussion list In-Reply-To: "Your message with ID" <4.3.1.2.20001122120109.00bcd520@funnel.cisco.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph, I hope I can attend the telecon. Can you send me the phone number etc. Thanks, Erik From owner-dhcp-v6@bucknell.edu Thu Nov 30 15:22:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00700; Thu, 30 Nov 2000 15:22:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id eAUKH8O11527; Thu, 30 Nov 2000 15:17:09 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id eAUKGqO16589; Thu, 30 Nov 2000 15:16:52 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-146.cisco.com [161.44.133.146]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA09518; Thu, 30 Nov 2000 15:16:36 -0500 (EST) Message-Id: <4.3.1.2.20001130150914.00b0c3a0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 30 Nov 2000 15:10:27 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: DHC WG meetings in San Diego 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 Information about the DHC WG meetings in San Diego is now available at http://www.dhcp.org/0012-meeting.html If you would like to be added to the agenda, please send me a request for time as soon as possible. - Ralph