RE: [dhcwg] Rev of DHCPv6 spec

[Ralph Droms <[e-mail]>]

The relevant text for Request messages in the -20d rev is:

    If the client has a source address that can be used by the server
    as a return address and the client has received a Client Unicast
    option (section 20.11) from the server, the client SHOULD unicast
    the Request message to the server.  Otherwise, the client sends
    the Request message to the All_DHCP_Agents multicast address.

To clarify and emphasize the requirement for multicast, I suggest the 
following text:

    If the client has a source address that can be used by the server
    as a return address and the client has received a Client Unicast
    option (section 20.11) from the server, the client SHOULD unicast
    the Request message to the server.  Otherwise, the client MUST send
    the Request message to the All_DHCP_Agents multicast address.

    DISCUSSION:

       Use of multicast 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.

Is this replacement text sufficiently clear?

- Ralph


At 09:08 PM 10/14/2001 -0500, Bernie Volz (EUD) wrote:

>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]>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
>
>At 12:18 PM 10/12/2001 +0530, [e-mail] wrote:
>
> >I would like to get clarification on when does a server send an unicast
> >option,
> >1. does the server send unicast option  whenever the client is on the same
> >link (20.11 is not clear about it) (or)
> >2. Is it an administrative policy that decides if the client can
> >unicast/multicast of messages. If it is so, is there any example of the
> >scenario where the server would not specify the option despite being on
>the
> >same link.
> >3. why is the client required to check if the client and server are on the
> >same link if  unicast option is already obtained from the server ( 16.1.1
>)
> >
> >And also,
> >  Is it not sufficient to have both client and server to be on the same
>link
> >to unicast client's message ?, if so what is the server response to
> >client's unicast if it didn't send unicast option to the client and still
> >gets messages unicast'ed to it.
> >-suresh
> >
> >
> >Ralph Droms <[e-mail]> on 10/11/2001 07:31:31 AM
> >
> >Please respond to Ralph Droms <[e-mail]>
> >
> >To:   [e-mail]
> >cc:    (bcc: Suresh Kodati/India/IBM)
> >Subject:  [dhcwg] Rev of DHCPv6 spec
> >
> >
> >I've finished another rev of the DHCPv6 spec (-20d), which is available at
> ><http://www.dhcp.org/dhcpv6.tty>http://www.dhcp.org/dhcpv6.tty  I plan 
> to submit this draft of the spec to
> >the IETF for publication on 10/12.  The list of issues addressed by this
> >draft is included below; these issues were discussed at the DHC WG meeting
> >in London (8/2001).  The -20d draft does not include any changes related
>to
> >IAs.  The changes related to IAs will appear in the next published rev of
> >the draft.
> >
> >- Ralph
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
><http://www1.ietf.org/mailman/listinfo/dhcwg>http://www1.ietf.org/mailman/listinfo/dhcwg 
>
>
>
>
>_______________________________________________
>dhcwg mailing list
>[e-mail]
><http://www1.ietf.org/mailman/listinfo/dhcwg>http://www1.ietf.org/mailman/listinfo/dhcwg 
>


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