RE: [dhcwg] dhcpv6 'zone suffix' option

"CTO YAN Renxiang" <Renxiang.Yan@alcatel-sbell.com.cn> Wed, 17 November 2004 03:35 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 WAA01137; Tue, 16 Nov 2004 22:35:53 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUGWA-0002RW-4f; Tue, 16 Nov 2004 22:30:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUGTo-0001pX-RO for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 22:27:37 -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 WAA00582 for <dhcwg@ietf.org>; Tue, 16 Nov 2004 22:27:35 -0500 (EST)
Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUGVp-0004Ed-VT for dhcwg@ietf.org; Tue, 16 Nov 2004 22:30:01 -0500
Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id iAH3LKhi029101 for <dhcwg@ietf.org>; Wed, 17 Nov 2004 11:21:46 +0800 (CST)
Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Wed Nov 17 11:25:21 2004 +0800
Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Nov 2004 11:25:20 +0800
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0
Subject: RE: [dhcwg] dhcpv6 'zone suffix' option
Date: Wed, 17 Nov 2004 11:25:19 +0800
Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205EDDA@bellnet-mail3.sbell.com.cn>
Thread-Topic: [dhcwg] dhcpv6 'zone suffix' option
Thread-Index: AcTL89XALObrWZa+SNKKM8Hc3gpJbQAT/fmA
From: CTO YAN Renxiang <Renxiang.Yan@alcatel-sbell.com.cn>
To: Bernie Volz <volz@cisco.com>, Ted.Lemon@nominum.com, mjs@cisco.com
X-OriginalArrivalTime: 17 Nov 2004 03:25:20.0431 (UTC) FILETIME=[111853F0:01C4CC55]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250
Content-Transfer-Encoding: quoted-printable
Cc: dhcwg@ietf.org
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Bernie,

I agree with you.  including FQDN in IA_PD option seems unmeaningful. 
I prefer using these two option is the following way, just a summary:

In stateful DHCP:
1. Prefix delegation: use IA_PD+ zone suffix option;
2. Unique address allocation: use IA_NA(IA_TA) + FQDN (or zone suffix option),

I'll revise the draft according to above items, in addition, a seperation section will
be include the draft to mention the interaction with FQDN option.

-Renxiang


-----原始邮件-----
发件人: Bernie Volz [mailto:volz@cisco.com]
发送时间: 2004年11月16日 23:03
收件人: CTO YAN Renxiang; Ted.Lemon@nominum.com; mjs@cisco.com
抄送: dhcwg@ietf.org
主题: RE: [dhcwg] dhcpv6 'zone suffix' option


Hi:

At present, the
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-00.txt draft
states:

   The Client FQDN option MUST only appear in IA_NA-options and
   IA_TA-options (see [12]) fields and applies to all addresses for that
   binding.

So, technically it can not be used with the IA_PD. We could relax this
requirement, but I'm not sure of the usage model for this situation. Is the
FQDN in the IA_PD supposed to represent the FQDN for the prefix(es) or is it
supposed to be used as the Domain Name suffix by the router?

Personally I see no issue in using a separate option for communicating a
domain name suffix that is supposed to be used by clients (IA_PD or
IA_NA/IA_TA) for DNS if the clients are to do the DNS updates themselves and
assumed to have appropriate security information to do so. I just think we
should be clear as to how the FQDN and the Domain Name suffix options are to
work and interact. I think restricting each IA_* option to contain only ONE
of these is appropriate.

An IA_NA and IA_TA? MUST contain neither option or just one of the options.
An IA_PD must not contain a FQDN option.

If the domain name suffix option is present, the client should use this
option to construct its own FQDN and perform DNS updates as required. If the
FQDN option is present, the client should use that name and perform DNS
updates as required in
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-00.txt.

- Bernie

> -----Original Message-----
> From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn] 
> Sent: Tuesday, November 16, 2004 2:58 AM
> To: Ted.Lemon@nominum.com; Bernie Volz; mjs@cisco.com
> Cc: dhcwg@ietf.org
> Subject: re: [dhcwg] dhcpv6 'zone suffix' option
> 
> 
> Let me conclude this discussion first.
> 
> 1. location of the FQDN option:
>   Location1: IA_* option
>      Bernie's preference. I also agree. This will reduce the 
> confusion, and...very clear.
>   Location2: message option
>      It isn't clear as to which addresses (or prefixes) it applies to.
>   Location3: IA_ADDR option
>      This will complicates the client and server processing code.
> 
>   Bernie: could you explain whether FQDN can be using in 
> IA_PD option? You mentioned this in the last mail, but I 
> cannot find the explicit explanation in your draft. 
> 
> 2. the method to transfer DNS zone suffix:
>   Method1: Adding a flag in FQDN option
>      This will complicate the FQDN option, and may make the 
> option messy. 
>   Method2: using a seperate option. 
>       Simple and clear,  it also benefits the case for 
> putting the FQDN in the IA_* option. It seems we reach this 
> consense after the discussion.
> 
> 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.
> 
> -Renxiang Yan
> 
> -----原始邮件-----
> 发件人: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]代表
> Bernie Volz
> 发送时间: 2004年11月11日 2:40
> 收件人: 'Ted Lemon'; dhcwg@ietf.org
> 主题: RE: [dhcwg] dhcpv6 'zone suffix' option
> 
> 
> Fine by me. I'll double check but I don't believe that I 
> mentioned stateful in the current draft.
> 
> > -----Original Message-----
> > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]
> > On Behalf Of Ted Lemon
> > Sent: Wednesday, November 10, 2004 1:21 PM
> > To: <dhcwg@ietf.org> <dhcwg@ietf.org>
> > Subject: Re: [dhcwg] dhcpv6 'zone suffix' option
> > 
> > 
> > On Nov 10, 2004, at 10:13 AM, Bernie Volz wrote:
> > > By putting it in the IA_* options, we're restricting it 
> to stateful 
> > > (PD or
> > > NA) but I don't think that's an issue (especially if we
> > don't use it to
> > > communicate the zone name).
> > 
> > I would encourage you not to put any language in the draft that 
> > explicitly refers to stateful versus not stateful.   I think it's 
> > likely that we will want to support dynamic DNS updates with the 
> > Information Request message using the FQDN option.   In this 
> > case, the
> > client would have to send an IA option, in order to identify 
> > it for the 
> > purposes of doing the DNS update.   So if you don't explicitly say 
> > anything about stateful vs. non-stateful, we don't need to 
> > update your 
> > draft when we write a draft explaining how to do updates with 
> > stateless 
> > DHCPv6.
> > 
> > 
> > _______________________________________________
> > 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
> 


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