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

From: Alain Durand <[email-masked]>
Date: Thu, 20 Feb 2003 22:39:29 -0800

On Thursday, February 20, 2003, at 10:25  PM, Pekka Savola wrote:

> On Thu, 20 Feb 2003, Alain Durand wrote:
>> On Thursday, February 20, 2003, at 12:03  PM, Ralph Droms wrote:
>>> 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...
>
> 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.

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?

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

Unpredictable behavior. Difficult to debug.

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

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

At 10:39 PM 2/20/2003 -0800, Alain Durand wrote:

>>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
>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: 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: 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: Pekka Savola <[email-masked]>
Date: Sat, 22 Feb 2003 13:13:48 +0200 (EET)

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

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!

---

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