Subject: RE: "RFC 2461bis" issue: DNS configuration

From: Soliman Hesham <[email-masked]>
Date: Thu, 23 Oct 2003 02:46:29 -0400

> I haven't been on this list very long so I'm unaware of the 
 > reasons to 
 > revisit 2461 and I don't know whether the following issue has been 
 > discussed, but:
 > 
 > Why is there no mechanism to learn DNS addresses through router 
 > advertisements?
 > 
 > It is currently possible to attach a host to a link with one or more 
 > IPv6 routers and have the host automatically discover all the 
 > paramaters needed to connect to the IPv6 internet... except DNS 
 > servers.
 > 
 > This is the absolute number one annoyance when running IPv6.

=> A couple of years ago there was a DT that compared several
different ways of achieving this. The proposal you mentioned
was one of those addressed. The DT settled on assigning
3 different site-local addresses that can be reserved for 
DNS servers. The solution was documented in a draft (I believe
Itojun, Alain and Dave Thaler co-authored it). But this idea
didn't get concensus in the WG and I think the draft is dead
now but I'm not sure. DHCPv6 allows for DNS configuration in
hosts among other things.

Hesham

 > 
 > 
 > --------------------------------------------------------------------
 > IETF IPv6 working group mailing list
 > [email-masked]
 > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
 > --------------------------------------------------------------------
 > 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 23 Oct 2003 16:00:52 +0900

Hello Hesham

>DHCPv6 allows for DNS configuration in hosts among other things.

Please don't definitely say that. As I said, RA based DNS discovery
is work in progress.

Regards

Daniel (Soohong Daniel Park)
Mobile Platform Laboratory, SAMSUNG Electronics

---

From: [email-masked] (Jun-ichiro itojun Hagino)
Date: Thu, 23 Oct 2003 16:14:43 +0900 (JST)

> Please don't definitely say that. As I said, RA based DNS discovery

	Hesham's statement does not reject RA-based DNS discovery, it
	seems to me.  there's nothing wrong with the above-quoted line.

itojun

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 23 Oct 2003 09:18:24 +0200

> hosts among other things.

Ok, I only have one word for this: unacceptable.

I stronly suggest everyone who was against this to try running IPv6 for 
a few minutes.

---

From: Soohong Daniel Park <[email-masked]>
Date: Thu, 23 Oct 2003 16:28:00 +0900

Hello itojun

>seems to me.  there's nothing wrong with the above-quoted line.

Yes, I didn't say something was wrong but considered one of
issue.

Regards

---

From: Tim Chown <[email-masked]>
Date: Thu, 23 Oct 2003 08:39:37 +0100

Iljitsch, I agree.  This has been discussed a lot on the dnsop list... 
there is currently no consensus about DHCPv6(Lite) vs RA-based discovery.

It will be interesting to see what the Moonv6 work may have to say in this
area, as the issue I'm sure will have been encountered there.   There are
still very few people working in networks where IPv6 transport DNS lookup
is a requirement, hence this issue has seen slow progress.

I am in the RA camp, but I agree DHCPv6 will be used for other things 
(e.g. NTP server), so in cases where a DHCPv6 server is present it will be 
able to be used for resolver discovery.  But I believe we should have a RA 
based method also.

The general thrust of the DHCPv6 camp argument is that in any situation
where a router is configured to pass DNS info in a RA extension it could
equally be configured to do so using DHCPv6 (Lite), or could forward to
a DHCPv6 server using the DHCPv6 relay agent function.

The second argument used by the DHCPv6 camp is that having two methods may
lead to complexity, and problems in troubleshooting.

The third is a fear of creeping featurism - where is the line over which
you don't step for RA extensions?   DNS resolver?  Search path?  NTP?

But there are some clear advantages for the RA method, like the ability
to multicast the information in a one-way message, where DHCPv6 must always
rely on a client-server exchange.

Both methods have security considerations.

There seem to be a handful DHCPv6 implementations, but no stripped down
DHCPv6 Lite implementations yet (the Lite version not maintaining state
for IP leases etc).

Tim

---

From: Ronald van der Pol <[email-masked]>
Date: Thu, 23 Oct 2003 11:40:29 +0200

> there is currently no consensus about DHCPv6(Lite) vs RA-based discovery.

This keeps popping up and we don't seem to be converging. Just before
reading this thread I contacted some people about trying DHCPv6 on the
MSP IETF network. I have no strong preference (yet) for either DHCPv6
or RA. Let's just give DHCPv6 a try.

What do you think of this idea?

> DHCPv6 Lite implementations yet (the Lite version not maintaining state

I tried KAME's dhcp6[sc]. It seems to work. Don't you consider this a
stripped down DHCPv6 implementation?

The client code is not very big, setup is easy and it even compiles and
works on my MacOSX iBook.

	rvdp

---

From: Tim Chown <[email-masked]>
Date: Thu, 23 Oct 2003 11:03:12 +0100

> What do you think of this idea?

Based on the "running code" maxim, sure :)
 
> works on my MacOSX iBook.

I'll take a look.  Thanks.  

Note my view is that we will have DHCPv6 for DNS resolver discovery; to 
suggest otherwise is rather futile and counter-productive.  However I think
the RA method has environments where it may be suited.   SO we should run
with DHCPv6 tests now for this, and if we discover scenarios where the
fit is not good we push to fix that, and RA method may be an answer.

Tim

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Oct 2003 06:48:44 -0400

The Cisco IOS DHCPv6 server does both stateless DHCP and PD.  The two
functions can be configured independently, so stateless DHCP can be
configured with just a couple of CLI commands.  Of course, the PD code is
still in the IOS footprint...

The primary problem at this point is deploy a client in hosts that can use
stateless DHCP.

In any event, I agree with what Pekka wrote in a followup:

>At 01:09 PM 10/23/2003 +0300, Pekka Savola wrote:
>Hi,
>
>Could we drop this thread here? :-)
>
>IMHO, it's no use to try chase down this particular rathole in *this*
>working group as well.
>
>Just state that the discovery/configuration of DNS is outside of the scope
>of this specification.  Additions can be defined separately in DNSOP or
>other WGs if need be.

- Ralph

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Fri, 24 Oct 2003 01:47:22 +0900

>>>>> On Thu, 23 Oct 2003 11:03:12 +0100, 
>>>>> Tim Chown <[email-masked]> said:

> I'll take a look.  Thanks.  

You may also want to check the following URL
http://www.kame.net/newsletter/20030411/
that describes how to use the DHCPv6 implementation as DNS resolver
discovery.

I agree with Pekka that we should drop this particular thread on this
list, so I'm just going to give a pointer that might be useful.

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 24 Oct 2003 00:03:06 +0200

On 23 okt 2003, at 9:39, Tim Chown wrote:

> It will be interesting to see what the Moonv6 work may have to say in 
> this area, as the issue I'm sure will have been encountered there.   
> There are still very few people working in networks where IPv6 
> transport DNS lookup is a requirement, hence this issue has seen slow 
> progress.

I know, and in practice there won't be many hosts that run just IPv6. 
But what good is a new protocol if it can't stand on its own two feet 
and needs its predecessor to provide crucial functions?

At least the new MacOS that's coming out tomorrow supports DNS 
transport over IPv6, making it possible to run IPv6-only. This is 
pretty cool.

> (e.g. NTP server), so in cases where a DHCPv6 server is present it 
> will be able to be used for resolver discovery.  But I believe we 
> should have a RA based method also.

A strong argument against using DHCPv6 would be that stateless 
autoconfiguration definately has the edge over DHCP so we can expect 
very many people to continue using autoconf even when DHCP 
implementations become available. Requiring DHCP in addition to 
stateless autoconf for just one thing that can also be done using 
mechanisms that autoconf uses would mean unnecessary complexity and 
delays.

But it shouldn't be one or the other. We want/need both.

> The general thrust of the DHCPv6 camp argument is that in any 
> situation where a router is configured to pass DNS info in a RA 
> extension it could equally be configured to do so using DHCPv6 (Lite), 
> or could forward to a DHCPv6 server using the DHCPv6 relay agent 
> function.

I doubt that many people will be using DHCP servers with IPv6. The 
reason to use them in IPv4 is so you can have stable addresses across 
reboots. Stateless autoconfiguration already supports this much better 
than DHCP ever did. And let's not forget that autoconf has been 
available for years while DHCPv6 is just now becoming somewhat 
available.

> The second argument used by the DHCPv6 camp is that having two methods 
> may lead to complexity, and problems in troubleshooting.

That would be a good argument to kill DHCPv6 altogether. Having to run 
autoconf for the address and DHCP for nameservers is exactly the 
complexity we should avoid.

> The third is a fear of creeping featurism - where is the line over 
> which you don't step for RA extensions?   DNS resolver?  Search path?  
> NTP?

When was the last time your browser couldn't load a page because the 
NTP server wasn't found?

---

From: Brian McGehee <[email-masked]>
Date: Thu, 23 Oct 2003 16:07:37 -0700 (PDT)

A student in my IPv6 class this week made the comment regarding IPv6:

 "It seems like the paint isn't dry yet!"

IPv6 needs stability and constant changes scare adopters away.  I agree
DNS should be a component of RA's.  But I feel strongly that we need to
stop making changes and show the industry we have stability.  (i.e.
Site-Local addressing)

...my 2cents...

Brian McGehee
-----------------------------
Native6, Inc.
http://www.native6.com
IPv6 Training and Consulting
-----------------------------

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Oct 2003 20:51:53 -0400

Following up on Pekka's e-mail, the DNS configuration problem now belongs to
the dnsop WG, and followups to this thread should be posted to [email-masked].

Most (if not all) of the issues from this thread have already been discussed
at the dnsop WG meeting in Vienna and on [email-masked]  Please take a look
at the minutes from the Vienna WG meeting,
http://ietf.org/proceedings/03jul/index.html, and the dnsop mailing list
archive, http://www.cafax.se/dnsop/maillist, for more information.

There are lots of problems in this space we haven't solved yet, like how to
do secure updates of PTR records for IPv6 hosts that use stateless address
autoconfiguration - seems to me we ought to apply our spare cycles to those
unsolved problems instead of inventing new solutions to solved problems...

- Ralph

At 12:03 AM 10/24/2003 +0200, Iljitsch van Beijnum wrote:
>>There are still very few people working in networks where IPv6 transport 
>>DNS lookup is a requirement, hence this issue has seen slow progress.
>
>I know, and in practice there won't be many hosts that run just IPv6. But 
>what good is a new protocol if it can't stand on its own two feet and 
>needs its predecessor to provide crucial functions?
>
>At least the new MacOS that's coming out tomorrow supports DNS transport 
>over IPv6, making it possible to run IPv6-only. This is pretty cool.
>
>>(e.g. NTP server), so in cases where a DHCPv6 server is present it will 
>>be able to be used for resolver discovery.  But I believe we should have 
>>a RA based method also.
>
>autoconfiguration definately has the edge over DHCP so we can expect very 
>many people to continue using autoconf even when DHCP implementations 
>become available. Requiring DHCP in addition to stateless autoconf for 
>just one thing that can also be done using mechanisms that autoconf uses 
>would mean unnecessary complexity and delays.
>
>>equally be configured to do so using DHCPv6 (Lite), or could forward to a 
>>DHCPv6 server using the DHCPv6 relay agent function.
>
>I doubt that many people will be using DHCP servers with IPv6. The reason 
>to use them in IPv4 is so you can have stable addresses across reboots. 
>Stateless autoconfiguration already supports this much better than DHCP 
>ever did. And let's not forget that autoconf has been available for years 
>while DHCPv6 is just now becoming somewhat available.
>
>When was the last time your browser couldn't load a page because the NTP 
>server wasn't found?
>
>