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

["Bernie Volz (EUD)" <[e-mail]>]

Thanks for these comments. We do need to fix these.

Regarding the general issue of improperly formatted messages (such as an IA Address option not encapsulated in an IA option or an IA option in an Information Request), there are two possible actions a server has:
1. Drop the message (ie, don't reply to it). Whether the server choses to log something is a server policy issue.
2. Respond with an appropriate reply with a Status Code option of UnspecFail.

The second action may be better as the client will hopefully not simply retransmit the bad request. And it is especially good early in implementations to help identify problems quickly.


Please keep comments coming!!!

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Friday, April 26, 2002 4:24 AM
To: [e-mail]
Subject: [dhcwg] some comments and questions on dhcpv6-24


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.
					[e-mail]


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