Subject: [dhcwg] (no subject)

From: "CTO YAN Renxiang" <[email-masked]>
Date: Wed, 14 Jul 2004 11:00:45 +0800

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:[email-masked]]
发送时间: 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:[email-masked]]
> 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:[email-masked]]
> 发送时间: 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:[email-masked]]
> > Sent: Sunday, July 11, 2004 11:35 PM
> > To: [email-masked]
> > 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 13 Jul 2004 23:19:07 -0400

Why?

The DHCP server will return the fully qualified domain name for each address
to the client (if appropriate). With this and if you know the how to reach a
DNS server, you can find out where the zone cut is. Ask for NS RRs with the
fully qualified domain name; if that doesn't return any, remove the first
component (ie, for a.b.test.com, remove a) and try the resulting domain ...
Keep going until you find the NS records or you run out of domain names. If
you find NS records, try the updates to the one or more servers.

Nothing more needed.

Now, agreed, that if the DHCP server doesn't return the Client FQDN option
for a address, then the DHCP client will need something for it to use. And,
lacking anything else, using the DNS search list probably isn't that bad an
idea.

- Bernie

> Sent: Tuesday, July 13, 2004 11:01 PM
> To: [email-masked]
> Cc: [email-masked]
> 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.
> 
> "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-d
> nszone-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.
> 
> 
> -----原始邮件-----
> 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
> 
> (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
> >
> > -----原始邮件-----
> > 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.
> >
> > > 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
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Jul 2004 08:24:37 -0700

Given that this is in last call, I'm going to weigh in here too.   I 
think that Bernie's solution to the problem Mr. Yan brings up is the 
right one.   It requires no change to the draft, and more importantly, 
it provides a reliable mechanism, whereas, as Mark points out, the 
DHCPREQUEST message isn't reliable, and might get an unwished-for 
answer.

So please let's advance the draft is, without the proposed change.