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

Jim Bound <seamus@bit-net.com> Sat, 12 January 2002 06:55 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09417 for <dhcwg-archive@odin.ietf.org>; Sat, 12 Jan 2002 01:55:27 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA09338 for dhcwg-archive@odin.ietf.org; Sat, 12 Jan 2002 01:55:28 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09246; Sat, 12 Jan 2002 01:44:08 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09221 for <dhcwg@optimus.ietf.org>; Sat, 12 Jan 2002 01:44:05 -0500 (EST)
Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09281 for <dhcwg@ietf.org>; Sat, 12 Jan 2002 01:43:57 -0500 (EST)
Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AA00274; Sat, 12 Jan 2002 01:43:46 -0500
Date: Sat, 12 Jan 2002 01:43:46 -0500
From: Jim Bound <seamus@bit-net.com>
To: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
Cc: '???' <hclee@i2soft.net>, ngtans???? <ngtrans@sunroof.eng.sun.com>, DHCP???? <dhcwg@ietf.org>
Subject: RE: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM envir onments
In-Reply-To: <66F66129A77AD411B76200508B65AC69B4CD67@EAMBUNT705>
Message-Id: <Pine.OSF.3.95.1020112013905.29924A-100000@www.bit-net.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by optimus.ietf.org id BAA09222
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 8bit

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: hclee@i2soft.net [mailto:hclee@i2soft.net]
> 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 : hclee@i2soft.net
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg