Subject: RE: [dhcwg] dhcpv6 'zone suffix' option

From: "CTO YAN Renxiang" <[email-masked]>
Date: Wed, 17 Nov 2004 11:25:19 +0800

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:[email-masked]]
发送时间: 2004年11月16日 23:03
收件人: CTO YAN Renxiang; [email-masked]; [email-masked]
抄送: [email-masked]
主题: 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:[email-masked]] 
> Sent: Tuesday, November 16, 2004 2:58 AM
> To: [email-masked]; Bernie Volz; [email-masked]
> Cc: [email-masked]
> 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
> 
> -----原始邮件-----
> 发件人: [email-masked] [mailto:[email-masked]]代表
> Bernie Volz
> 发送时间: 2004年11月11日 2:40
> 收件人: 'Ted Lemon'; [email-masked]
> 主题: 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: [email-masked] [mailto:[email-masked]]
> > On Behalf Of Ted Lemon
> > Sent: Wednesday, November 10, 2004 1:21 PM
> > To: <[email-masked]> <[email-masked]>
> > 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/dhcwg
> > 
> 
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "CTO YAN Renxiang" <[email-masked]>
Date: Thu, 18 Nov 2004 08:55:08 +0800

> From: Joe Quanaim [mailto:[email-masked]]
> Send: 2004/11/18 2:11
> To: CTO YAN Renxiang; [email-masked]
> As others have stated, I would prefer using a new option 
> rather than trying to overload the fqdn option.

Yes, as I stated before, using a new option are simple and clean, without adding
complexity to FQDN option.

> CTO YAN Renxiang wrote:
> 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
> 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.

It is a typo, I have revised it in the -02 version. Thanks for your mention anyway.

> 
>    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.

Yes, you are correct, I will make revision in the -02 version. 

Thank you!

-Renxiang