RE: [dhcwg] Rev of DHCPv6 spec

[Ralph Droms <[e-mail]>]

It probably wouldn't hurt to add a sentence to the effect that a server
MAY choose to accept unicast messages from clients to which the server has
not sent a unicast option.  A server might want to reject those messages
because they won't include relay agent options...

- Ralph

On Mon, 15 Oct 2001, Bernie Volz (EUD) wrote:

> Thanks Ralph, this looks good to me. I assume that this text change applies to other unicastable messages (Renew, Decline, Release), though perhaps the discussion section isn't needed everytime.
>
> Do we want to state anything about what the server must do (probably in a different section) if a unicasted packet arrives when unicast option wasn't sent to client? Personally, I don't see a need, but perhaps others do?
>
> - Bernie
>
> -----Original Message-----
> From: Ralph Droms [mailto:[e-mail]]
> Sent: Monday, October 15, 2001 10:45 AM
> To: Bernie Volz (EUD)
> Cc: '[e-mail]'; [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: [dhcwg] Rev of DHCPv6 spec
>
>
> 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