[dhcwg] some comments and questions on dhcpv6-24
JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Fri, 26 April 2002 10:05 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28573 for <dhcwg-archive@odin.ietf.org>; Fri, 26 Apr 2002 06:05:31 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29461 for dhcwg-archive@odin.ietf.org; Fri, 26 Apr 2002 06:05:31 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28008; Fri, 26 Apr 2002 05:50:33 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA23661 for <dhcwg@optimus.ietf.org>; Fri, 26 Apr 2002 04:24:13 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27170 for <dhcwg@ietf.org>; Fri, 26 Apr 2002 04:24:08 -0400 (EDT)
Received: from localhost ([3ffe:501:100f:1048:200:39ff:fed9:21d7]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g3Q8O9o15591 for <dhcwg@ietf.org>; Fri, 26 Apr 2002 17:24:09 +0900 (JST)
Date: Fri, 26 Apr 2002 17:24:23 +0900
Message-ID: <y7vadrqq348.wl@ocean.jinmei.org>
From: JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp>
To: dhcwg@ietf.org
User-Agent: Wanderlust/2.6.1 (Upside Down) Emacs/21.1 Mule/5.0 (SAKAKI)
Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan.
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset="US-ASCII"
X-Dispatcher: imput version 20000228(IM140)
Lines: 76
Subject: [dhcwg] some comments and questions on dhcpv6-24
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
I have some comments and questions on the latest I-D of DHCPv6, draft-ietf-dhc-dhcpv6-24.txt. 15.10. Reply message Clients MUST discard any received Reply messages that meet any of the following conditions: - the message does not include a Server Identifier option - the "transaction-ID" field in the message does not match the value used in the original message - the message does not include a Client Identifier option and the original message from the client contained a Client Identifier option - the message includes a Client Identifier option and the contents of the Client Identifier option does not match the DUID of the client What if the message includes a Client Identifier option but the client did not send the option in the corresponding request? 17.2.2. Creation and transmission of Advertise messages ... The Advertise message MUST be unicast through the interface on which the Solicit message was received. It seems to me the requirement is too strong. Is this really necessary? 18.2.5. Receipt of Information-request messages The server contructs a Reply message by setting the "msg-type" field ^^^^^^^^^this should be "constructs". There are many other "contructs" in the draft. to REPLY, copying the transaction ID from the Rebind message into the ^^^^^^ transaction-ID field. Should the "Rebind" message be "Information-request"? This sentence seems to be just copied from the previous section... The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Rebind ^^^^^^ message in the Reply message. Again, should the "Rebind" be "Information-request"? Other questions to this section: - what should the receiving server do if the Information-request contains a client Identifier option? I think the server MUST copy the option to the reply, but the draft does not mention this case. - what should the receiving server do if the Information-request contains an IA option? Section 18.1.5 says that: The client MUST NOT include any IA options. But none of this section and Section 15.12 mention this case. BTW: there seem to me several cases for this type of incompleteness. For example, Section 22.6 says "The IA Address option must be encapsulated in the Options field of an Identity Association option." But I'm not sure what a node should do when it receives an IA address option not encapsulated in an IA option. I've not gone through the entire draft, so I may miss something, and if so, I'd apologize in advance. If my guess is correct, however, then I'd suggest to check the consistency of the requirements over the entire draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] some comments and questions on dhcpv6-24 JINMEI Tatuya / 神明達哉
- RE: [dhcwg] some comments and questions on dhcpv6… Bernie Volz (EUD)
- Re: [dhcwg] some comments and questions on dhcpv6… Ralph Droms
- [dhcwg] Re: comments and qeustions on dhcpv6-24 JINMEI Tatuya / 神明達哉
- [dhcwg] comments and qeustions on dhcpv6-24 JINMEI Tatuya / 神明達哉
- Re: [dhcwg] some comments and questions on dhcpv6… JINMEI Tatuya / 神明達哉
- Re: [dhcwg] some comments and questions on dhcpv6… Ralph Droms
- [dhcwg] additional comments on dhcpv6-24 JINMEI Tatuya / 神明達哉
- [dhcwg] unresolved comments in dhcpv6-25 JINMEI Tatuya / 神明達哉
- Re: [dhcwg] unresolved comments in dhcpv6-25 Ralph Droms
- Re: [dhcwg] unresolved comments in dhcpv6-25 Ralph Droms
- Re: [dhcwg] unresolved comments in dhcpv6-25 Raymond Jayaraj
- Re: [dhcwg] unresolved comments in dhcpv6-25 JINMEI Tatuya / 神明達哉
- Re: [dhcwg] unresolved comments in dhcpv6-25 JINMEI Tatuya / 神明達哉
- Re: [dhcwg] unresolved comments in dhcpv6-25 Ralph Droms
- Re: [dhcwg] unresolved comments in dhcpv6-25 SHIRASAKI Yasuhiro