[dhcwg] (no subject)

Hi, Bernie,

I don't think domain name search list option defined in RFC3646 can transfer the DNS
zone suffix which is used by host to update the FQDN without any modification.

In section4 of RFC3646, it states:
"The Domain Search List option specifies the domain search list the client is to use when
resolving hostnames with DNS."

The initial purpose of domain search list option is hostname resolving, not domain name
update. Furthermore, the domain name listed in the Domain Search List option can be
different from the DNS zone suffix the client needed to update its domain name.

Even if Domain Search List option can be used in domain name update, we have to
define a mechanism to choose a correct domain name from domain search list.

To sum up, two choices exist to make it possible for IPv6 client to dynamically update its domain name:
1. define another option to transfer DNS zone suffix to client, which enables the client generates its FQDN,
as defined in http://www.ietf.org/internet-drafts/draft-yan-dhc-dhcpv6-opt-dnszone-00.txt.
2. define a mechanism to choose a domain name as DNS zone suffix from domain search list,
and use it to generate and update client's FQDN

-Renxiang

P.S. In order to foster a discussion on this topic, I am CCing  this mail to DHC list,
I would be appreciated any value comments from experts in the list.

-----原始邮件-----
发件人: Bernie Volz [mailto:volz@cisco.com]
发送时间: 2004年7月13日 10:38
收件人: CTO YAN Renxiang
主题: RE: about your draft

The Client FQDN option sends the fully qualified domain name. There is no
indication of which is the host portion and which is the domain name. In
general, this really isn't that useful.

In DHCPv6, we already have the domain name search list option (see
http://www.ietf.org/rfc/rfc3646.txt) This is generally much more useful
than just the "domain name" and, in DHCPv4 it is generally the domain name
that is used as the default domain search list.

So, if a client receives the Client FQDN option with a fully qualified
domain name, it can figure out the host name portion by using the domain
search list, if it really cares. Or, it can do DNS lookups.

- Bernie

> -----Original Message-----
> From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn]
> Sent: Monday, July 12, 2004 8:38 PM
> To: Bernie Volz
> Subject: re: about your draft
>
>
> Hi, Bernie,
>
> In DHCPv4, the domain name is tranferred using option 15
> (domain name) defined in 2132. However, DHCPv6 does not
> defined such an option. How does your draft implement? could
> you explain in a bit detail?
>
> regards,
> -renxiang
>
> -----原始邮件-----
> 发件人: Bernie Volz [mailto:volz@cisco.com]
> 发送时间: 2004年7月12日 21:28
> 收件人: CTO YAN Renxiang
> 主题: RE: about your draft
>
>
> Hi:
>
> The draft should appear at the IETF web site shortly.
> Sometimes the announcement preceeds the upload to the web/ftp
> site(s), so give it a day or two and it should appear.
>
> The option is modeled after the DHCPv4 Client FQDN option.
>
> - Bernie
>
> > -----Original Message-----
> > From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn]
> > Sent: Sunday, July 11, 2004 11:35 PM
> > To: volz@cisco.com
> > Subject: about your draft
> >
> >
> > Hi Bernie,
> >
> > I found you will make presentation on 60th IETF meeting about
> > the DHCP FQDN option. I can't find the draft "The DHCPv6
> > Client FQDN Option" on website. Could you send me
> > the link?
> >
> > I wrote a draft  "DNS zone suffix option for DHCPv6" to allow
> > DHCPv6 server transfer the DNS zone suffix to DHCPv6 client.
> > I wonder there will be close relationship between our drafts,
> > so could you tell me how to tranfer the DNS suffix in your draft?
> >
> > Thank you!
> >
> > regards,
> > -Renxiang
> >
> cn 

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