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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sat, 12 Jan 2002 11:11:56 -0600

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.

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?

- Bernie

-----Original Message-----
From: Jim Bound [mailto:[email-masked]]
Sent: Saturday, January 12, 2002 1:44 AM
To: Bernie Volz (EUD)
Cc: '???'; ngtans????; DHCP????
Subject: RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM
envir onments

Bernie is correct.  The DSTM draft is in the process of using whats in
Draft -22.

Currently if the server tells the client via an ORO request a DSTM option
the client has to begin that with a solicit via an IA.

I believe DSTM implementors will want to justt request an IA with DSTM
option at a request.  Which can be done too.

/jim

/jim

On Fri, 11 Jan 2002, Bernie Volz (EUD) wrote:

> For a Solicit, you would send the DSTM option with an IA Option encapsulated within it.
> 
> The server should then send you back an Advertise with a DSTM Option with an IA Option encapsulated within it (and within the IA Option would be an IA Address Option which contains the V4 address).
> 
> The Request is then sent with what the server sent you (DSTM Option ...).
> 
> In any Renew, Rebind, ... you would continue to send the DSTM Option with IA Option with IA Address Option.
> 
> APPENDIX B is wrong and needs to be fixed. Good catch. DSTM Option is allowed in Solicit, Advert., Request, Confirm, Renew, Rebind, Decline, Release, and Reply. (Same list as that for IA.)
> 
> 
> A Client CAN NOT place the DSTM option in the ORO option. The reason for this is that a IA ID must be provided and the ORO option can not also provide this. Therefore, the ONLY way a client can request a DSTM address is by sending a DSTM option and encapsulating an IA Option within it (to specify the IA ID). Whereever a IA option can appear, a DSTM option with an encapsulated IA option may appear.
> 
> 
> Note that the other DSTM I-Ds may not yet be fully in agreement with the changes recently done to the DHCP DSTM option.
> 
> - Bernie
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, January 11, 2002 3:50 AM
> To: ngtans????; DHCP????
> Subject: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM
> environments
> 
> 
> We are developing the DSTM client. So we have following up to the DHCPv6 draft 22.
> We have several questions about the DHCPv6 draft 22 in a point of view to support 
> the DSTM environments. 
> 
> Question 1 : 
> According to the draft version 22, when a client request DSTM Global IPv4 address,
> the client send IA and IA Address option encapsulated in DSTM Global IP address option. 
> But, Appendix B describes that DSTM Global IP address option is not included in Request.
> Is my thought wrong? 
> 
> Do you think that a client should request DSTM Global IPv4 address by transmitting request message
> set OPTION_DSTM at within ORO option?
> 
> When a client want to renew, rebind or release for the assigned IPv4 global address, 
> should I transmit those messsage set OPTION_DSTM at within ORO option to DHCPv6 server?
> 
> I think, if we use DSTM global IPv4 address option at request message,
> dhcpv6 spec can support the client which have multiple interfaces.
> but, with request message set OPTION_DSTM at within ORO option, it is difficult to support those client.
> How do you think about it?  
> 
> section 22.11 at draft 22 describes as followings:
>   "The DSTM Global IPv4 Address Option informs a client or server that
>    the Identity Association Option (IA) encapsulated in this option
>    contains or requests an IPv4-Mapped IPv6 Address [10]"
> 
> and also Appendix B at draft 22 describes as followings:
> 
>             DUID   IA    RTA   ORO  Pref  Time Client Server DSTM  DSTM
>                                                                  Forw. Forw.  Addr    Tunn
> Solicit      *     *       *       *
> Advert.     *     *       *                *        *                           *         *
> Request  *     *        *       *
> Confirm   *     *        *       *
> Renew    *     *        *       *
> Rebind    *     *        *       *
> Decline   *     *        *       *
> Release  *     *        *       *
> Reply      *     *        *                *         *                           *        *
> Reconf.   *                       *
> Inform.    *                       *
> R-forw.                                                        *         *
> R-repl.                                                         *         *
> 
> section C.1 at page 14 in draft-ietf-ngtrans-dstm-05.txt describes as followings:
>   "This option can be used with the DHCPv6 Request, Reply, and
>    Reconfigure- Init Messages for cases where a DHCPv6 Server wants to
>    assign to clients IPv4-Mapped IPv6 Addresses, thru the Option Request
>    Option (ORO) in DHCPv6."
> 
> Question 2 : 
> In general IPv4 networks, every host has its default IPv4 gateway address information. 
> if so, does client need to have a IPv4 default gateway address information to have IPv4 communications
> in DSTM environments? 
> 
> if so, How does DHCPv6 server inform the client of IPv4 default gateway address?
> 
> if it doesn't have to send IPv4 default gateway address to client, Why is it?
> 
> Question 3 : 
> 
> In this case that 
>                  client reboots,
>                  client is physically disconnected from a wired connection,
>                  client returns from sleep mode,
>                  client using a wireless technology changes access points,
> I think client may send confirm message with multiple options to confirm configuration parameters. 
> But, why client sends confirm messages with only ORO option except for IA option?
> For example, why doesn¡¯t confirm message include DNS option to confirm DNS Server Address?
> 
> It would be appreciated very much if you would kindly reply to me at your earliest convenience for our questions.
> 
> email : [email-masked]
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

---

From: Jim Bound <[email-masked]>
Date: Sun, 13 Jan 2002 01:20:00 -0500 (EST)

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).

>    other information about the IAs to the client in IA options in a

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

---

From: Jim Bound <[email-masked]>
Date: Sun, 13 Jan 2002 01:26:47 -0500 (EST)

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