Re: (ngtrans) RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM envir onments

[Jim Bound <[e-mail]>]

Bernie,

So the client could send in a request

IA
DSTM Option
IA Address Option (empty)

To the server that sent the Reconfigure.
As one way to implement the behavior.

The IA is still valid.

regards,


/jim


On Sun, 13 Jan 2002, Jim Bound wrote:

> Hi Bernie,
> 
> Our readings are not similar.  The server does not have to send addresses
> back with an advertise but just ack the IA.
> 
> In 17.2.2  it says:
> 
>    The server MUST include IA options in the Advertise message
>    containing any addresses that would be assigned to IAs contained in
>    the Solicit message from the client.  The server MAY include some or
>    all of the IA options from the client in the Advertise message.
> 
>    If the server will not assign any addresses to IAs in a subsequent
>    Request from the client, the server SHOULD either send an Advertise
>    message to the client that includes only a status code option with
>    the status code set to AddrUnavail and a status message for the user
>    or not respond to the Solicit message.
> 
> In the first paragraph the IA refers to the Identity Association Option.
> Not the IA Address Option.  The wording is correct in the spec.  IA by
> itself is a reference to the IA option as defined in 22.3.  If you then
> look at 22.4 it references the IA address option specifically.  So IA is
> the association (e.g. IAID, T1 and T2, etc.)   To reference the addresses
> for an IA we say specifically IA Address Option as in 22.4.
> 
> Hence the server MUST return the IAs but may not return addresses and it
> can too.  The spirit of this was to provide in dhcpv6 the optimization the
> working group requested so the client could get addresses after solicit
> from the server.  But the server policy can be that the client must do a
> request to get addresses unless it states specifically ADDRUNAVAIL for a
> specific IA (association again).
> 
> On Sat, 12 Jan 2002, Bernie Volz (EUD) wrote:
> 
> > Hum, my understanding of -22 is that a client MUST go (back) to the Solicit state to "request" new IAs. Request, Renew, Rebind can only be used on IAs that have been used in a Solicit (or better yet, returned by a server in an Advertise response to a Solicit):
> > 
> > 18.1.1. Creation and transmission of Request messages
> > 
> >    The client uses a Request message to populate IAs with addresses
> >    and obtain other configuration information.  The client includes
> >    one or more IA options in the Request message, with addresses and
> >    information about the IAs that were obtained from the server in a
> >    previous Advertise message.  The server then returns addresses and
> >    other information about the IAs to the client in IA options in a
> >    Reply message.
> 
> So 18.1.1 is correct that the client can later poplulate IAs with
> addresses by sending IA Address Options with an IA with Request.
> 
> > 
> > I'm not necessarily completely happy with this (as I suspect you aren't), 
> >but I think it has some benefits - since it is also possible that if
> >there are multiple servers, some may be configured to provide DSTM
> >addresses and others not?
> >
> 
> We are fine with the current text completely.  I believe you may be
> confusing IAs with IA Address Options.
> 
> In the case of DSTM the server that tells the client they need a DSTM
> address in early deployment of IPv6 will also have the DSTM addresses and
> possibly nothing else for clients.  Its purely a server that knows thru
> user administration that specific clients need DSTM addresses.  Its an
> optimization early on designed in DSTM (go see NGTRANs DSTM discussions
> and presentations) to permit this kind of relationship via dhcpv6.
> 
> But as you suggest is also possible and most likely at medium and long
> term IPv6 deployment where the client is best off going to solicit to find
> the server.
> 
> DHCPv6 -22 supports both mechanisms and our IA and IA Address Options work
> well in both cases and we have done a good job in the working group to
> support this need from NGTRANS in the community.
> 
> regards,
> /jim
> 
> 


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