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

[Jim Bound <[e-mail]>]

OK.  thats correct.  I was presenting the logic model for DSTM processing.
thx
/jim


/jim


On Mon, 14 Jan 2002, Bernie Volz (EUD) wrote:

> Jim:
> 
> The client would send a DSTM option with the IA option encapsulated inside the DSTM option. The client need not send the IA Addr option if there are no addresses associated with the IA.
> 
> The -22 draft has the DSTM option encapsulating the IA option - the DSTM option is the outermost option.
> 
> - Bernie
> 
> -----Original Message-----
> From: Jim Bound [mailto:[e-mail]]
> Sent: Sunday, January 13, 2002 1:27 AM
> To: Bernie Volz (EUD)
> Cc: '???'; ngtans????; DHCP????
> Subject: Re: (ngtrans) RE: [dhcwg] Questions about DHCPv6 draft 22 to
> support DSTM envir onments
> 
> 
> 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