RE: [dhcwg] dhcpv6 'zone suffix' option

"Bernie Volz" <volz@cisco.com> Tue, 16 November 2004 15: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 KAA07586; Tue, 16 Nov 2004 10:20:59 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4w6-00054m-Lj; Tue, 16 Nov 2004 10:08:02 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4rr-0002vW-6s for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 10:03:40 -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 KAA04990 for <dhcwg@ietf.org>; Tue, 16 Nov 2004 10:03:37 -0500 (EST)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4u3-0007Tt-BL for dhcwg@ietf.org; Tue, 16 Nov 2004 10:05:57 -0500
Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 07:16:03 -0800
Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAGF30Ox019938; Tue, 16 Nov 2004 07:03:01 -0800 (PST)
Received: from volzw2k ([161.44.65.122]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANB50827; Tue, 16 Nov 2004 10:02:58 -0500 (EST)
From: Bernie Volz <volz@cisco.com>
To: 'CTO YAN Renxiang' <Renxiang.Yan@alcatel-sbell.com.cn>, Ted.Lemon@nominum.com, mjs@cisco.com
Subject: RE: [dhcwg] dhcpv6 'zone suffix' option
Date: Tue, 16 Nov 2004 10:02:58 -0500
Organization: Cisco
Message-ID: <000201c4cbed$5cab89d0$7a412ca1@amer.cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: quoted-printable
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
In-Reply-To: <8634B809B90D6E4AACA4AB0562A1F07205EDD9@bellnet-mail3.sbell.com.cn>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
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

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