RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM envir onments

[Jim Bound <[e-mail]>]

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