[dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt
Richard Hussong <rhussong@juniper.net> Tue, 29 October 2002 21:44 UTC
Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27046 for <dhcwg-archive@odin.ietf.org>; Tue, 29 Oct 2002 16:44:40 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id g9TLkbL08573 for dhcwg-archive@odin.ietf.org; Tue, 29 Oct 2002 16:46:37 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TLkbv08570 for <dhcwg-web-archive@optimus.ietf.org>; Tue, 29 Oct 2002 16:46:37 -0500
Received: from www1.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27005 for <dhcwg-web-archive@ietf.org>; Tue, 29 Oct 2002 16:44:09 -0500 (EST)
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TLi4v08442; Tue, 29 Oct 2002 16:44:04 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id g9TLglv08338 for <dhcwg@optimus.ietf.org>; Tue, 29 Oct 2002 16:42:47 -0500
Received: from mailwest.unispherenetworks.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26783 for <dhcwg@ietf.org>; Tue, 29 Oct 2002 16:40:18 -0500 (EST)
Received: by uniwest1.unispherenetworks.com with Internet Mail Service (5.5.2653.19) id <VDJVYVPH>; Tue, 29 Oct 2002 16:42:40 -0500
Received: from rhussongpc.dhcp.west.unispherenetworks.com ([10.10.121.9]) by mailwest2.unispherenetworks.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VDJM9TSA; Tue, 29 Oct 2002 16:35:32 -0500
From: Richard Hussong <rhussong@juniper.net>
To: dhcwg@ietf.org
Date: Tue, 29 Oct 2002 16:42:44 -0500
Organization: Juniper Networks, Inc.
Message-ID: <310uru0q1a32fthd4qt21qb71h8jhhoelj@4ax.com>
X-Mailer: Forte Agent 1.9/32.560
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id g9TLglv08339
Subject: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Id: <dhcwg.ietf.org>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 8bit
Content-Transfer-Encoding: 8bit
To: Ralph Droms <rdroms@cisco.com> I have some comments on the new DHCPv6 draft. I think the changes have improved its clarity quite a bit, but I still see a few problems. Actually, some of these were in the previous draft; I'm sorry I didn't find them there and bring them to your attention, but I haven't been on this stuff for long. First, a general comment: since IPv6 has stateless address auto-configuration, and small routers are becoming increasingly common, even in homes, isn't it possible, even likely, that the main use of DHCPv6 will be for prefix delegation rather than address assignment? If this is the case, it seems unfortunate that prefix delegation is not in this document, since that fact makes it appear that it is of lower status or importance than the address assignment that is in the document. I am sure there are sound historical reasons for putting prefix delegation in a separate document (including the controversy over whether prefix delegation should be handled by DHCPv6 at all), but there are so many parallels between address assignment and prefix delegation that it seems a shame not to treat them in a parallel fashion. The rest of the comments are on particular sections of the draft. ============= Section 1.3, "Client-server Exchanges Involving Four Messages" Typo in Paragraph 2: "the client sends a Renew messages ..."; "messages" should be "message". ============= Section 16. Client Source Address and Interface Selection Typo in Paragraph 1: "... is certain the two interface are ..."; "interface" should be "interfaces". ============= Section 17.1.1. Creation of Solicit Messages In Paragraph 4: The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. This states that the Option Request option is required in a Solicit message. However, Section 22.7 says: A client MAY include an Option Request option in a Solicit, Request, Renew, Rebind, Confirm or Information-request message to inform the server about options the client wants the server to send to the client. This implies that the Option Request option is not required in a Solicit message. Should the server treat a Solicit message without an Option Request option as invalid? If the client includes instances of particular options without listing their codes in the Option Request option, should those options be ignored? ============= Section 17.1.1. Creation of Solicit Messages In Paragraph 5: The client MUST include a Reconfigure Accept option (see section 22.20) indicating whether or not the client is willing to accept Reconfigure messages from the server. This states that the Reconfigure Accept option is required in a Solicit message. However, Section 22.20 says: The default behavior, in the absence of this option, means unwillingness to accept Reconfigure messages, or instruction not to accept Reconfigure messages, for the client and server messages, respectively. This implies that the Reconfigure Accept option is not required in a Solicit message. Should the server treat a Solicit message without a Reconfigure Accept option as invalid? ============= Section 18.1.5. Creation and Transmission of Information Request Messages In Paragraph 5: The first Information-request message from the client on the interface MUST be delayed by a random amount of time between 0 and INF_MAX_DELAY. It is not specified what event defines the start of the delay period. I imagine the intent is that the delay starts from the "interface up" event. Is that true, and would there be any value in making it explicit? ============= Section 18.1.8. Receipt of Reply Messages Paragraph 3, bullet 4: - Discard any addresses from the IA as recorded by the client that have a lifetime of 0 in the IA Address option Just for clarity, perhaps "lifetime" should be "valid lifetime"? ============= Section 18.2.8. Transmission of Reply Messages Typo in Paragraph 2: "see Section!22.10" should be "see Section 22.10". ============= Section 22.4. Identity Association for Non-temporary Addresses Option In the next-to-last paragraph, In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters. However, in the last paragraph, If the time at which the addresses in an IA_NA are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. I suspect the intent of the extract from the next-to-last paragraph is something like "In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 parameters, unless they are 0", right? ============= Section 22.6. IA Address Option In Paragraph 3: In a message sent by a server to a client, the client MUST use the values in the preferred and valid lifetime fields for the preferred and valid lifetimes. Just for clarity, it might be useful to note here than a valid lifetime field value of 0 has the special meaning of "stop using this address", even though that is the natural consequence of a valid lifetime of 0. It would be even handier if a cross-reference were included to Section 18.1.8, which discusses the Reply message that might actually use such 0 lifetime values. ============= Section 22.6. IA Address Option Typo in Paragraph 3: "More than one IA Address Options can appear"; "Options" should be "Option". ============= - Richard Hussong _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.txt Richard Hussong
- RE: [dhcwg] comments on draft-ietf-dhc-dhcpv6-27.… Bernie Volz (EUD)