RE: [dhcwg] [dhcpv6] UseMulticast

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

My take is that a Reply MUST always include the Server Identifier option (since that identifies the server responding) and it MUST include the Client Identifier option if the client sent one.

I think the statements such as "no other options" should likely be reviewed and perhaps restates as no options containing configuration related information. We probably need a blanket statement somewhere that clarifies that all responses from a server to a client MUST contain:
- The server identifier of the server.
- The client identifier of the client if the client provided it.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, May 16, 2002 1:41 AM
To: [e-mail]
Subject: [dhcwg] [dhcpv6] UseMulticast


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


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