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

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Mon, 12 Dec 2005 21:45:27 -0500

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.

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.

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

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Dec 2005 20:55:41 -0700

> been keen about this in the past.

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 13 Dec 2005 12:09:09 +0100

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.

   I guess one could argue that the device might have many TSIG keys
   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: Francis Dupont <[email-masked]>
Date: Tue, 13 Dec 2005 12:16:58 +0100

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.

=> this is not true because the highly recommended binding between
the FQDN and the client authentication is the job of the server *only*.
   
   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.
   
=> I vote for this last suggestion! (keep the can of worms closed)

Regards