Subject: RE: proposal for a compromise on DNS discovery

From: "BELOEIL Luc FTRD/DMI/CAE" <[email-masked]>
Date: Tue, 29 Jul 2003 13:43:33 +0200

Hi Doug

> -----Message d'origine-----
> De : Doug Barton [mailto:[email-masked]]
> Envoye : mardi 29 juillet 2003 05:15
> 
> 
> On Mon, 28 Jul 2003, BELOEIL Luc FTRD/DMI/CAE wrote:
> 
> > Ok DHCP servers are embedded in current IPv4 SOHO router.
> 
> There, and LOTS of other places.
> 

Good point. But "LOTS of other places" should be clarified for the sake
of arguments.

> > This is cheap and efficient. But this is not a valid argument to to
> > say that DHCP is THE only valid solution to announce DNS resolver
> > server IPv6 address.
> 
> DHCP in SOHO networks alone isn't, no. However, the fact that 
> just about
> every network of any size has, or can easily deploy dhcp(lite) is.
> 

Don't conclude so quickly please. 
- "every network of any size" do not always have DHCP. At least one
example: DSL access use currently PPP+IPCP so as to configure IPv4
"parameters".
- "or can easily deploy dhcp(lite": ok it is not so clear for me.
Deployment is one thing, then we should be sure that such a solution
would work in a lot of situation. I have the case where several DHCP
servers (one stateless, and another statefull for example) could deal a
same LAN, and there I still miss the proper engineering rules not to
confuse a DHCP client.

> > There was a analysis made by the DNS Discovery Design Team 
> in march 2001
> > (draft-ietf-ipnwg-dns-discovery-01.txt). Wouldn't it be 
> valuable to go
> > on or to restart such a work ? (instead of this no-end battle?)
> 
> The "battle" would end if the RA DNS proponents would stop 
> re-proposing
> it. :)
> 

:)

> Doug

Luc

#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Doug Barton <[email-masked]>
Date: Tue, 29 Jul 2003 10:55:01 -0700 (PDT)

> Good point. But "LOTS of other places" should be clarified for the sake

I've already clarified my argument in great detail in a previous post. I
should have restrained my urge to comment on this post, but let me make
myself clear once again:

1. In every situation where RA DNS announcements are proposed, dhcp is a
   better solution.

2. RA DNS announcements are an ugly feature creep for RA, and should not
   be implemented.

Is that clear enough for you? :)

Doug

-- 
Angel:  We need you to distract the vampires.
Buffy:  Right.
Xander: What are you going to do?
Buffy:  I'm going to kill them all. (Walking away)
	That oughta distract them.
  "When She Was Bad" - Buffy the Vampire Slayer, Season 2 Episode 1
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Tim Chown <[email-masked]>
Date: Tue, 29 Jul 2003 20:17:30 +0100

> 1. In every situation where RA DNS announcements are proposed, dhcp is a

But will every device have a DHCPv6 (or DHCPv6 Lite) server on link?  For
those that do, one might ask "why bother with stateless autoconf?" and of
course many sites will wish to keep using DHCP(v6) as a policy choice.
But for networks without DHCP on link, the RA method is an alternative.

Perhaps you can elaborate on your view of "better" to help the resolution
of this discussion along? :)
 
> 2. RA DNS announcements are an ugly feature creep for RA, and should not

The spec for Router Advertisements allows for additional options to be
specified, so this was considered possible when the spec was done.

Tim

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Jul 2003 13:02:45 -0700

</ad>

> But will every device have a DHCPv6 (or DHCPv6 Lite) server on link?

i remember when this was asked of v4.  at the stockholm ietf, which
was not all that long ago, folk so disbelieved in it that i had to
run the dhcp server on my laptop and leave it on a rather beautiful
corner table all week.  within a year it was common, two it had
become ubiquitous.

as someone recently asked, do we really believe that a significant
number of nets will have a dns server but not a dhcp server?  the
$65 home dsl gateways have a dhcp server now, and many have some
sort of dns cache or relay.  my wristwatch probably has a dhcp
server, but i don't know how to access it.

randy

---

From: Alain Durand <[email-masked]>
Date: Tue, 29 Jul 2003 13:19:38 -0700

On Tuesday, July 29, 2003, at 12:17  PM, Tim Chown wrote:

> For

One could very well envision a network where the routers will act as
DHCP-lite servers, only passing "stateless configuration" like
DNS server, NTP server, .... but NOT allocating IPv6 addresses.

> specified, so this was considered possible when the spec was done.

So the next step would be to define NTP server address in RA, web proxy 
address in RA,
SIP server address in RA,.... RA could be extended to pass anything 
that could be a DHCP option.
This is where feature creep happen.

	- Alain.

---

From: Doug Barton <[email-masked]>
Date: Tue, 29 Jul 2003 14:59:49 -0700 (PDT)

> But will every device have a DHCPv6 (or DHCPv6 Lite) server on link?

This has been asked an answered numerous times. In addition to the
overly simplistic "yes" that this overly simple question deserves,
please note the rather precise way that I've framed my statement. For
every situation that you can posit where RA DNS "might be a good idea,"
my response is, "dhcp is a better idea."

The fact that dhcp is already nearly impossible to avoid, even if you
wanted to, simply adds strength to my argument.

> For those that do, one might ask "why bother with stateless autoconf?"

ENONSEQUITUR

> and of course many sites will wish to keep using DHCP(v6) as a policy
> choice. But for networks without DHCP on link, the RA method is an
> alternative.

See above.

> of this discussion along? :)

I have done this in the past, but the summary is that dhcp already
provides the mechanism to do what RA DNS announcements would, plus all
the other things that are actually needed to make a client that needs
DNS resolution functional. Thus, it's pointless to make an incomplete
implementation of something from scratch when a complete implementation
of a complete solution already exists.

<selfish state=on>
Also, speaking as a client (freebsd) implementor, I don't want to have
to fuss with "maybe RA exists, and maybe it doesn't," given that the
solutions are already in place for dhcp.
<selfish state=off>

> specified, so this was considered possible when the spec was done.

I didn't say, "RA should never be added to." I said THIS is an ugly
feature creep for RA. Primarily because the IP(s) of the resolver(s) are
mostly useless without the search string, and then of course you'll be
needing to add the netbios name server IPs, etc. etc.

There is no point in starting down this road (and lots of reasons not
to).

Hope this helps,

Doug

---

From: Tim Chown <[email-masked]>
Date: Tue, 29 Jul 2003 20:17:30 +0100

Tim

---

From: Doug Barton <[email-masked]>
Date: Tue, 29 Jul 2003 10:55:01 -0700 (PDT)

Doug