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

--
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: Alain Durand <[email-masked]>
Date: Thu, 20 Feb 2003 11:40:26 -0800

From a quick look at the draft:

4. Domain Name Server option

   The Domain Name Server option provides a list of one or more IP
   addresses of DNS servers to which a client's DNS resolver MAY send
   DNS queries [2].  The DNS servers are listed in the order of
   preference for use by the client resolver.

   The format of the Domain Name Server option is:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      OPTION_DNS_SERVERS       |         option-len            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   DNS-server (IP address)                     |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                   DNS-server (IP address)                     |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Are the IP addresses of the DNS servers IPv4 ones or IPv6 ones?
How would the DHCP client knows?
 From the width of the boxes, one could think it it is v4 addresses,
but from the height (4 lines!), one could think it is actually v6 addresses.

My points are:
- the spec is unclear if those addresses are v4 or v6
- it may makes sense to actually mix both type in an announcement,
   for example say: try this v6 address, if it does not work, try this 
v4 one.
   Then each DNS server entry should have both the actual address and 
its family.

    - Alain.

Ralph Droms wrote:

> 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.
>
> --------------------------------------------------------------------
> 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: Ralph Droms <[email-masked]>
Date: Thu, 20 Feb 2003 15:03:44 -0500

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

- Ralph

At 11:40 AM 2/20/2003 -0800, Alain Durand wrote:
>   for example say: try this v6 address, if it does not work, try this v4 one.
>   Then each DNS server entry should have both the actual address and its 
> family.
>
>    - Alain.
>
>
>Ralph Droms wrote:
>
>>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.
>>
>>-----
>>
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 20 Feb 2003 13:17:26 -0700

I thought I had said that I thought it should go ahead, but maybe not 
explicitly.   I would like to see this draft advance.

---

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.

---

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

[ post by non-subscriber.  with the massive amount of spam, it is easy to miss
  and therefore delete posts by non-subscribers.  if you wish to regularly
  post from an address that is not subscribed to this mailing list, send a
  message to <listname>[email-masked] and ask to have the alternate
  address added to the list of addresses from which submissions are
  automatically accepted. ]

> > 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: Alain Durand <[email-masked]>
Date: Thu, 20 Feb 2003 22:39:29 -0800

> So, I think clarifying the scope to do only IPv6 seems like the best

Some may scream at this idea, but couldn't we pass an IPv4-mapped 
address
in there? The DHCPv6 client could recognize this special format
to mean this is actually a v4 address?

> latest query take precedence.  I don't see a problem here, myself.

Unpredictable behavior. Difficult to debug.

	 - Alain.

---

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

On Thu, 20 Feb 2003, Alain Durand wrote:
> Some may scream at this idea, but couldn't we pass an IPv4-mapped address

That is certainly an idea, but I don't like passing around mapped
addresses if it can be avoided.  Anything which requires special code in
DHCPv6 seems like a bad idea.  Of course, if the mapped address is pushed
in your /etc/resolv.conf and your resolver understands that....

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 21 Feb 2003 21:19:00 +0900

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

> support for advancing the document.

Just as a note: I believe I presented a positive recommendation for
advancement.

(But it would better to revise the document once to address issues
raised during the last call period.)

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Fri, 21 Feb 2003 07:56:20 -0500

Regarding unpredictable, difficult to debug behavior (see end of quoted 
text)...

Shouldn't the host receive the same answer to a DNS query, regardless of 
the resolver to which the query is sent?  If so, the order in which 
resolvers are used by the host shouldn't matter.

What is done today in the deployed IPv6 world in a host that has both an 
IPv6 stack and an IPv4 stack, and a manually configured list of DNS 
resolvers?  Is it allowed to mix together IPv6 and IPv4 addresses for 
resolvers?  Is that configuration actually used?  Does the host have two 
lists: one for IPv6 and one for IPv4?

Suppose the host only has an IPv6 stack but both IPv6 and IPv4 addresses in 
its list of DNS resolvers?

I'm hoping we can get some real-world deployment experience injected into 
the conversation...

- Ralph

---

From: Robert Elz <[email-masked]>
Date: Fri, 21 Feb 2003 20:56:12 +0700

Date:        Fri, 21 Feb 2003 07:56:20 -0500
    From:        Ralph Droms <[email-masked]>
    Message-ID:  <[email-masked]>

  | Shouldn't the host receive the same answer to a DNS query, regardless of 
  | the resolver to which the query is sent?  If so, the order in which 
  | resolvers are used by the host shouldn't matter.

It shouldn't matter to the answer (but those who insist on shoving 2faced
DNS implementations down everyone's throats can cause problems).

It can matter to the workability - often the first resolver listed is
the one that should be used, the others are there for backup purposes
only, and won't necessarily respond as quickly (they may have smaller
cache capacity, slower net links, slower CPU, ...).

All this is fine as a backup when the primary resolver happens to be
broken, but you wouldn't want to be using it just because you happened
to pick the wrong address from a list.

  | What is done today in the deployed IPv6 world in a host that has both an 
  | IPv6 stack and an IPv4 stack, and a manually configured list of DNS 
  | resolvers?

Just about everyone uses IPv4 alone for their resolvers.

  | Is it allowed to mix together IPv6 and IPv4 addresses for resolvers?

Allowed, yes, of course, nothing disallows it.

  | Is that configuration actually used?

Probably not at the minute.

  | Does the host have two lists: one for IPv6 and one for IPv4?

This would make no sense.   The host (or application in most cases)
has one resolver (stub).  When called, all that exists is a domain name,
there's no particular v4 or v6 preference.  The resolver stub needs to
contact its back end resolver to resolve the address, whether v4 or v6
is used for this will depend entirely upon what addresses have been
configured for the back end resolver (cache).  It certainly isn't
influenced by the nature of the query, or by what use is intended
for the results of the query.

  | Suppose the host only has an IPv6 stack but both IPv6 and IPv4 addresses in 
  | its list of DNS resolvers?

The v4 address would be useless, just like any other (patently) bogus
address that is configured.   Ignoring that one would be easy.

  | I'm hoping we can get some real-world deployment experience injected into 
  | the conversation...

Since just about no-one is using v6 in their stub resolvers (just a few
who will no doubt now speak up...) this might be difficult.

On the issue - I think having just v6 addresses in the DHCPv6 option is
fine.

How the host actually mixes addresses it gets from DHCPv6 and DHCPv4, and
other mechanisms is an interesting problem to which we don't yet have
any real answers.   This is an area where we probably should just say
nothing, and wait to see how implementations actually react.

But rather than mixing v6 & v4 addresses in one response (as you imply, v6
addresses are no use to a node with only v4, and v4 addresses no use to
a node with only v6) it might be better to explicitly add a "priority of
this DNS cache" field along with each address.  This allows the implicit
"this one is better than that one" based upon ordering to be done away with.
What's more, if we were to pick a middling well known priority that would
implicitly be applied to addresses in a v4 response it also allows v6 to
be placed before, or after, v4 addresses in nodes that support both (or
even some before, and some after).   It doesn't allow v4 addresses to be
ranked other than by their implicit ordering, nor for v6 addresses to be
inserted in the middle of the v4 list, but we can't have everything (and
I doubt anyone wants to go changing the v4 DNS cache list option now).

kre

---

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: Alain Durand <[email-masked]>
Date: Fri, 21 Feb 2003 12:15:41 -0800

On Friday, February 21, 2003, at 04:56  AM, Ralph Droms wrote:

> Regarding unpredictable, difficult to debug behavior (see end of 
> quoted text)...
>
> Shouldn't the host receive the same answer to a DNS query, regardless 
> of the resolver to which the query is sent?  If so, the order in which 

There might be performance/security issues.

>
> What is done today in the deployed IPv6 world in a host that has both 
> an IPv6 stack and an IPv4 stack, and a manually configured list of DNS 
> resolvers?

Yes, in /etc/resolv.conf

>  Is that configuration actually used?

Yes

> Does the host have two lists: one for IPv6 and one for IPv4?

No, one list which include either v4 or v6 addreses
>
> Suppose the host only has an IPv6 stack but both IPv6 and IPv4 
> addresses in its list of DNS resolvers?

then obviously it should ignore the v4 one, the same way a v4-only host
should ignore AAAA records.

> I'm hoping we can get some real-world deployment experience injected 
> into the conversation...
>
> - Ralph

---

From: Mika Liljeberg <[email-masked]>
Date: 22 Feb 2003 12:48:27 +0200

> So, I think clarifying the scope to do only IPv6 seems like the best 

Is that necessary? IPv4 addresses can be returned in IPv4 Mapped format
if necessary. Just add some text explaining this. With our hybrid
IPv4/IPv6 stack implementation this would work out of the box.

	MikaL

---

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

> support for advancing the document.

I would like to see this specification move forward.

	MikaL

---

From: Ralph Droms <[email-masked]>
Date: Mon, 24 Feb 2003 12:43:06 -0500

Summary of discussion during WG last call on 
draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt

Pekka Savola, Tony Lindstrom, Bernie Volz and Peter Koch all responded with 
editorial suggestions.  These suggestions have been incorporated into the 
draft and will appear in next published rev.

Peter Koch and Rob Austein commented on the "Security Considerations"; 
specifically, whether DNSSEC can prevent problems caused by a search list 
supplied as part of an attack by a DHCP server.  Based on Rob's argument 
(and assuming I understood Rob correctly) that DNSSEC can guarantee that a 
host can trust the replies it receives, but DNSSEC can't guarantee that the 
host has asked the right question based on its search list, I'm inclined to 
leave the text in question unchanged.

Alain Durand raised the issue of supplying both IPv4 and IPv6 addresses for 
DNS resolvers in the DNS server option.  I judged the rough consensus in 
the responses to be that restricting the DNS server option to return only 
IPv6 addresses is acceptable.

- Ralph

---

From: David Terrell <[email-masked]>
Date: Tue, 25 Feb 2003 16:42:13 -0600

> IPv4/IPv6 stack implementation this would work out of the box.

Did I miss some announcement that mapped addresses were suddenly
allowed to be present on the wire?  They were supposed to be only
used in the socket API.

Camels... tents....

-- 
David Terrell             | "War is peace, 
Prime Minister, Nebcorp   | freedom is slavery, 
[email-masked]              | ignorance is strength 
http://wwn.nebcorp.com/   | Dishes are clean." - Chris Fester