Re: [dhcwg] dhcpv6 'zone suffix' option

Joe Quanaim <jdq@lucent.com> Wed, 17 November 2004 18:20 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26853; Wed, 17 Nov 2004 13:20:19 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUUMc-0001lq-Jg; Wed, 17 Nov 2004 13:17:06 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUUGr-0000OB-Td for dhcwg@megatron.ietf.org; Wed, 17 Nov 2004 13:11:10 -0500
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26166 for <dhcwg@ietf.org>; Wed, 17 Nov 2004 13:11:06 -0500 (EST)
Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUUJH-00084k-CR for dhcwg@ietf.org; Wed, 17 Nov 2004 13:13:42 -0500
Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAHIAwY2025192; Wed, 17 Nov 2004 12:10:59 -0600 (CST)
Received: from kraken by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iAHIAv213309; Wed, 17 Nov 2004 13:10:57 -0500 (EST)
From: Joe Quanaim <jdq@lucent.com>
To: CTO YAN Renxiang <Renxiang.Yan@alcatel-sbell.com.cn>, dhcwg@ietf.org
Subject: Re: [dhcwg] dhcpv6 'zone suffix' option
Date: Wed, 17 Nov 2004 13:10:58 -0500
User-Agent: KMail/1.7.1
References: <8634B809B90D6E4AACA4AB0562A1F07205EDD9@bellnet-mail3.sbell.com.cn>
In-Reply-To: <8634B809B90D6E4AACA4AB0562A1F07205EDD9@bellnet-mail3.sbell.com.cn>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <200411171310.58201.jdq@lucent.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Content-Transfer-Encoding: quoted-printable
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: jdq@lucent.com
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Content-Transfer-Encoding: quoted-printable

As others have stated, I would prefer using a new option rather than trying to 
overload the fqdn option.

CTO YAN Renxiang wrote:
> For my draft <draft-yan-dhc-dhcpv6-opt-dnszone-01.txt>, the idea behind is
> rather simple. It's arised when I try to identify a solution to perform DNS
> auto-registration in IPv6 access network.  and I believe is can also be
> used in other cases, e.g. DNS update in stateless configuration. Please
> give me comments, to move this work forward.

Some comments follow.  I was not at the wg meeting, so I apologize if I am 
repeating something.

   Currently, there exist several methods to register domain name for
   an IPv6 terminal: (1) manually add the DNS resource record into DNS
   server database; (2) use FQDN option and register domain name
   automatically either by DHCP client or by DHCP server [6];
   (3) configure a DNS zone suffix information in the router, and use
   the RA-based DNS auto-registration mechanism [5].

   Method (1) is not effective for large number of IPv6 devices. Method
   (3) requires that the every terminal get the address and FQDN using
   DHCP mechanism. Thus every terminal needs a DHCP client. Method (2)
   will only be suitable in the case where a router is presented in the
   network, and the DNS zone suffix has been configured correctly.

jdq> I believe these references are incorrect.  This paragraph refers to 
method 1, 2, and then 3, but it denotes 1, 3, and 2.

   DNS zone suffix: A string of DNS zone suffix. It is comprised of a
   sequence of labels, where each label consists of a length octet
   followed by that number of octets. The suffix terminates with the
   zero length octet for the null label of the root. This field should
   be padded with zeroes to be the multiple of 8 octets.

jdq> Is it necessary for this field to be a multiple of 8 octets?  Also, it is 
probably better to refer to rfc 3315 than to summarize the dns encoding.  
This is done in rfc 3646.

   The above figure shows a typical usage of the option. In this model,
   ISP has the ISP level domain name suffix (e.g. shtele.com)  The
   procedure may follow as:

jdq> It might be simpler to refer to example.com.

   [5]  Jae-Hoon, J., Byung-Yeob, K., Jung-Soo, P. and Hyong-Jun K.,
        "IPv6 Router Advertisement based DNS Autocofiguration", draft-
        jeong-ipv6-ra-dns-autoconf-00.txt, 17 April, 2003.

jdq> This draft is no longer available on the ietf site.  Revision 01 is left 
as a placeholder saying it has been expired.

   [6]  M.Stapp, Y. Rekhter, "The DHCPv6 Client FQDN Option", draft-
        volz-dhc-dhcpv6-fqdn-00.txt, July, 2004.

jdq> I believe draft-ietf-dhc-dhcpv6-fqdn-00.txt superceded this draft.


Thanks,
Joe.


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