[dhcwg] Questions about DHCPv6 draft 22 to support DSTM environments
이희철 <hclee@i2soft.net> Fri, 11 January 2002 09:03 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 EAA12164 for <dhcwg-archive@odin.ietf.org>; Fri, 11 Jan 2002 04:03:06 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA22267 for dhcwg-archive@odin.ietf.org; Fri, 11 Jan 2002 04:03:08 -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 DAA21617; Fri, 11 Jan 2002 03:51:16 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA21595 for <dhcwg@optimus.ietf.org>; Fri, 11 Jan 2002 03:51:11 -0500 (EST)
Received: from i2soft_web ([211.240.20.130]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA12059 for <dhcwg@ietf.org>; Fri, 11 Jan 2002 03:51:07 -0500 (EST)
Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for <dhcwg@ietf.org> at Fri, 11 Jan 2002 17:53:12 +0900
From: 이희철 <hclee@i2soft.net>
To: ngtans워킹그룹 <ngtrans@sunroof.eng.sun.com>, DHCP워킹그룹 <dhcwg@ietf.org>
Date: Fri, 11 Jan 2002 17:50:14 +0900
Message-ID: <JKEALACDOCEIFIMDPHAICEKICAAA.hclee@i2soft.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="ks_c_5601-1987"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by optimus.ietf.org id DAA21596
Subject: [dhcwg] Questions about DHCPv6 draft 22 to support DSTM environments
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
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