Subject: WG last call on draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

From: Ralph Droms <[email-masked]>
Date: Thu, 20 Feb 2003 13:56:59 -0500

Reminder and note: there have been a few responses to this WG last call, 
but no explicit positive recommendations for advancement.  Please review 
draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt and reply with comments.  If you 
recommend the document for advancement without revision, please respond 
with a quick acknowledgment.  No response will be interpreted as a lack of 
support for advancing the document.

-----

This message announces a WG last call on "DNS Configuration options for 
DHCPv6" <draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt>.  The last call will 
conclude on Friday, 2/21.

Note that this is a parallel WG last call in the dhc, ipv6 and dnsext WGs.

draft-ietf-dhc-dhcpv6 opt-dnsconfig-02.txt describes two options for 
DHCPv6: the Domain Name Server option and the Domain Search List 
option.  This document is being considered for Proposed Standard as an 
extension to the base DHCPv6 specification, and is available as 
http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

- Ralph Droms

---

From: Alain Durand <[email-masked]>
Date: Thu, 20 Feb 2003 16:10:44 -0800

On Thursday, February 20, 2003, at 12:03  PM, Ralph Droms wrote:

> Alain,
>
> If it's unclear, then we should edit the document to explicitly 
> identify the addresses as IPv6 addresses.
>
> This option is intended to return IPv6 configuration information.  
> IPv4 addresses for DNS resolvers should be provided through DHCPv4...

??? Why so?
This would be the equivalent to say: "If queried using IPv6, DNS will 
return AAAA
and if queried using IPv4, it will return A".

Now, let's say that this is the case for DHCP,
what should a node that act both as a DHCPv4 and DHCPv6 client do
when it will be returned two lists of recursive DNS serves, one IPv4 
via DHCPv4
and one IPv6 via DHCPv6. Which one should take priority?

	- Alain.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Fri, 21 Feb 2003 08:25:57 +0200 (EET)

> > IPv4 addresses for DNS resolvers should be provided through DHCPv4...

I symphatize with this -- there are some uses to have DHCPv6 return IPv4
addresses too -- but the result would just make the dnsconfig option more
complex for little benefit.  Let's face it: if you deploy DHCPv6, you
really should have long since deployed IPv6-enabled nameservers too.

So, I think clarifying the scope to do only IPv6 seems like the best 
option by far.
 
> Now, let's say that this is the case for DHCP, what should a node that
> act both as a DHCPv4 and DHCPv6 client do when it will be returned two
> lists of recursive DNS serves, one IPv4 via DHCPv4 and one IPv6 via
> DHCPv6. Which one should take priority?

Implementation decision, but I guess typically the results of the 
latest query take precedence.  I don't see a problem here, myself.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Feb 2003 10:48:44 -0700

I'm not sure why you would have a deployed DHCPv6 server and not deploy 
a DNS resolver that listens to requests on an IPv6 socket.   Can 
anybody give a rationale for this?   Has anybody done this?   Was it a 
problem?

In principle, there is nothing that would prevent you from configuring 
your DHCPv6 server to return an encapsulated IPv4 address, but as 
various people have said, this might produce a not-useful result.

I think that the idea of having a DNS resolver priority list is a 
reasonable answer to the problem of "what do we do if we have both IPv4 
and IPv6 addresses for resolvers," but I also think that it's a 
complicated answer, and I do not believe that the problem it solves is 
a compelling one.   It adds significant special-case code to the DHCP 
client, and I don't think it produces a useful benefit.

---

From: Rob Austein <[email-masked]>
Date: Fri, 21 Feb 2003 20:39:30 -0500

In response to the main question: I've read the draft, the option
looks looks reasonable to me (subject to the discussion that has
already taken place during this last call, I'm not disagreeing with
any of that), and I think it'd be useful for this draft to advance.

The rest of this message is on one specific point:

At Thu, 20 Feb 2003 14:55:11 -0500, Ralph Droms wrote:
> At 08:27 PM 2/10/2003 +0100, Peter Koch wrote:
> 
> >Apart from the sad fact that DNSSEC isn't yet deployed I don't see why it
> >wouldn't be able to detect spoofing. If, however, you want to say that
> >using domain names in the search list you don't control is a dangerous
> >thing, that could be emphazised by a reference to RFC 1535.
> 
> The idea here (note that I'm not a DNSSEC expert, either) is that
> a search list that the host doesn't control might still pass DNSSEC
> authentication while yielding unexpected results.
> 
> I would be happy to hear that DNSSEC can prevent the problem and would
> be willing to follow your suggestion and replace the reference to
> DNSSEC with a more general reference to untrusted search lists.

DNSSEC could let you figure out whether the data you got back was
signed by an entity which you trust.  The difficulty with search
paths, is that you're also trusting the search path to tell you what
question you should be asking.  So DNSSEC could let you figure out
whether the random question that your search path just told you to ask
was answered with data signed by an entity which you trust, but it's
not going to help you figure out whether that was the right question.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 13:17:44 +0200

On Sat, 2003-02-22 at 13:13, Pekka Savola wrote:
> IMO, we should just say "IPv6 addresses" (the critical thing here is the
> size of the address -- no checks are done to validate them!), and nothing
> about mapped addresses.
> 
> If some want to push mapped addresses in there, that's fine by me -- if 
> your DNS resolver supports mapped addresses in /etc/resolv.conf (or 
> equivalent).
> 
> No special code/text, is my opinion!

That's good. I agree.

	MikaL

---

From: Bill Manning <[email-masked]>
Date: Sat, 22 Feb 2003 04:54:00 -0800 (PST)

regarding the use of mapped addresses:

draft-cmetz-v6ops-v4mapped-api-harmful-00.txt

might be a useful ID to review before committing this draft to the
stds process.

--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Sun, 23 Feb 2003 18:09:37 +0200

Hi all!

Even though I find standardizing "stateless DNS discovery" in the IPv6 wg very important, I find this DHCPv6 option useful. So I also support moving it forward.

 Juha Wiljakka