Subject: Re: How IPv6 host gets DNS address

From: Bob Hinden <[email-masked]>
Date: Wed, 01 Oct 2003 11:19:04 -0700

John,

>This apparent efficiency - one packet per link rather than 2 per host -
>would come at the cost of the hosts waiting until the next scheduled
>multicast RA. Where would the two-packet exchange be more detrimental
>than a random delay until DNS is available?

The host learns about the router via a Router Advertisement (RA) so having 
it use the same mechanism to learn the addresses of a DNS server doesn't 
add any extra delay.  Having all the information in one RA seems like a 
clear win to me as compared to using RAs to learn about routers and link 
info, and then (perhaps in parallel, but I am not sure about that) have 
each host use a two packet DHCPv6 exchange to get the addresses of the 
recursive DNS servers.

> >In addition, mobile node (especially WLAN) prefer RA option to DHCP
> >from ISP experiences because of below reasons
> >1) Delay of DHCP request/reply Relay
> >2) Risk of centralized DHCP server (fault, failure and etc.)
>
>In the circumstance in which RA would suffice, there is no need for
>a "centralized DHCP server" or the relay agent to get traffic to it.
>The same router that provides RA could answer a DHCPv6 information
>request with the options relevant to DNS.

Right, if the router was running the DHCPv6 (or DHCPv6 lite) server, then 
they would have the same fate sharing propriety with the RAs.  If it was a 
centralized DHCPv6 server, then Soohong Park's comment would apply.

Bob

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

---

From: Doug Barton <[email-masked]>
Date: Wed, 1 Oct 2003 12:04:27 -0700 (PDT)

> each host use a two packet DHCPv6 exchange to get the addresses of the

The problem with this argument is that it's a slippery slope. It sounds
totally reasonable to say, "As long as we have X, we might as well
include Y." However, the address(es) of the recursive name servers
aren't that useful without a search list. Then, once you get into a
windows environment you really need the netbios name server address....
etc. Once you get done with that, you've invented something that looks
an awful lot like dhcp.

Doug

-- 
	If you're never wrong, you're not trying hard enough.

---

From: Suresh K Satapati <[email-masked]>
Date: Wed, 1 Oct 2003 20:18:38 -0700 (PDT)

> etc. Once you get done with that, you've invented something that looks

completely agree.

---

From: Pekka Savola <[email-masked]>
Date: Thu, 2 Oct 2003 08:03:39 +0300 (EEST)

On Wed, 1 Oct 2003, Doug Barton wrote:
> The problem with this argument is that it's a slippery slope. 

Agreed here.

> It sounds
> aren't that useful without a search list. 

Why do you need a search list?  I certainly don't.

Just remember which scenarios we'd be targeting the solution.  The target 
audience would _very probably_ *not* be the enterprise network.

> Then, once you get into a

In an environment of one hop (e.g. home), the lookups can go directly over 
the LAN I think?  And in some cases, it isn't really necessary, as Windows 
environements may not be used at all in some environments where this is 
envisioned.

> etc. Once you get done with that, you've invented something that looks

What if the mechanism is not meant to be an every-purpose tool for service 
discovery, but rather, for every specific purposes only?

The one example I personally have used a couple of times is my laptop at 
the IETF or in some other network I plug it to.  I don't care less about 
DHCP, NTP (the clock is good enough already), Windows environments, search 
paths, etc. -- I just want the DNS and be done with it..!

-- 
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: Brad Knowles <[email-masked]>
Date: Thu, 2 Oct 2003 11:03:01 +0200

>  Why do you need a search list?  I certainly don't.

	Maybe you don't, but I submit that you're not the target typical consumer.

>  audience would _very probably_ *not* be the enterprise network.

	One target audience would be the enterprise network.  Another 
would be the home user.  I can see where search lists would be 
important to both.

>  paths, etc. -- I just want the DNS and be done with it..!

	Again, I don't think you're the target typical consumer.

-- 
Brad Knowles, <[email-masked]>

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
     -Benjamin Franklin, Historical Review of Pennsylvania.

GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
#----------------------------------------------------------------------
# To unsubscribe, send a message to <[email-masked]>.

---

From: Bob Hinden <[email-masked]>
Date: Thu, 02 Oct 2003 16:15:38 -0700

Pekka,

>paths, etc. -- I just want the DNS and be done with it..!

That's my experience as well and the scenario where using RA's makes the 
most sense.  I think it is becoming very common in many quasi public 
networks where all one needs is an address and the address of a DNS 
server.  It's simple and works reliably.

Bob

---

From: Randy Bush <[email-masked]>
Date: Thu, 2 Oct 2003 17:09:32 -0700

>> The one example I personally have used a couple of times is my
>> laptop at the IETF or in some other network I plug it to.  I
>> don't care less about DHCP, NTP (the clock is good enough
>> already), Windows environments, search paths, etc. -- I just
>> want the DNS and be done with it..!
> That's my experience as well and the scenario where using RA's
> makes the most sense.  I think it is becoming very common in many
> quasi public networks where all one needs is an address and the
> address of a DNS server.  It's simple and works reliably.

due to recent more strinent mail relay issues, one also often needs
the local smtp server.  pita.

randy

---

From: Bob Hinden <[email-masked]>
Date: Thu, 02 Oct 2003 17:04:25 -0700

Doug,

>etc. Once you get done with that, you've invented something that looks

To clarify by slippery slope, I think you mean creating two sets of options 
(e.g., one for DHCPv6 and one for RA's) as both DHCPv6 and IPv6 neighbor 
discovery are existing protocols.  It seems to be this can easily be 
avoided by creating an ND option that can carry a DHCPv6 option.  The ND 
options are <type><length> form so it should be easy to define a new one 
that said the contents was a DHCPv6 option.   This seems very simple to me.

I also note that the current list of DHCPv6 option drafts listed on the DHC 
w.g.'s charter that are relevant is fairly short (DNS, Time, NIS, and two 
DSTM IDs) and as far as I can tell only the first three have current 
drafts.  I think it is very unlikely that there is going to be a need for 
options for nbios, IPX, etc. with IPv6.

So perhaps even in the worst case the slippery slope isn't that 
steep.  Note, I do think think we can keep this under control and limit RAs 
to the most basic services.  The addresses of the recursive DNS servers is 
what I think is needed the most.

Bob

---

From: Ralph Droms <[email-masked]>
Date: Thu, 02 Oct 2003 20:39:12 -0400

I think the slippery slope is not so much the options, but rather the
requirement that a stack implement both mechanisms.  That is, the
stack - not knowing which of RA or DHCP might be in use where the device
might be attached - must have both the RA and DHCP implementation.  The
problem gets worse if more options get added, perhaps in parallel, to both
RA and DHCP.  With Bob's suggestion, the specification of the two
protocols in parallel seems easy enough.  But the stack implementer will
have to add code for any new options to both RA and DHCP.

- Ralph

At 05:04 PM 10/2/2003 -0700, Bob Hinden wrote:
>To clarify by slippery slope, I think you mean creating two sets of 
>options (e.g., one for DHCPv6 and one for RA's) as both DHCPv6 and IPv6 
>neighbor discovery are existing protocols.  It seems to be this can easily 
>be avoided by creating an ND option that can carry a DHCPv6 option.  The 
>ND options are <type><length> form so it should be easy to define a new 
>one that said the contents was a DHCPv6 option.   This seems very simple to me.

---

From: Brad Knowles <[email-masked]>
Date: Fri, 3 Oct 2003 03:20:06 +0200

>  the local smtp server.  pita.

	Many sites now are insisting that you use a local domain to go 
along with that local SMTP server.  Otherwise, they won't route your 
mail.  So, now you have to be told what the local domain is (or what 
at least some of the acceptable local domains are), what the SMTP 
server is (servers are), etc....

	Nice slippery slope.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 3 Oct 2003 09:32:24 +0300 (EEST)

> the local smtp server.  pita.

I'm not sure if this is a common problem.  From my perception,
 - if you log in to some foreign system (either using SSH, VPN, ...), 
you'll already use that mail relay; and

 - if you fetch the mails to your system or read them remotely (e.g. using 
secured IMAP), you'd most probably want to have secured SMTP access as 
well (if not encrypted, at least authenticated, to your home mail relay)

Your scenario seems to happen if the folks want to send mail from their
laptop (or similar) unauthenticated and unencrypted using SMTP?  
Something I've missed?

---

From: Randy Bush <[email-masked]>
Date: Thu, 2 Oct 2003 23:41:52 -0700

> laptop (or similar) unauthenticated and unencrypted using SMTP?  

yep.  you know, that small minority who use this funny opsys
from somewhere near seattle, use pop3, and then try to use
smtp.

i am not saying they are doing a good thing.  or that they
are smart.  they're just paying our salaries.

randy