Re: [dhcwg] some comments and questions on dhcpv6-24

[Ralph Droms <[e-mail]>]

Thanks for your review - I apologize for the delay in replying, and we'll 
take your comments into account when we edit the next rev of the draft.

- Ralph

At 05:24 PM 4/26/2002 +0900, JINMEI Tatuya / 
=?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>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?

The message should be rejected if it includes a Client Identifier option
and the client did not include the option in its original message.


>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?

It's necessary if the server received the Solicit directly from the client; 
i.e., if the server and the client are on the same link and the server is 
sending the Advertise to the client's link-local address.


>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.

This problem was fixed between preliminary publication of the -24
rev and the final version published at the IETF.


>    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...

This problem was fixed between preliminary publication of the -24
rev and the final version published at the IETF.


>    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"?

This problem was fixed between preliminary publication of the -24
rev and the final version published at the IETF.


>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.

Yes, we should make that clarification.

>   - 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.

We will add text clarifying that an Information-request containing IA options
is discarded.

>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.

OK, we'll make that consistency check.


>                                         JINMEI, Tatuya
>                                         Communication Platform Lab.
>                                         Corporate R&D Center, Toshiba Corp.
>                                         [e-mail]
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/dhcwg


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg