[dhcwg] unresolved comments in dhcpv6-25
JINMEI Tatuya / 神明達哉 <jinmei@isl.rdc.toshiba.co.jp> Sat, 01 June 2002 02:56 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 WAA09794 for <dhcwg-archive@odin.ietf.org>; Fri, 31 May 2002 22:56:22 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA20246 for dhcwg-archive@odin.ietf.org; Fri, 31 May 2002 22:56:48 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA20085; Fri, 31 May 2002 22:54:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA16871 for <dhcwg@optimus.ietf.org>; Thu, 30 May 2002 12:13:54 -0400 (EDT)
Received: from shuttle.wide.toshiba.co.jp (shuttle.wide.toshiba.co.jp [202.249.10.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11253 for <dhcwg@ietf.org>; Thu, 30 May 2002 12:13:26 -0400 (EDT)
Received: from localhost ([3ffe:501:100f:1041::6]) by shuttle.wide.toshiba.co.jp (8.11.6/8.9.1) with ESMTP id g4UGDZ863135 for <dhcwg@ietf.org>; Fri, 31 May 2002 01:13:35 +0900 (JST)
Date: Fri, 31 May 2002 01:14:30 +0900
Message-ID: <y7vit55ehp5.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.
References: <y7vadrqq348.wl@ocean.jinmei.org> <y7vadr4sf81.wl@ocean.jinmei.org> <y7vk7q5mg3c.wl@ocean.jinmei.org> <y7vadr0myz6.wl@ocean.jinmei.org>
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: multipart/mixed; boundary="Multipart_Fri_May_31_01:14:30_2002-1"
X-Dispatcher: imput version 20000228(IM140)
Lines: 733
Subject: [dhcwg] unresolved comments in dhcpv6-25
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
(Sorry for the long attachments) I've checked the draft dhcpv6-25 and found that most of my comments to the 24 draft was not addressed in the latest draft. Namely: - the "other questions" part of the first message - all comments except 3 and 14 in the second message - the comments 1 and 2 in the third message - the comment in the fourth message Some of the unresolved comments have been responded in this list, but it seems to me that the responses have not been reflected in the latest draft. Most of them are even not responded at all. Perhaps the reason is just because the comments and questions are so trivial and neglected. But, even so, I'd like to hear a short response like "they are trivial and does not have to be considered in the draft". Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp
--- Begin Message ---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--- End Message ---
--- Begin Message ---I've just gone thorough dhcpv6-24, and have some comments and questions on it. Since most of them are just for clarification or editorial comments, I've put all of them into this message. If we need to discuss some of them separately, please make another thread for the particular items. I've also checked recent discussions on the list based on comments from Thomas and tried to avoid duplicated comments (actually I have one.) I'd apologize in advance, if there is still any duplication. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp 1. Section 4.1. defines binding A binding (or, client binding) is a group of server data records containing the information the server has about the addresses in an IA and any other configuration information assigned to the client. A binding is indexed by the tuple <DUID, IA-type, IAID> (where IA-type is the type of address in the IA; for example, temporary) Is it always appropriate to contain "IA-TYPE" and "IAID" in the index of a binding? What if a configuration information (that needs a binding) is not associated with an IA? An IPv6 prefix delegated by DHCPv6 can be an example of such binding. 2. Section 15.13. says Clients MUST discard any received Relay-forward messages. What if a relay agent receives a relay-forward message? 3. Section 16. repeatedly says like When a client sends a DHCP message to the DHCP_Anycast address, it MUST use an address assigned to the interface for which the client is interested in obtaining configuration,... I think requiring the client to use an address on the particular "interface" is too strong (though it should be the typical case). The source address MUST be on the "link" to which the interface being configured belongs, since the server may use the information to detect the client's link, but does not necessarily have to be on the exact interface. Using the term "link" instead of "interface" is also consistent with the last paragraph of this section. Also, I don't get why the "default address selection" draft is cited here. If this is just because the draft describes the generic mechanism to select source addresses, I don't think we need to cite it explicitly here. 4. Section 17.1. says A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. The wording is too specific. Since the client may just need other information than addresses, the text should be like "DHCP servers configured to server addresses or other configuration parameters...". 5. Section 17.1.1. says The client MAY include options with data values as hints to the server about parameter values the client would like to have returned. I'm not sure how the data values are specified. An option request option can only specify required option "types"... The same comments applies to Sections 18.1.1 and 18.1.5. 6. Section 17.1.3 says The client MUST ignore any Advertise message that includes a Status Code option containing the value AddrUnavail, with the exception that the client MAY display the associated status message to the user. and Section 17.2.2 has a corresponding text: If the server will not assign any addresses to IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a status code option with the status code set to AddrUnavail and a status message for the user. With the specification, it seems to me that a client cannot configure itself without getting addresses (except via information-request and reply exchanges). For example, suppose that a client wants to be delegated an IPv6 prefix from a provider, and sends a solicit without any IA option. The server is configured to delegate prefixes only (i.e. not addresses), so it sends an Advertise message with an AddrUnavail code. Since the client MUST ignore the advertise message, it cannot proceed any more. So, the specification should be clearer on the procedure when a client does not need addresses. 7. What if a reply message for a solicit with a rapid commit option does *not* contain a rapid commit option? Section 17.2.3 says that the server includes a Rapid Commit option in the Reply message, but Section 17.1.4 says nothing about the case if the rapid commit option is not included. 8. It is not very clear when a server includes a Server Unicast option. Section 18.1.1 (and some succeeding sections) says Use of multicast or anycast on a link and relay agents enables the inclusion of relay agent options in all messages sent by the client. The server should enable the use of unicast only when relay agent options will not be used. But, this only talks about some restrictions of including the option. Even with the text of section 22.13, I'm still not sure when a server should or can send a Server Unicast option. It would be better to describe the allowed (or necessary) cases explicitly. 9. (I've once pointed it out, but I'll do it again) Section 17.2.2 says If the Solicit message was received directly by the server,...The Advertise message MUST be unicast through the interface on which the Solicit message was received. Technically, the requirement is too strong, since links are larger than interfaces according to the IPv6 scoped address architecture. So, more accurately, it should say "The Advertise message MUST be unicast through the link on which the Solicit message was received." (Also see the last paragraph of Section 16.) 10. Section 18.2.1 says When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a status code option with value UseMulticast and no other options. I'm not sure how the client should act when it receives the reply message. Should it resend the request to multicast? Should it restart the entire procedure from the solicit? At least Section 18.1.6 should mention this case. The same comment applies to Sections 18.2.3, 18.2.6, and 18.2.7. 11. Section 18.2.6 says "The server ignores invalid addresses." What does "invalid" exactly mean? In particular, I'm not sure if the source address of the receipt message is "invalid" or not (note that section 18.1.7 prohibits the client to use addresses being released as the source address). The text should clearly define the term "invalid". The same comment applies to Section 18.2.7. 12. Section 19.1.1 says "The server sets the transaction-id field to 0". But I could not found description about the case where the client receives a reconfigure message with a non-0 transaction-id. Should it discard the message, or should it ignore the non-0 value, or others? 13. Why doesn't the timeout and retransmission rule in Section 19.1.2 follow the general rules described in Section 14? Is there something special for reconfigure messages? 14. In the first sentence of Section 19.3 A client MUST accept Reconfigure messages sent to UDP port 546on... we need a white space after "546". 15. What if a client receives a reconfigure message but none of the configuration information was provided by the server (that sends the reconfigure)? What if only a part of the configuration information was provided by the server? Section 19.3.1 is not clear (enough) about the cases. 16. (Relevant to the comment 12 above) Section 19.3.1 says the client ignores any additional Reconfigure messages (regardless of the transaction ID in the Reconfigure message) until the exchange is complete. Subsequent Reconfigure messages (again independent of the transaction ID) cause the client to initiate a new exchange. But, according to Section 19.1.1, the transaction ID should always be 0. So I don't get the rationale about the wording here. Does this simply mean the client should always ignore the transaction-ID? If so, it seems to me more natural to say so explicitly. 17. Section 21.5.2 says A DHCP message MUST NOT contain more than one Authentication option when using the delayed authentication protocol. Then, what if a received message contains more than one Authentication option? Ignore the entire message, ignore the authentication options (but a particular one), or others? (an editorial comment) we need some additional white space in this paragraph: ... in the DHCP message to facilitate processing of the authentication information.The format of the Authentication... after "information". 18. Section 21.5.3 says receiver computes the MAC as described in [9]. The entire DHCP message (except the MAC field of the authentication option itself), is used as input to the HMAC-MDS computation function. This is not very clear to me. Does this mean we should regard the MAC field as an all-0 field when computation? 19. We need a closing parenthesis in the first sentence of Section 21.5.5.4: If the server has selected a key for the client in a previous message exchange (see section 21.5.6.1, the client MUST use the same key to generate the authentication information. The appropriate point should be after "21.5.6.1". 20. Section 22.5 says An identity association for temporary addresses option MUST NOT appear in a Renew or Rebind message. What should the receiving node do if this condition is broken? 21. Section 22.14 specifies to use a UTF-8 encoded text string, but it seems to me too much. I think a simple ascii text is enough. (However, this may be based on a consensus of a former discussion, and if so, I don't oppose to the result.) 22. Section 22.17 says A DHCP message MUST NOT contain more than one Vendor Class option. What should the receiving node do if this condition is broken? 23. Section 22.18 says A DHCP message MUST NOT contain more than one Vendor-specific Information option with the same Enterprise Number. What should the receiving node do if this condition is broken? 24. Section 22.19 says This option MUST NOT appear in any message except a Relay-Forward or Relay-Reply message. What should the receiving node do if this condition is broken? (This question should be extended in a general form; "what should the receiving node do if an option is included in a message in which the option MUST NOT be appeared?") _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg--- End Message ---
--- Begin Message ---I have some additional comments (and questions) on dhcpv6-24, particularly about server solicitation. (1) If the client sent a solicit message with a rapid commit option but the server responds to the solicitation with an advertise message, what should the client do? Should it ignore the advertise, should it accept the advertise and send a request, or others? Section 17.1.4 says ...If the client does not receive a Reply message, the client restarts the server solicitation process by sending a Solicit message that does not include a Rapid Commit option. So, the client should probably ignore the advertise (and keep waiting for a reply.) But I'm not 100% sure about this. (2) Section 17.1.2 says: If the client is waiting for an Advertise message, the mechanism in section 14 is modified as follows for use in the transmission of Solicit messages. The message exchange is not terminated by the receipt of an Advertise before IRT has elapsed. Rather, the client collects Advertise messages until IRT has elapsed. Should this rule apply if the client is retransmitting solicit messages? For example, suppose that there is no advertise in response to the first solicit, and so the client retransmit the solicit. If the client then receives a first advertise, should it still wait until IRT elapses? (3) The paragraph above then says: Also, the first RT MUST be selected to be strictly greater than IRT by choosing RAND to be strictly greater than 0. However, according to Section 13, the first RT should be RT = 2*IRT + RAND*IRT where RAND is a random number chosen with a uniform distribution between -0.1 and +0.1. Thus, RT >= 2*IRT - 0.1*IRT = 1.9 * IRT >= IRT (the rightmost '=' is satisfied only when IRT is 0) So the RT should always be greater than IRT regardless of the value of RAND, and "by choosing RAND to be strictly greater than 0" seems to be redundant. Is my understanding correct? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg--- End Message ---
--- Begin Message ---Section 18.2.1 of dhcpv6-24 says: When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a status code option with value UseMulticast and no other options. On the other hand, section 15.10 says - the message does not include a Server Identifier option (snip) - the message does not include a Client Identifier option and the original message from the client contained a Client Identifier option Those two requirements seem to be inconsistent, or at least be confusing. Should the reply message contain the Server Identifier option (and the Client Identifier option if the original message contained it) in the Reply even if the server is responding with a status code option with UseMulticast? Or should the client loosen the validation in 15.10 if the reply contains a status code option? Or others? JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg--- End Message ---
- [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