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

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Fri, 11 January 2002 12:43 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 HAA13818 for <dhcwg-archive@odin.ietf.org>; Fri, 11 Jan 2002 07:43:45 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA28188 for dhcwg-archive@odin.ietf.org; Fri, 11 Jan 2002 07:43:47 -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 HAA28052; Fri, 11 Jan 2002 07:37:23 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA28031 for <dhcwg@optimus.ietf.org>; Fri, 11 Jan 2002 07:37:20 -0500 (EST)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13708 for <dhcwg@ietf.org>; Fri, 11 Jan 2002 07:37:17 -0500 (EST)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0BCbIW04479 for <dhcwg@ietf.org>; Fri, 11 Jan 2002 06:37:18 -0600 (CST)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0BCbI914041 for <dhcwg@ietf.org>; Fri, 11 Jan 2002 06:37:18 -0600 (CST)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Fri Jan 11 06:37:18 2002 -0600
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <ZP0QF2FQ>; Fri, 11 Jan 2002 06:37:17 -0600
Message-ID: <66F66129A77AD411B76200508B65AC69B4CD67@EAMBUNT705>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: '???' <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
Date: Fri, 11 Jan 2002 06:37:16 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19A9C.B3FAFA70"
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

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