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
- RE: [dhcwg] Questions about DHCPv6 draft 22 to su… Bernie Volz (EUD)
- RE: [dhcwg] Questions about DHCPv6 draft 22 to su… Jim Bound
- RE: [dhcwg] Questions about DHCPv6 draft 22 to su… Bernie Volz (EUD)
- RE: [dhcwg] Questions about DHCPv6 draft 22 to su… Jim Bound
- Re: (ngtrans) RE: [dhcwg] Questions about DHCPv6 … Jim Bound