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

From: Jim Bound <[email-masked]>
Date: Sat, 12 Jan 2002 01:43:46 -0500 (EST)

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
>