Subject: [dhcwg] dhc WG last call on "Domain Suffix Option for DHCPv6"

From: Stig Venaas <[email-masked]>
Date: Mon, 5 Dec 2005 15:04:33 +0100

This message announces a WG last call on "Domain Suffix Option for
DHCPv6" <draft-ietf-dhc-dhcpv6-opt-dnsdomain-00.txt>.  The last call
will conclude at 1700 ET on 2005-12-19.

Please respond to this WG last call.  If you support acceptance of the
document without change, respond with a simple acknowledgment, so that
support for the document can be assessed.  Lack of discussion does not
represent positive support.  If there is no expression of support for
acceptance during the WG last call, the document will not be advanced
to the IESG.

"Domain Suffix Option for DHCPv6" specifies an option passed from
server to client to specify a domain suffix name to be used for
domain name updates.  This draft is available as
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsdomain-00.txt

Stig

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

---

From: "CTO YAN Renxiang" <[email-masked]>
Date: Tue, 13 Dec 2005 15:22:34 +0800

> Here are my comments on this draft:
> 
> 1. There is no mention as to whether the client SHOULD (MUST) put the
> "domain suffix" option into the ORO to request that the server send it.
> 
> I think we wanted *ALL* options (other than a small set, such as IA_NA,
> IA_TA, IA_PD) to do this to avoid some of the confusion we've had with
> DHCPv4 and the Parameter Request List option.
> 
> I'm sure Ted will also speak up on this subject since I believe he has
> been keen about this in the past.
> 
> I would like to see that text added.

Ted has said a lot about this, I also prefer to add some text to clarify this point.
But it would be better to make the text consistent to other options. I think SHOULD
is better.

> 2. While this option conveys the domain name suffix, I'm not sure how
> useful this is as most DNS Updates are likely to require some level of
> security (TSIG) and thus whether the goal of the draft can be met is
> questionable. In the introduction, it states:
> 
>    The configured domain suffix name is intended to be used by the IPv6
>    device to perform DNS update for the hosts inside its local network.
> 
> I guess one could argue that the device might have many TSIG keys
> preconfigured for the various domains it is expecting, and when it
> receives the domain suffix, it finds the appropriate key from 
> that list to use? But, this certainly requires additional configuration.

As I clarified in previous mails, this option does not address the DNS update
issues, the method for hosts inside the local network can use FQDN or other 
possible methods to perform DNS update, i.e. in the local DNS server.  
It's used to for the FQDN in the local DHCPv6 server. So I think stating security
issues for DNS update is not suitable.

> Perhaps the security considerations section needs to be revised to
> include this?
> 
> 
> Other than the above comments, I have no other issues with the draft.
> 
> - Bernie
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] 
> > On Behalf Of Stig Venaas
> > Sent: Monday, December 05, 2005 9:05 AM
> > To: [email-masked]
> > Cc: Ralph Droms (rdroms)
> > Subject: [dhcwg] dhc WG last call on "Domain Suffix Option 
> for DHCPv6"
> >

---

From: "CTO YAN Renxiang" <[email-masked]>
Date: Tue, 13 Dec 2005 15:58:34 +0800

On Tuesday 13 December 2005 11:45, Ted Lemon wrote:
> On Monday 12 December 2005 19:45, Bernie Volz (volz) wrote:
> It is important that no RFC describing a DHCPv6 option state 
> that the DHCP server will return the option for any reason other than that 
> that option was requested in the client's ORO.   The language that I 
> commented on earlier does in fact to some extent contradict this, by requiring 
> that the server send the option only in certain circumstances, regardless of 
> whether or not the client has requested it.
> 
> In reality, it would be better to just delete the example section and get rid 
> of the MAYs and MUST NOTs, and simply depend on the client to 
> request the option if it wants it, and to be able to handle it when it 
> appears, wherever that happens to be.
> 
> So to be clear, I am saying that you should delete section 3 
> entirely, and delete paragraph 1 and paragraph 2 Section 2.1, and also 
> delete sentence 2 of paragraph 3 of Section 2.1.
> 
> Also, in section 4, I think you can delete paragraph 2, 3 and 
> 4.   In section 1 you can delete paragraph 3.
 
I suggest to make revision after we make consensus on the usage of the option.
In addition, I am wondering deleting the example may affect the understanding
of the option.  

> I'm sorry for not suggesting this in my previous message - I 
> was trying to keep the changes as small as possible.   But I think there 
> are a lot of words in this document that aren't needed, and I don't think the 
> IESG will advance it with these words in it.
> 
> I'm in favor of this document because I think there are uses 
> for a domain suffix option, just as in DHCPv4.  As Bernie points out, 
> however, there is no  way for the client to authenticate its DNS update.    If it 
> has no prior knowledge of the domain into which it will be making its 
> update, it will not have a TSIG key that it can use to do the update.
> 
> I think that advancing a draft with the changes I've made will allow the 
> people at Shanghai Bell and China Mobile to experiment with 
> the functionality they are trying to develop.   If they figure out a good way 
> to do what they want, then can then write a second draft describing how that 
> works.   But it would be better if this draft simply described the format of 
> the option and didn't specifically suggest using it in a DNS update.

In fact, we are currently working on the solution as indicated in the section 3
of the draft. Using this option, we implement a system to automatically update
domain name in the CPE's DNS server. Also, in NSP's DNS server, a NS record
is added. So every IPv6 devices can be accessed using domain name. I also 
plan to write another draft about how this works. The draft will include the usage
of this options.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 13 Dec 2005 06:36:26 -0500

Hi:

See below. 

- Bernie

> From: CTO YAN Renxiang [mailto:[email-masked]] 
> Sent: Tuesday, December 13, 2005 2:23 AM
> To: Bernie Volz (volz); [email-masked]
> Subject: re: [dhcwg] dhc WG last call on "Domain Suffix 
> Option for DHCPv6"
> 
> 
>  

I missed Ted's comments on this draft. Great that he did and I see that
he responded to my email as well.

> issues for DNS update is not suitable.

Ah, but the draft *DOES* specifically say "DNS update". I quoted some
text in my email from the draft that explicitly mentioned that. Ted has
suggested you remove all references to that and I agree that this would
solve the issue ("But it would be better if this draft simply described
the format of the option and didn't specifically suggest using it in a
DNS update.").

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 13 Dec 2005 06:46:07 -0500

Francis:

I don't believe we really have a similar DHCPv4 option. There is a
domain name option in v4, but that came about before the FQDN option.
And, the DHCPv6 domain search list option replaces that option.

Regarding the reference to TSIG, it was just an example and the one that
I know is in wide deployment. Use whatever you like.

The problem with "the client may ask the server to update DNS" is that
in this model (see the draft), that device is the one getting this
option but it may not have the required security token to perform the
updates. Sure, it could be preconfigured with a token but that means it
may have access to updating more domains than you want.

Anyway, I think by remove "DNS update" from the draft, we resolve this
issue for now.

- Bernie 

> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Tuesday, December 13, 2005 6:09 AM
> To: Bernie Volz (volz)
> Cc: Stig Venaas; [email-masked]; Ralph Droms (rdroms)
> Subject: Re: [dhcwg] dhc WG last call on "Domain Suffix 
> Option for DHCPv6" 
> 
>  In your previous mail you wrote:
> 
>    security (TSIG)
> => RRSIG(0) and IPsec are valid (and for sure better) 
> alternatives to TSIG,
> and of course the client may ask the server to update the AAAA.
> 
>    preconfigured for the various domains it is expecting,
> 
> => but it can have one TSIG key for all domains and expect 
> the DNS server
> to be smart enough to bind the key to the right domain.
> 
> => I don't believe but BTW what the IPv4 counterpart says about this?
> 
> Regards
> 
> [email-masked]
>

---

From: "CTO YAN Renxiang" <[email-masked]>
Date: Wed, 14 Dec 2005 08:47:08 +0800

Hi, Bernie,

> the format of the option and didn't specifically suggest using it in a 
 
The draft DOES give some hint to use the "domain suffix" option, but it's not the
aim of the draft, it can be used in many different ways, I think. Anyway, as Ted said,
it would be better to remove all of the references.  I agree.

---

From: "CTO YAN Renxiang" <[email-masked]>
Date: Fri, 16 Dec 2005 09:58:29 +0800

Hi, Bernie,

Yeah, it's better not to mention DNS update in this draft. In my last mail, I just give a possible way to use it.  In fact, we've implemented it successfully in an IPv6 demonstration network. I believe there exist many other ways to use it.  I will summarize the usa case in our IPv6 demo in another draft.

RGs,
-Renxiang

On Thursday 15 December 2005 01:18, Bernie Volz wrote:

While I think you'd be far wiser to not mention DNS Updates at all, this does weaken the draft because then the question comes up as to why is the option needed?

So, you're in a catch-22 in that if you leave DNS updates in, it is obvious that much about DNS updates is still missing and you need to say "magic happens" or there is no DNS update security OR you have a lot more work to do to figure out how to communicate more information so the updates can happen.

- Bernie

---

From: "CTO YAN Renxiang" <[email-masked]>
Date: Mon, 19 Dec 2005 14:11:38 +0800

Dear All,

I revised the draft based on the discussing result in the mailing list recently.  
As suggested by many people, the "DNS update" was removed. The draft only 
address the definition of the "domain suffix" option, and the usage of this 
option will be defined in a separated draft.

Please review and give comments on it.  I plan to submit it in Dec. 26.

Regards,
-Renxiang