RE: [dhcwg] Rev of DHCPv6 spec

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

I don't think the server is responsible for knowning all about the client - it can't. Therefore, the server simply sends the option as a matter of configuration policy (ie, no cable modems involved on those links and hence no reason why client can't unicast). It is up to the client to determine whether it CAN unicast.

So, to the server it is a matter of configuration.

To the client, it has to make the decision as to whether to unicast to the server. It can make this decision based on:
- Receipt of the option from the server
- Conditions of its addresses (does it have an address of sufficient scope). For example, if the server is on the same link, it can always unicast (using the link local). If the server is off-link, it can only unicast should it have an address available of sufficient scope (note that some links may have autoconfigured AND managed (DHCP) addresses).

I don't understand why this is such a big deal?

Please understand that multicasting for DHCPv6 is not like broadcasting. Only those hosts with an interest in that functionality (DHCP relays and servers) need to receive these packets.

- Bernie

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Monday, October 15, 2001 8:31 AM
To: Bernie Volz (EUD); Ralph Droms
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [dhcwg] Rev of DHCPv6 spec



Are there any conditions that the server has to check before sending an
unicast option, other than scope of the client's address. ( The draft talks
about "sufficient scope" only  20.11 in draft 20d).
If not,
     (a) Is there difference between the client verifying its scope to
reach the  server's address and server verifying the scope of the client
address to send the unicast option?.   if this is the case may i know what
are they. Does the example given by you (cable modem) considers this case?.

if yes:
     what are the other checks that the server has to perform.

If answer to (a) is "no difference", why does a client need to receive
"unicast option" from the server? instead of checking it at client's side.
-suresh

>The reason for having the SERVER send the unicast option and tell the
client that it is OK is to avoid some of the >problems that exist today
with client renewals that don't go through relay options (such as in cable
modem >systems). Since the client/server communicate directly (in DHCPv4),
the relay can't add the relay-agent options to >the client's messages. If
this isn't in the -20 draft, perhaps we should add something about it (just
so people in >the future won't need to ask why).
>
>I think that a client MUST NOT unicast a message unless it has received
the unicast option from that server. (As >Ralph indicated, I'm not sure it
is required that a server MUST check that a message was multicast unless it
told >the client it was OK to use the unicast option; however, a server is
free to drop those datagrams if it wishes. >Hence, for a client to get
service from all servers, it will need to honor the required behavior).
>
>- Bernie Volz
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: Saturday, October 13, 2001 3:06 AM
>To: Ralph Droms
>Cc: [e-mail]; [e-mail]; [e-mail]
>Subject: Re: [dhcwg] Rev of DHCPv6 spec
>
>
>
>
>
>Ralph Droms <[e-mail]> on 10/12/2001 03:36:08 PM>
>
>Please respond to Ralph Droms <[e-mail]>
>
>To:   Suresh Kodati/India/IBM@IBMIN
>cc:   [e-mail], Suparna Bhattacharya/India/IBM@IBMIN, R
>      Sharada/India/IBM@IBMIN
>Subject:  Re: [dhcwg] Rev of DHCPv6 spec
>
>
>
>
>
>
>>1./2. the unicast option is an administrative policy;
>
>>3. I don't see any text in 16.1.1 that requires the
>>client to check that the server is on the same link>
>
>
>I took the case of client and server on the same link as an example for
the
>first condition 16.1.1/16.1.3/16.1.6/16.1.8/ "If the client has a source
>address that can be used by the server as a return address").
>
>>In response to your last question, the use of unicast
>>isn't dependent on whether the client and server
>>are on the same link.  A client could use unicast to
>>deliver DHCP messages to an off-link router.

>>The draft doesn't specify how a server should react
>>to a unicast message received from a client to which the
>>server has not sent a unicast option.  I imagine the
>>right thing to do is to allow the server to process
>>such messages.

>If the client can unicast the message without referring to receipt of
>unicast option from the server, (and since the server doesn't mandate the
>client to use unicast the messages to the server by sending unicast
>option), How this option would be useful.
>
>Is there any scenario that a client cannot unicast the
>REQUEST/RENEW/RELEASE/DECLINE even after receipt of unicast option from
the
>server.

>Isn't it is enough to leave it to the client to choose the
>unicast/multicast based on the first condition ("If the client has a
source
>address that can be used by the server as a return address").

-Suresh