Subject: RFC 5006 status

From: Fred Baker <[email-masked]>
Date: Wed, 17 Mar 2010 11:18:44 -0400

This is a structured question for the community.

Jari Arkko tells us that he is getting requests from various sources to take RFC 5006 to Proposed Standard. It is now experimental.

http://www.ietf.org/rfc/rfc5006.txt
5006 IPv6 Router Advertisement Option for DNS Configuration. J. Jeong,
    Ed., S. Park, L. Beloeil, S. Madanapalli. September 2007. (Format:
    TXT=26136 bytes) (Status: EXPERIMENTAL)

(1) Please take a look at the document in the next few days; if you have comments on it (eg, you think it should be changed in some way), please comment to v6ops.

(2) Vendors, please advise on implementations. Are there any? Has interoperability been demonstrated?

(3) Operators, enterprise and/or service provider, please advise on deployment experience.

I'm adding a brief discussion to the agenda Monday morning with a view to getting a quick thumbs-up/thumbs-down to advise Jari, who can then take that to 6man later in the week if appropriate.

BTW, I have had a flurry of email related to the agenda. The current agenda may be found at http://www.ietf.org/proceedings/10mar/agenda/v6ops.html

---

From: Michael Cardell Widerkrantz <[email-masked]>
Date: Wed, 17 Mar 2010 17:13:27 +0100

Fred Baker <[email-masked]>, 2010-03-17 16:18 (+0100):

> Jari Arkko tells us that he is getting requests from various sources
> to take RFC 5006 to Proposed Standard. It is now experimental.
>

Implementations of RFC 5006 known to me:

  - Server side: radvd,

    http://www.litech.org/radvd/

  - Client side:

    My own radns, slowly getting there, 
    http://hack.org/mc/hacks/radns/

    rdnssd, now maintained as a part of ndisc6: 
    http://rdnssd.linkfanel.net
    http://www.remlab.net/ndisc6/

radvd works well with both radns and rdnssd.

> (3) Operators, enterprise and/or service provider, please advise on

I have so far only used this with a manual configuration in radvd, but I
think this will typically be used in a home or SOHO environment where
the ISP gives addresses to DNS resolvers to a home/small office router
with DHCPv6 and that router, in turn, sends this information to end
nodes with the RDNSS option in RA.

-- 
http://hack.org/mc/
Use plain text e-mail, please. OpenPGP welcome, 0xE4C92FA5.

---

From: "Durand, Alain" <[email-masked]>
Date: Wed, 17 Mar 2010 12:44:13 -0400

Fred,

Here is my input to this.

First of, we have in IPv6 two competing auto-config mechanisms: RA & DHCP.
For a subset of parameters, they more or less overlap. For others, they do
not.
DNS is in the later category, only in the standard track for DHCP. An
example of what can only be discovered with RA is default router or prefix
info.
This has been a very poisonous discussion for many years, with the result
that the IPv6 autoconf story is more complicated that the IPv4 one.

At this point, I would favor opening the larger discussion of ³How can we
fix this mess² rather than pushing a particular technique from experimental
to standard track.
It might be that the only acceptable answer is we need to defined BOTH
mechanisms for every value to discover.

Now, about this particular document:

1. The interaction between DHCP & RA is not very well documented.
2. Why do we need a lifetime in that DNS RA? This create extra complexity
for no apparent good reasons
3. What is the host suppose to do when it gets DNS RAs from **different**
interfaces? Should it treat them the same as if they came from the same
interface? Or is it that the information is tied to the prefix, not to the
interface?

In other words, it seem that the general cases beyond a single interface,
single prefix are not well documented.

   - Alain.

On 3/17/10 11:18 AM, "Fred Baker" <[email-masked]> wrote:

> Jari Arkko tells us that he is getting requests from various sources to take
> RFC 5006 to Proposed Standard. It is now experimental.
> 
> (1) Please take a look at the document in the next few days; if you have
> comments on it (eg, you think it should be changed in some way), please
> comment to v6ops.
> 
> I'm adding a brief discussion to the agenda Monday morning with a view to
> getting a quick thumbs-up/thumbs-down to advise Jari, who can then take that
> to 6man later in the week if appropriate.
> 
> 
> 
> BTW, I have had a flurry of email related to the agenda. The current agenda
> may be found at http://www.ietf.org/proceedings/10mar/agenda/v6ops.html
>

---

From: james woodyatt <[email-masked]>
Date: Wed, 17 Mar 2010 11:16:52 -0700

> (2) Vendors, please advise on implementations. Are there any? Has interoperability been demonstrated?

Both solicitor and advertiser sides of RFC 5006 are implemented in Apple's AirPort Extreme and Time Capsule (simultaneous dual-band II) firmware 7.5 and later.  It was tested for interoperability with a Linux implementation prior to its release.

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 17 Mar 2010 11:49:27 -0700 (PDT)

Hi Alain,

>First of, we have in IPv6 two competing auto-config mechanisms: RA & DHCP. For a subset of parameters, they more or less overlap. For others, they do not.
>DNS is in the later category, only in the standard track for DHCP. An example of what can only be discovered with RA is default router or prefix info.
>This has been a very poisonous discussion for many years, with the result that the IPv6 autoconf story is more complicated that the IPv4 one.
>
>At this point, I would favor opening the larger discussion of “How can we fix this mess” rather than pushing a particular technique from experimental to standard track.
>It might be that the only acceptable answer is we need to defined BOTH mechanisms for every value to discover.

I agree. We need IPv4-like DHCP because it is needed in some networks and IPv6 autoconf also because it is needed in some other networks.

>    2. Why do we need a lifetime in that DNS RA? This create extra complexity for no apparent good reasons 
>    3. What is the host suppose to do when it gets DNS RAs from **different** interfaces? Should it treat them the same as if they came from the same interface? Or is it that the information is tied to the prefix, not to the interface?

This issue is MIF WG issue and I think there is a draft on this issue already.

Regards,

Behcet

---

From: james woodyatt <[email-masked]>
Date: Wed, 17 Mar 2010 12:06:48 -0700

On Mar 17, 2010, at 09:44 , Durand, Alain wrote:
> The interaction between DHCP & RA is not very well documented.
That could be improved when revising RFC 5006 for proposed standard.  Apple's implementation merges all IPv4 and IPv6 addresses for DNS servers from all the available sources, DHCP4, DHCP6 and RFC 5006.
> Why do we need a lifetime in that DNS RA? This create extra complexity for no apparent good reasons
Is the reason for the lifetime field really not apparent?  It was perfectly apparent to me when I implemented it, i.e. so that hosts will stop using DNS servers when their lifetimes expire.  This makes renumbering less painful.  I suppose you could argue that the router lifetime should imply the DNS server lifetime, but that would be a weird departure from the conventional architecture of ICMP6 timeout parameters.
> What is the host suppose to do when it gets DNS RAs from **different** interfaces? Should it treat them the same as if they came from the same interface? Or is it that the information is tied to the prefix, not to the interface?
The same thing the host does when it gets DNS server addresses from DHCP servers on different interfaces.  Multihomed hosts have a choice of models for dealing with merging of DNS server configuration: A) merge them all into one list, or B) merge them into a list per interface.  (The RDNSS options are not tied to PIO, so that's not an option.)

> In other words, it seem that the general cases beyond a single interface, single prefix are not well documented.

Most of the issues here revolve around configuring multihome/multistack hosts with recursive DNS server addresses from a variety of sources not necessarily RFC 5006, and those issues should probably be addressed separately whether RFC 5006 goes to proposed standard or not.  There really isn't very much here that makes RFC 5006 into a specific problem in and of itself.  We can argue about the lifetime parameter, which I happen to think is a pretty good idea, but others may differ.

---

From: Mark Smith <[email-masked]>
Date: Thu, 18 Mar 2010 07:19:12 +1030

On Wed, 17 Mar 2010 17:13:27 +0100

> radvd works well with both radns and rdnssd.

radvd and radns have also worked successfully for me.

> nodes with the RDNSS option in RA.

I've been thinking a bit about the RDNSS verses stateless DHCPv6
question a bit in the last few weeks.

I think there is value in the RDNSS option, however I think it is only
really useful for low end embedded devices - ones that are resource
constrained to the point where running a stateless DHCPv6 client might
be too much overhead, although that is a very low point though these
days. Sensor networks could be an example.

(I'm not sure if my perspective is correct, however I've started to
think that the original boundary between RAs and Autoconf was a
"bootstrap" connectivity boundary. RAs provided enough information for
IPv6 to get to the point of being able to send packets beyond the
local router, Autoconf was then to fill in other more user oriented /
application supporting parameters. DNS certainly does fit into the
latter category, although I can see it also being considered a bootstrap
connectivity parameter, which is why the RDNSS option was created)

However, I think the other parameters that RDNSS don't support, such as
SIP servers or NTP servers, are going to be "widely" useful. I think
it's inevitable that all telephones in people's homes will eventually
be IP phones, and they'll need SIP server and possibly time server
addresses. It's possible that all clocks on people's homes will
eventually be "IP clocks" so announcing NTP servers may also be a wide
spread requirement. 

In conjunction with the likely requirement of DHCPv6-PD on CPE, I think
stateless DHCPv6 clients will be nearly ubiquitous on IPv6 devices.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Mar 2010 10:46:51 +1300

This showed up as a requirement in the survey leading to
draft-carpenter-v6ops-isp-scenarios-01:

"Simple automatic distribution of DNS server details is essential;
RFC 5006 support is needed."

Only one ISP out of 30 mentioned this explicitly, although seven stated
an intention to support SLAAC (often combined with DHCPv6). However, it
does seem like the one essential feature for an all-SLAAC deployment.

Regards
   Brian Carpenter

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 18 Mar 2010 04:44:59 +0100 (CET)

> mechanisms for every value to discover.

I favour this approach. With my ISP hat on, I want everything that has to 
do with addresses to be handled by DHCPv6 (this is a MUST to have 
tracability), the rest can be handled by SLAAC or DHCPv6. I'd imagine this 
is totally the opposite of the original intentions of SLAAC.

In a home scenario, I'd like to leave out the complexity of DHCPv6 if 
possible, so there I favour RFC5006.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Antonio Querubin <[email-masked]>
Date: Wed, 17 Mar 2010 18:42:19 -1000 (HST)

> (3) Operators, enterprise and/or service provider, please advise on 

No deployment experience here since none of our equipment currently 
supports it.  But it would be a very welcome feature if hardware vendors 
began supporting it - the sooner the better.

Antonio Querubin
808-545-5282 x3003
e-mail/xmpp:  [email-masked]

---

From: Marco Hogewoning <[email-masked]>
Date: Thu, 18 Mar 2010 09:01:28 +0100

On 18 mrt 2010, at 04:44, Mikael Abrahamsson wrote:

> I favour this approach. With my ISP hat on, I want everything that has to do with addresses to be handled by DHCPv6 (this is a MUST to have tracability), the rest can be handled by SLAAC or DHCPv6. I'd imagine this is totally the opposite of the original intentions of SLAAC.
> 
> In a home scenario, I'd like to leave out the complexity of DHCPv6 if possible, so there I favour RFC5006.

Count me in, although DHCPv6 would be used by the more demanding users I can see a huge group of end-users who are perfectly ok with SLAAC on their home network.

MarcoH

---

From: Gert Doering <[email-masked]>
Date: Thu, 18 Mar 2010 09:14:45 +0100

Hi,

> possible, so there I favour RFC5006.

Seconded, for both.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  150584

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Mar 2010 09:52:34 +0100

On Thu, 18 Mar 2010 04:44:59 +0100 (CET) Mikael Abrahamsson wrote:
>tracability), the rest can be handled by SLAAC or DHCPv6. 

I'm curious, how does that work. Does each and every lightswitch at the
customer have to individually request an IPv6 address from you using DHCPv6?

Or do you also support giving the customer a /48 using PD?

---

From: Gert Doering <[email-masked]>
Date: Thu, 18 Mar 2010 10:04:13 +0100

Hi,

> Or do you also support giving the customer a /48 using PD?

Well, what we envision is:

 - the CPE router gets a /48 or /56 by DHCP-PD
 - the CPE router does RA/5006 announcements so that "the light switches"
   can do SLAAC
 - other services (NTP, ...) will be discovered by service-location protocols
   running locally in the LAN (bonjour, SLP, ...) - OSX already does a great
   job here, in discovering stuff without having to fiddle with DHCP server
   setup etc.

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Thu, 18 Mar 2010 10:15:39 +0100 (CET)

> > is totally the opposite of the original intentions of SLAAC.

Agreed. Note that this includes having DHCPv6 delivering the default
gateway.

> > possible, so there I favour RFC5006.

Agreed here too.

Steinar Haug
Senior network architect, Ventelo Networks (AS 2116)

---

From: Gert Doering <[email-masked]>
Date: Thu, 18 Mar 2010 10:25:56 +0100

Hi,

On Thu, Mar 18, 2010 at 10:15:39AM +0100, [email-masked] wrote:
> Note that this includes having DHCPv6 delivering the default gateway.

This is not really important for us (no cable deployments, and the DSL
deployment is PPP based, so the default gateway is always "the other end
of the pipe" anyway).  But I understand that other networks need this,
so I'm certainly not opposing this.

Gert Doering
        -- NetMaster

---

From: [email-masked]
Date: Thu, 18 Mar 2010 10:30:16 +0100 (CET)

> Or do you also support giving the customer a /48 using PD?

The customer would receive a /56 or /48, depending on local policy. I
would expect the customer to have a router which can then handle IPv6
addressing inside the customer's home.

Steinar Haug

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Mar 2010 10:38:38 +0100

>   job here, in discovering stuff without having to fiddle with DHCP server

Now assuming that the light switch also needs the current time. Probably
using SNTP. I don't that many customers will dedicated NTP devices, so it
is either the router that implements NTP or the ISP's NTP server will be used.

So now the light switch has to implement one of those service location
protocols as well? Or does it use DHCP?

>From an implementors point of view, the main thing I find annoying about
RFC-5006 is that information about DNS servers ends up in the kernel instead
of in user land where I need it. And I don't want the kernel to store and
forward all kinds of user land data. Of course, it is always possible to send
an extra router solicitation ICMP from user land... 

I find it suprising that where essentially every IPv4 device can speak DHCPv4,
we now envision IPv6 devices that do speak DNS, but cannot afford to speak
enough of DHCPv6 to get the address of DNS resolvers.

---

From: Benoit Boissinot <[email-masked]>
Date: Thu, 18 Mar 2010 11:56:05 +0100

> an extra router solicitation ICMP from user land...

As for as I know, rdnssd and radns both process the RA information in
userspace. There's no handling of DNS in the kernel.

regards,

Benoit

---

From: Rémi Després <[email-masked]>
Date: Thu, 18 Mar 2010 11:52:36 +0100

HI,

> so I'm certainly not opposing this.

Some time ago, Dan Wing proposed (I don't remember where) that RAs could contain DHCP options that are worth advertising to all hosts.

If generalized, this would permit to avoid reinventing in RAs options that are available in DHCPv6, and yet make the DHCPv6 protocol to be in general unnecessary.

The simplicity of this approach is IMHO very attractive.

Any thoughts?

RD

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Mar 2010 12:19:32 +0100

>userspace. There's no handling of DNS in the kernel.

A quick look at radns suggests that it doesn't send a router solicitation 
messages. So, if it misses the initial one that is requested by the kernel, it
may take a while before you have your DNS addresses.

I din't check the rdnssd code, but the manual says:
"On Linux, since version 2.6.24, rdnssd takes advantage of a new
"netlink interface,  forwarding  RDNSS  options validated by the
"kernel to user- land.  Otherwise, it merely listens to all ICMPv6
"traffic through a raw socket.

Which suggests extra kernel code, or the same problem as radns.

---

From: Michael Cardell Widerkrantz <[email-masked]>
Date: Thu, 18 Mar 2010 12:39:14 +0100

Philip Homburg <[email-masked]>, 2010-03-18 10:38 (+0100):

> From an implementors point of view, the main thing I find annoying
> about RFC-5006 is that information about DNS servers ends up in the
> kernel instead of in user land where I need it. And I don't want the
> kernel to store and forward all kinds of user land data.

No client side implementation of RFC 5006 that I know of is done in a
kernel. I guess I don't understand what you mean.

Implementing an RFC 5006 client side would typically be done with

  ICMP6_FILTER_SETBLOCKALL(&filter);
  ICMP6_FILTER_SETPASS(ND_ROUTER_ADVERT, &filter);

which then gives you RAs in your userland application, to be read from a
socket just like any other network data.

(Strictly speaking, all network data is passed through the kernel an
almost all operating systems, but that, I guess, is beside the point.)

---

From: Benoit Boissinot <[email-masked]>
Date: Thu, 18 Mar 2010 13:00:56 +0100

On Thu, Mar 18, 2010 at 12:19:32PM +0100, Philip Homburg wrote:
> >> kernel instead of in user land where I need it. And I don't want
> >> the kernel to store and forward all kinds of user land data. Of
> >> course, it is always possible to send an extra router solicitation
> >> ICMP from user land...
> >>
> >

Extra kernel code, yes. But it doesn't store or process anything related
to the DNS servers. In the same way it already forwards address, prefix,
lifetime, etc., it forwards the user options through netlink.

It is not much more than what was previously forwarded, and the code
is not specific to RDNSSD (it is a more generic "useropt" information).

See here for the code:
http://lxr.linux.no/linux+v2.6.33/net/ipv6/ndisc.c#L1373

regards,

Benoit
-- 
:wq

---

From: Mark Smith <[email-masked]>
Date: Thu, 18 Mar 2010 22:50:58 +1030

On Thu, 18 Mar 2010 11:52:36 +0100

> The simplicity of this approach is IMHO very attractive.

Surely if everything is "crammed" into RAs, the only difference between
RAs and stateless DHCPv6 is very slightly less CPU use on the
client/server (i.e. typically router), very slightly less RAM on the
client, and the ability of clients to ask for what they
want and servers being selective about what they give certain clients,
rather than getting everything in RA and then ignoring what they
don't want. Those costs are all so low they're negligible, so I don't
understand why people seem to be so focused on making RAs a slightly
less capable substitute for stateless DHCPv6, at the cost of now having
two nearly identical mechanisms to achieve the same goal.

Antoine de Saint-Exupéry said, "In anything at all, perfection is
finally attained not when there is no longer anything to add, but when
there is no longer anything to take away."

I see adding all the stateless DHCPv6 parameters to RAs as adding
something to RAs that, when added, should be taken away, because a
simple mechanism already exists to perform those functions.

Is there something I'm missing?

---

From: Ole Troan <[email-masked]>
Date: Thu, 18 Mar 2010 14:15:20 +0100

> It might be that the only acceptable answer is we need to defined BOTH mechanisms for every value to discover.

we already have proposals for doing other options in ND, which already exist in DHCP.
should we reconsider the idea of a generic DHCPv6 option container option for ND?

cheers,
Ole

---

From: Michael Cardell Widerkrantz <[email-masked]>
Date: Thu, 18 Mar 2010 14:51:02 +0100

Philip Homburg <[email-masked]>, 2010-03-18 12:19 (+0100):

> A quick look at radns suggests that it doesn't send a router
> solicitation messages.

True. Do you think it should? In many operating systems, the
solicitation is sent from a userland program, in many called rtsol or
rtsold.

How rtsol and radns works together depends on the order in which they
are started. If radns is always started before rtsol, the wait for an RA
you hint at should disappear. I confess I haven't looked into this,
really.

Another idea I've had it so merge radns with rtsold. 

Opinions?

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Mar 2010 15:09:26 +0100

>kernel. I guess I don't understand what you mean.

Let's assume that I want DUD to start as soon as possible, so my kernel
sends the first router solication as soon as the ethernet link is up.
Then it may very well be that the kernel receives an RA before the user
land DNS configuration program is running. Then the DNS option in the RA will
be lost.

So, the DNS configuration program has to send its own router solication. If
DNS configuration data is actually distributed using DHCP, then we just wasted
a multicast and interrupted all routers on the link.

Solution, have the kernel store this information.

Of course, we can pay attention to the other configuration bit in the RA,
and have the kernel store that bit. Then, when that bit is set, we can try
DHCP first and if that fails to return DNS servers fall back to sending a
router solication. Possible, but annoying.

---

From: Rémi Després <[email-masked]>
Date: Thu, 18 Mar 2010 15:10:07 +0100

Hi Mark,

Le 18 mars 2010 à 13:20, Mark Smith a écrit :

> don't want.

The point is to PERMIT, with a very simple extension of RAs, that all common stateless parameters of hosts be available in RAs. 

> Those costs are all so low they're negligible, so I don't

I love this sentence, and have tried to work with it in mind for many years.
This is the case in particular for the subject at hand.
(To me, in design efforts, MISS is even better than KISS: "MAKE It Simple, Stupid" may take more time and energy than just "KEEP It Simple, Stupid", but that's often worth it.)

A given function shouldn't be made more complex than necessary for the (wrong) reason that some of its uses are combined with more complex functions.
Hosts that need only stateless parameters shouldn't be obliged to pay the cost of supporting the protocol that is needed for stateful parameters. 
One more protocol, even if requiring little RAM, is something Saint-Exupery would suggest to get rid of.

If you consider vendors of very small objects that will proliferate with IPv6, they should be permitted to use IPv6 links between these objects and their centralized controllers.
Having in these objects all network parameters acquired in RAs is simpler. 

> simple mechanism already exists to perform those functions.

Note that the idea is not to impose that "all" stateless parameters should have to be advertised in RAs.
It is only that hosts should be prepared to receive some DHCPv6 options in RAs, with a standardized format for this (trivially simple to do).
Options a host doesn't know, or want to know, are simply skipped (thanks to the TLV format of options).

That's it. There is no more to standardize.

And IMHO, nothing will have to be taken away, at any time.

> Is there something I'm missing?

In my understanding, yes, as I tried to explain. 

Regards,
RD

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Mar 2010 16:02:08 +0100

>solicitation is sent from a userland program, in many called rtsol or

Yes, if you do that, and then intergrate radns in rtsol it should be no 
problem.

But I'm not sure why you would want a user land rtsol. 

One thing I noticed when I accidentally plugged a Debian system into an
ethernet port with the wrong vlan, is that the Linux kernel picks up new
prefixes without invalidating the ones that belong to the old link.

I see in the FreeBSD man page for rtsol that it sends out new router
solications when the link status changes. (I don't know if old prefixes are
also flushed).

So I'm wondering how smart it is to have part of this processing in user space.

My person reason for putting it in the kernel is to start DUD as soon as
possible.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 18 Mar 2010 07:00:48 -0700

Stateless DHCPv6, in combination with RA/SLAAC address assignment, is  
simply not complex.  It does not require a full DHCPv6 server, easily  
fits in resource constrained devices and can be configured  
automatically.

Stateless DHCPv6 is certainly less complex than the DHCPv4 servers  
currently deployed in IPv4 gateways.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Thu, 18 Mar 2010 06:58:10 -0700

Giving a counterpoint opinion, home network users don't care which mix  
of RS/RA and DHCP is used on their networks, as long as they don't  
have to deal with it in any way.  The combination of upstream DHCPv6/ 
PD provisioning, with automated config of ND and stateless DHCPv6 is  
easily deployable - I have an existence proof in my lab - and operates  
without any manual intervention whatsoever.  Just as much plug-and- 
play as the IPv4/NAT/DHCP function in RGs.

There are likely other network operators who do have to manually  
manage configs and the network that might prefer RA-only operation,  
but in my opinion home networks are not such a good example...

- Ralph

On Mar 18, 2010, at 1:01 AM 3/18/10, Marco Hogewoning wrote:

>>> It might be that the only acceptable answer is we need to defined  
>>> BOTH mechanisms for every value to discover.
>>
>> I favour this approach. With my ISP hat on, I want everything that  
>> has to do with addresses to be handled by DHCPv6 (this is a MUST to  
>> have tracability), the rest can be handled by SLAAC or DHCPv6. I'd  
>> imagine this is totally the opposite of the original intentions of  
>> SLAAC.
>>
> Count me in, although DHCPv6 would be used by the more demanding  
> users I can see a huge group of end-users who are perfectly ok with  
> SLAAC on their home network.
>
> MarcoH
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 18 Mar 2010 10:21:14 -0700

No - IMO it would be a bad idea to define a generic RA container  
option for DHCP options.  (See previous e-mail.)

- Ralph

On Mar 18, 2010, at 6:15 AM 3/18/10, Ole Troan wrote:

>> First of, we have in IPv6 two competing auto-config mechanisms: RA  
>> & DHCP. For a subset of parameters, they more or less overlap. For  
>> others, they do not.
>> DNS is in the later category, only in the standard track for DHCP.  
>> An example of what can only be discovered with RA is default router  
>> or prefix info.
>> This has been a very poisonous discussion for many years, with the  
>> result that the IPv6 autoconf story is more complicated that the  
>> IPv4 one.
>>
>> At this point, I would favor opening the larger discussion of “How  
>> can we fix this mess” rather than pushing a particular technique  
>> from experimental to standard track.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 18 Mar 2010 12:25:20 -0700

Mark - it seems there is a strong opinion that "running stateless  
DHCPv6" is onerous, and ND/RA is much less overhead.  I don't share  
that opinion - if the network operator really wants to configure all  
those presumably identical parameters in every router - which is  
required for ND/RA, one can just as easily configure and run a  
stateless DHCPv6 server in each router.  The stateless DHCPv6 server  
is really, truly, uncomplicated to implement, configure and run.

And, if the operator wants to centralize configuration, she can use  
the more traditional centralized DHCPv6 server with relay agents in  
all the routers.

So, how is extending RAs to carry the DHCP options any less complicated?

There is one way in which RAs involve less overhead - they can use  
multicast to carry all the options in one message rather than use  
individual message exchanges for each host.

- Ralph

On Mar 18, 2010, at 5:20 AM 3/18/10, Mark Smith wrote:

>> Some time ago, Dan Wing proposed (I don't remember where) that RAs  
>> could contain DHCP options that are worth advertising to all hosts.
>>
>> If generalized, this would permit to avoid reinventing in RAs  
>> options that are available in DHCPv6, and yet make the DHCPv6  
>> protocol to be in general unnecessary.
>>

---

From: Gert Doering <[email-masked]>
Date: Thu, 18 Mar 2010 20:30:36 +0100

Hi,

> individual message exchanges for each host.

Another nice benefit of RAs is that unsolicited RAs can be used to 
add new prefix information (add prefix, deprecate prefix), which becomes 
active right away - while DHCP information will only be refreshed upon,
uh, client-initiated refresh.

Please accept that RA is there to stay, and that this infighting between
the two groups ("who needs RA when you can have DHCP!!!") is not going
to help.  The IETF has solidly messed up this part of IPv6 by delaying
things for 10 years or so...

"real world speaking",

Gert Doering
        -- NetMaster

---

From: Ralph Droms <[email-masked]>
Date: Thu, 18 Mar 2010 12:40:15 -0700

You miss my point.  I have no problem with using RAs for  
configuration.  I don't see this as infighting - unless you consider  
the expression of a different opinion to be "infighting".  I don't  
happen to share your opinion that "[t]he IETF has solidly messed up  
this part of IPv6 by delaying things for 10 years or so," which is  
truly not a helpful opinion.  I'm just trying to make sure everyone  
has the facts straight.

- Ralph

---

From: Gert Doering <[email-masked]>
Date: Thu, 18 Mar 2010 21:10:25 +0100

Hi,

On Thu, Mar 18, 2010 at 12:40:15PM -0700, Ralph Droms wrote:
> I don't  happen to share your opinion that "[t]he IETF has solidly 
> messed up this part of IPv6 by delaying things for 10 years or so," 

No need to share any opinion here.  Just try to run an IPv6-only network
with Windows, Linux and MacOS clients, and consider whether the IETF 
might have given vendors better guidance.  Or finished one or the other
RFC 5 years earlier.

As an operational person, this endless bickering between the RA camp and
the "what do you need RA for that, when DHCP can do this all along" has
FAIL stamped all over it.

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Mar 2010 13:32:01 -0700

Gert,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Gert Doering
> Sent: Thursday, March 18, 2010 1:10 PM
> To: Ralph Droms
> Cc: Gert Doering; Mark Smith; Rémi Després; IPv6 v6ops
> Subject: Re: RFC 5006 status
> 
> Hi,
> 

If you are meaning to blame the RA/DHCP discussions for
the slow uptake of IPv6, I don't think that is correct.
IPv6 was declared operational in 2002 and 8 years later
we still have yet to see appreciable growth. But, that
is a business case failing and not a protocol one.

Fred
[email-masked]

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 18 Mar 2010 21:41:45 +0100

On Thu, 18 Mar 2010 11:56:05 +0100, Benoit Boissinot <[email-masked]>

>> RFC-5006 is that information about DNS servers ends up in the kernel

>> instead of in user land where I need it. And I don't want the kernel to

>> store and forward all kinds of user land data. Of course, it is always

>> possible to send an extra router solicitation ICMP from user land...

There is no need to store it. It just needs to be forwarded. (Arguably

though, the whole auto-configuration should be entirely done in user space

anyway.)

> userspace. There's no handling of DNS in the kernel.

As one of the co-author of rdnssd, I can assure you that this is incorrect.

rdnssd gets the RDNSS information from the Linux kernel via NetLink out of

the kernel SLAAC code.

-- 

Rémi Denis-Courmont

http://www.remlab.net

http://fi.linkedin.com/in/remidenis

---

From: Benoit Boissinot <[email-masked]>
Date: Thu, 18 Mar 2010 21:52:49 +0100

> though, the whole auto-configuration should be entirely done in user space

It would probably be a good idea, much more flexible than configuring via
sysctl.

> rdnssd gets the RDNSS information from the Linux kernel via NetLink out of

I should have been clearer. There's indeed a forwarding, but no
processing of the DNS information happens in the kernel.

regards,

Benoit
-- 
:wq

---

From: Gert Doering <[email-masked]>
Date: Thu, 18 Mar 2010 22:09:41 +0100

Hi,

> the slow uptake of IPv6, I don't think that is correct.

Not alone so, of course.  But the lack of standards and/or guidelines in 
certain areas (RA/DHCP, multi6, selection of src+dst address pairs in the 
face of multiple source and destination IPv6 addresses being available)
certainly didn't help.

As I said: you still can't run an IPv6-only network with the most
common client operating systems without manually configuring some
missing bits and pieces.  Had some standards be available 5 years
earlier, most notably 5006, this might all be a non-issue today.

Let me repeat: I'm an operational person, and not a researcher or 
vendor.  We funny operational people are not searching for the "most 
religiously perfect" solution for things.  We need something that 
*works*, and we need it in a timely fashion.

Gert Doering
        -- NetMaster

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 18 Mar 2010 14:18:30 -0700

Gert,

> From: Gert Doering [mailto:[email-masked]]
> Sent: Thursday, March 18, 2010 2:10 PM
> To: Templin, Fred L
> Cc: Gert Doering; Ralph Droms; Mark Smith; Rémi Després; IPv6 v6ops
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Where is this pressure for this coming from? Are there
customers waiting frustrated at your doorstep because
you are not yet able to provide them a service they are
longing to pay for? (Note: I am a firm believer in the
need to move to IPv6 and have been pushing for it for
close to 15 years now. But, I still don't see the
developing business cases yet.)

Fred

---

From: james woodyatt <[email-masked]>
Date: Thu, 18 Mar 2010 14:44:15 -0700

On Mar 18, 2010, at 07:00, Ralph Droms wrote:
> 
> Stateless DHCPv6, in combination with RA/SLAAC address assignment, is simply not complex.  It does not require a full DHCPv6 server, easily fits in resource constrained devices and can be configured automatically.
> 
> Stateless DHCPv6 is certainly less complex than the DHCPv4 servers currently deployed in IPv4 gateways.

This has been my experience.

Configuring a stateless DHCP6 server is pretty easy compared to a stateful DHCP4 server, where you're forced to manage address assignments as well.  If you've already inserted a DHCP4 server into your residential gateway, it isn't that hard to add a stateless DHCP6 server for just the IPv6 DNS server addresses.

If RFC 5006 were to be revised for Standards Track category, then one "improvement" we might consider is to require O=0 in router advertisements that contain RDNSS options.  This would go some way toward addressing the ambiguity problem, while still allowing routers to advertise O=0 and PIO with A=1 and expect that hosts that SLAAC their addresses to those prefixes will be able, at least, to run applications that require them to be able to resolve domain names.

The main reason I'm a proponent of RFC 5006 is because it makes the O bit in the router advertisement something that can usefully be set to zero.  I suppose another way forward would be to deprecate O=0 in router advertisements.

---

From: <[email-masked]>
Date: Thu, 18 Mar 2010 22:57:27 +0100

We have implemented this on Symbian OS and on Nokia S40 OS. Tested against RADVD and TAHI. Not released in products yet.

Would like to see this go to Proposed Standard.

Best regards,

Teemu

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Fred Baker
> Sent: 17. maaliskuuta 2010 17:19
> To: IPv6 Operations
> Cc: Lindqvist Kurt Erik; Ralph Droms; 6man Chairs; Dave Thaler; Jari
> Arkko; [email-masked]; [email-masked];
> [email-masked]; Daniel Park
> Subject: RFC 5006 status
> 
> Jari Arkko tells us that he is getting requests from various sources to
> take RFC 5006 to Proposed Standard. It is now experimental.
> 
> (1) Please take a look at the document in the next few days; if you
> have comments on it (eg, you think it should be changed in some way),
> please comment to v6ops.
> 
> I'm adding a brief discussion to the agenda Monday morning with a view
> to getting a quick thumbs-up/thumbs-down to advise Jari, who can then
> take that to 6man later in the week if appropriate.
> 
> 
> 
> BTW, I have had a flurry of email related to the agenda. The current
> agenda may be found at
> http://www.ietf.org/proceedings/10mar/agenda/v6ops.html

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Mar 2010 11:00:21 +1300

Fred,

>> *works*, and we need it in a timely fashion.

If you have a defective egg, you may not get a chicken
at all.

The time pressure is at http://www.potaroo.net/tools/ipv4/,
and the ISPs we've surveyed have given 2011 as the most
common date when they want to offer IPv6 as a standard
service. [Shameless plug for my presentation in v6ops
and iepg.]

Getting back to the purpose of this thread, I've seen enough
responses describing operational value in 5006 to convince me
that we should standardise it for use in simple deployments.
I can't see a downside, quite regardless of who chooses to
deploy DHCPv6; that is a separate question entirely.

    Brian

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Mar 2010 08:41:49 +1030

On Thu, 18 Mar 2010 14:15:20 +0100

> should we reconsider the idea of a generic DHCPv6 option container option for ND?

We could also have a go at re-inventing the wheel.

Sorry to be sarcastic, but now is not the time to be clean
slating autoconf methods when there is not another 10 to 15 years
before we need to deploy IPv6. Further more, going down that path now
will cause even more people to hesitate to deploy it - including me.
Why would I want to invest time in deploying today's autoconf
methods that work if there is a chance that they'll be completely
replaced in 5 to 10 years?

People need to accept the existing methods, even though they may not be
completely happy with them. The time to influence their design has gone
- it was 15 years ago.

---

From: Ralph Droms <[email-masked]>
Date: Thu, 18 Mar 2010 15:25:35 -0700

You still miss my point.  I don't think sending config info in RAs is  
necessarily a bad idea.  The IETF has worked from an architectural  
guideline of providing one way to carry config.  Some network  
operators would rather use one protocol to carry config, be that ND or  
DHCP.  It's just a different philosophy.

I do think the idea of carrying config info in RAs is being sold with  
FUD.  I also think the ways in which adding more config info to RAs  
ought to be thought through fairly carefully, based on some of the  
IETF's relevant experience with DHCP.

- Ralph

---

From: james woodyatt <[email-masked]>
Date: Thu, 18 Mar 2010 16:11:13 -0700

> should we reconsider the idea of a generic DHCPv6 option container option for ND?

I wouldn't support that.  We already have a protocol where merging a wide variety of configuration options for multiple sources is the main object of the game, and it's called DHCP.  I see no reason to insert all that complexity into the processing and emission of router advertisements.

I can see utility in the *limited* extension of RDNSS to standards track, because it allows zero-configuration hosts on IPv6 networks where all the routers advertise O=0 to have some hope of resolving domain names after joining them.  They don't get that today, and I don't see a good way to use DHCP to do anything about that.

Advancing RDNSS to proposed standard would be a recognition that the Domain Name Service is *not* like the other services that an IPv6 host may require dynamic configuration to use, i.e. it's not a luxury, it's expected to be universally available everywhere there is an IPv6 router.  I realize this would be a departure from the current architecture, where for reasons that I don't quite understand, the DNS is regarded as an "extra" feature of the Internet that's only relevant to special interest communities, and under no circumstances should it be regarded as a fundamental architectural component.  Still, I think it's worth reconsidering the question.

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 19 Mar 2010 00:26:39 +0100

On Thu, 18 Mar 2010 21:52:49 +0100, Benoit Boissinot <[email-masked]>

wrote:

>> As one of the co-author of rdnssd, I can assure you that this is

>> incorrect.

>> rdnssd gets the RDNSS information from the Linux kernel via NetLink out

>> of the kernel SLAAC code.

> processing of the DNS information happens in the kernel.

Parsing the packet is done in kernel. But it's not nearly as arguable as

retaining extra state in the kernel.

-- 

Rémi Denis-Courmont

http://www.remlab.net

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Mar 2010 14:09:51 +1300

On 2010-03-19 11:25, Ralph Droms wrote:
> guideline of providing one way to carry config.  Some network operators
> would rather use one protocol to carry config, be that ND or DHCP.  It's
> just a different philosophy.
> 

What I notice is that DHCP has become very heavily loaded with options.
Although one can deploy DHCP without using all those options, it has
become a complex thing. SLAAC at least has the advantage that it's
stayed simple; in fact the only overloading so far is RFC 5006. I think
we'd need a very convincing argument to depart from that simplicity,
as opposed to simply saying: if you need to convey arbitrary parameters
to hosts, use DHCPv6, which is intended for that purpose.

A DNS server address is not an arbitrary parameter; along with a default
router, it's the second address you *must* know in every host. So adding
it to SLAAC seems consistent. Adding arbitrary parameters to SLAAC would
be a whole other approach, and I'm not sure I understand the motivation.

    Brian

---

From: Seiichi Kawamura <[email-masked]>
Date: Fri, 19 Mar 2010 10:43:30 +0900

I fully agree with Brian here.
I would choose DHCPv6 inside my ISP/data center
network to do any dynamic node configurations where necessary.
Traceability is a MUST.
But I would like to have SLAAC in other areas specifically
services that connect nodes
that don't have robust amount of resources.

So keeping SLAAC simple, but with the
options that are absolutely necessary to
get connected(default router and dns)
without relying on other protocols or manual
configuration, would be the best thing.

Regards,
Seiichi

---

From: Xing Li <[email-masked]>
Date: Fri, 19 Mar 2010 10:01:57 +0800

Seiichi Kawamura 写道:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

I second.

xing

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iEYEARECAAYFAkui1sEACgkQcrhTYfxyMkLcFgCfYrw8qJBRg1RusLOHtAt6OOfj
> uH4An0deFXQJJ0X1a/2UJ7ux0a9vkbAn
> =W/oE
> -----END PGP SIGNATURE-----
>
>
>

---

From: Gert Doering <[email-masked]>
Date: Fri, 19 Mar 2010 09:15:33 +0100

Hi,

On Thu, Mar 18, 2010 at 02:18:30PM -0700, Templin, Fred L wrote:
> Where is this pressure for this coming from? 

The lack of finalized standards has been a topic in many discussions
with our customers and with early adopters in the last years.

"So if the standardization process is not yet finished, we'll better wait,
otherwise me might have to do things twice".

I'm not saying that this is *the* reason why IPv6 adoption is slow, but
it didn't help either.

Gert Doering
        -- NetMaster

---

From: Adrian Kennard <[email-masked]>
Date: Fri, 19 Mar 2010 08:53:51 +0000

> (2) Vendors, please advise on implementations. Are there any? Has interoperability been demonstrated?

Firebrick FB6000 series as of release V0.00.402-Gerald Alpha (9th Mar 
2010) supports announcing RDNSS addresses as part of RA.

> (3) Operators, enterprise and/or service provider, please advise on deployment experience.

We have deployed in our offices and found nothing seems to take any 
notice of the RDNSS announcement. We found we had to run rdnss on linux 
to pick up addresses and it has slightly odd handling of the 
/etc/resolv.conf file when dhcp client also running and only on more 
recent installations.

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Mar 2010 10:59:53 +0100

> (1) Please take a look at the document in the next few days; if you have comments on it (eg, you think it should be changed in some way), please comment to v6ops.

While supporting in general the idea, there is one improvement I suggest to make:
Rather than a specific RA option for Recursive DNS Servers, standardize the generic RA option to embed some stateless DHCP options, as proposed in draft-krishnan-intarea-ra-dhcp-00.

This is in my understanding more powerful without being more complex.
By giving to routers a general possibility to broadcast stateless DHCP parameters (in addition to their still being obtainable in DHCPv6), not only the purpose of RFC50026 is achieved but, in one shot, the same progress is made for all common parameters that may concern all or most hosts.
  
Hosts that support the RA DHCP option only have to: (1) process embedded DHCP options that they understand; (2) skip others; (3) request in DHCPv6 only options that aren't already received in RAs, if any.

Note that Suresh Krishnan has 15min slot scheduled at the 6man meeting of Wednesday for:
"Stateless DHCPv6 and Router Advertisements for propagating configuration information".

I add Suresh to the list, and Dan Wing who is known to support this approach.

RD

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 19 Mar 2010 16:35:57 +0530

What's the difference between running Stateless DHCPv6 vs carrying
DHCP options in ND messages?

If nodes can implement DHCP options in ND messages, I could not
understand why cannot they implement Stateless DHCPv6 itself.

In case ND option for DHCPv6 options is better than running stateless
DHCPv6, then we need to look at whether there exists any other options
other the DNS server address for which IETF is looking at defining RA
options.

Thanks,
Syam

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Fri, 19 Mar 2010 08:41:26 -0400

> I can see utility in the *limited* extension of RDNSS to standards
> track, because it allows zero-configuration hosts on IPv6 networks
> where all the routers advertise O=0 to have some hope of resolving
> domain names after joining them.  They don't get that today, and I
> don't see a good way to use DHCP to do anything about that.

I'm confused by this O=0 proposal. I thought the O flag was intended to
announce that there was a DHCP server available with other (non-IA)
configuration info, including NTP, SIP server, DNS, etc. Is this
suggesting that the O flag be used exclusively to announce the
availability of DNS info in DHCPv6, and not any other config info?
Should clients just guess whether DHCPv6 is available for non-IA,
non-DNS info? Is it suggesting that if clients do not support RFC5006
for getting DNS info (but do support DHCPv6), that they not be given a
hint that a DHCPv6 server is available that might have other config
info? Or, with O=0, would there be a simultaneous proposal that support
for RFC5006 be mandatory in clients?

Just trying to understand this, since I've seen it suggested before, and
can't quite figure out the full range of expected behavior in the wild
frontier of IPv6 home networks.
Barbara

---

From: Mark Smith <[email-masked]>
Date: Fri, 19 Mar 2010 23:50:49 +1030

On Fri, 19 Mar 2010 16:35:57 +0530

> DHCP options in ND messages?

A very small amount of RAM, CPU and a single packet. They way people
are persisting with this "we've got to turn RAs in to half-duplex
DHCPv6", you'd think those all those things were getting dramatically
more expensive.

I have a challenge for the RA for everything crowd. Firstly, however,
I'd like to quote Yogi Berra, or possibly Jan L. A. van de Snepscheut
or Albert Einstein (according to
http://en.wikiquote.org/wiki/Yogi_Berra),

"In theory there is no difference between theory and practice. In
practice there is."

I haven't seen anybody justify this RA for everything view
by saying, "I deployed RAs + stateless DHCPv6, and I had (one or more
of) (a) devices run out of RAM, (b) run out of CPU or (c) run out of
network bandwidth" or listed some significant problem they experienced
with the existing mechanisms. So as far as I can see, all the arguments are theoretical,
with no practice to support the argument.

The existing mechanisms work, both in theory, and in practice. I think
that means that the onus is on the RA for everything proponents to
*prove* where it doesn't work before anybody should spend valuable time
redesigning the existing mechanisms. There are better IPv6 things to
spend time on that are far more important to *get* working, rather than
spending time on changing the way existing things work.

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Fri, 19 Mar 2010 09:26:29 -0400

My sense of what's going on in the industry is that there is a lot of
momentum around RFC5006 being used inside home networks. It is widely
stated and believed that clients and OSs exist that only support RFC5006
and not DHCPv6 for DNS (v6 server) acquisition. Therefore, most router
manufacturers and ISPs seem to be leaning towards putting RFC5006 inside
the routers anyway, no matter the status of the RFC. 

I say acknowledge the inevitable and make it a standard. There's no way
to put this genie back in the bottle. 

Beyond RFC5006, I really, really hope that the IETF doesn't try to
duplicate all DHCPv6 stateless config in RA (and I would have preferred
not having DNS in RA -- but, like I said, what's done is done, and the
inevitability of RFC5006 just has to be accepted). 

My concerns are centered around operations, testing devices to make sure
they work, and troubleshooting customer configuration problems. 

When clients are given the ability to choose among multiple ways to do
the same thing, this means that the router/server has to support *all*
of these ways. Even if each is simple on its own, the complexity of
supporting all methods is additive (at a minimum). All methods have to
be coded, and all have to be tested. This doubles the effort of
coding/testing on the routers.

When a customer calls to complain that something isn't working, and it
turns out something didn't get configured, we'll have to figure out
first how it was expecting to get configured. This increases the
complexity of troubleshooting.

What I need, operationally, is predictability. All this discussion
around "let's create half a dozen ways to do the same thing so hosts can
choose the one they like best" is a recipe for failure. Every time the
IETF creates a new way to do something that can already be easily done,
you're introducing complexity and make it that much more likely that
things will go wrong for the average consumer.  Please, please, please
-- Keep It Simple, for every device in the ecosystem.
Barbara

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Mar 2010 14:54:58 +0100

> DHCP options in ND messages?

As noted by Ralph (who was not arguing in favor of RAs, but just stating a fact):
"There is one way in which RAs involve less overhead - they can use multicast to carry all the options in one message rather than use individual message exchanges for each host."

Other differences can be discussed, but there is at least this one.

> understand why cannot they implement Stateless DHCPv6 itself.

This question amounts to:
"why to make it simpler when you can afford to keep it complex?"
The right answer is IMHO in the sentence of Saint-Exupery quoted by Mark Smith on this thread:
"In anything at all, perfection is finally attained not when there is no longer anything to add, but when
there is no longer anything to take away."

> other the DNS server address for which IETF is looking at defining RA

No.
Not more than to specify Stateless DHCP servers.
(Note incidentally that RFC on Stateless DHCPv6 (RFC 3736) already mentions SIP-server addresses as useful stateless parameters, without this closing the list for the future.) 

The standard needs only to say that:
- Routers MAY send RAs containing stateless DNS options
- Hosts MAY be ready to receive stateless DNS options in RAs
- IF THEY DO, it MUST be with the approved format.
(And, for this, the format proposed by Suresh is so obvious and simple that I doubt there would be any competitive proposals)

This being done, one can expect that all vendors of products that send and/or receive RAs will eventually add this simple capability to their products, making things more efficient and simpler in many circumstances. 

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Mar 2010 15:07:49 +0100

Le 19 mars 2010 à 14:20, Mark Smith a écrit :

> *prove* where it doesn't work...

There is clearly no proof that it doesn't work, but there is a proof that efficiency can be improved by a very small complement.

> ... before anybody should spend valuable time
> redesigning the existing mechanisms.

There is no "redesign", just an optional complement for which, contributors who wish to implement it, need an approved common format.
Those that don't want to support it are free not to: things will continue to work for them as before, just less efficiently than for those who have the complement. 

> There are better IPv6 things to

Then, please let others doing it (it won't hurt you in any way), and the discussion will terminate.

RD

---

From: "STARK, BARBARA H (ATTLABS)" <[email-masked]>
Date: Fri, 19 Mar 2010 10:21:29 -0400

> (And, for this, the format proposed by Suresh is so obvious and simple
> that I doubt there would be any competitive proposals)
> 
> This being done, one can expect that all vendors of products that send
> and/or receive RAs will eventually add this simple capability to their
> products, making things more efficient and simpler in many
> circumstances.

Thus doubling the complexity of the devices that now have to support *both* DHCPv6 stateless and RAs for receiving/sending that *identical* info, and greatly increasing the difficulty of troubleshooting problems (because 2 solutions now exist where there used to just be one). What we have today is simple. It sounds to me like the question being asked is "why keep it simple when you can make it more complex?" In my case, "it" refers to the overall ecosystem of protocols.
Barbara

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 19 Mar 2010 19:52:47 +0530

> "why to make it simpler when you can afford to keep it complex?"

Sure, as far as I know that's how things being done at the IETF - If
it ain't broke, don't fix it.

> This being done, one can expect that all vendors of products that send and/or receive RAs will eventually add this simple capability to their products, making things more efficient and simpler in m…

I doubt this. For me this would be a new standard that needs to be
implemented new.

And if you are proposing the RA DHCP option for DNS server address
alone, for the argument sake, this involves one extra step in
processing than RFC 5006.

I hope there will not be another proposal for RA into DHCP :-)

Thanks,
Syam

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Mar 2010 15:38:57 +0100

Le 19 mars 2010 à 15:22, Syam Madanapalli a écrit :
> alone,

I am not.
Just the opposite.
It is RFC 5006 which has this limitation.

> I hope there will not be another proposal for RA into DHCP :-)

Your job, (in any case not mine ;-).

RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Mar 2010 15:47:29 +0100

Le 19 mars 2010 à 15:21, STARK, BARBARA H (ATTLABS) a écrit :

> Thus doubling the complexity of the devices that now have to support *both* DHCPv6 stateless and RAs for receiving/sending that *identical* info,

No.
Again, no one is obliged to implement it in any device.
But those who do it (to increase efficiency), have a standard format to do it.
Deployment is incremental and can remain partial.

The point is that authorizing some DHCP options in RAs is more powerful, and simpler, than RFC 5006.
This way should therefore, IMHO, be preferred.

RD

---

From: Syam Madanapalli <[email-masked]>
Date: Fri, 19 Mar 2010 20:36:06 +0530

What I understood from your arguments is that you have a solution and
we need to find a problem.

>> And if you are proposing the RA DHCP option for DNS server address

You can put the list here, and the need for these list to be in RAs.

> It is RFC 5006 which has this limitation.

RFC 5006 has been written for a single and specific option.
You seem to be justifying DHCP into RA based on RFC 5006
defining DNS Server Address Option, which in my views is
incorrect.

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Mar 2010 16:29:51 +0100

> You can put the list here, and the need for these list to be in RAs.

No need for the list.
The proposal is just a generic tool.
It can be used with any existing or future stateless DNS option, existing or to be added.

> defining DNS Server Address Option, which in my views is

That's in fact not how things happened.
I had already expressed to Dan Wing, in a previous meeting, my support for DNS options in RAs, not remembering that the original idea was from Suresh Krishnan. 
But now that it is discussed that  RFC 5006 could become standard track, it's an obvious time to suggest a more generic approach.

RD

---

From: Sander Steffann <[email-masked]>
Date: Fri, 19 Mar 2010 16:39:39 +0100

Hi,

> it to SLAAC seems consistent.

This exactly summarizes my thoughts/feelings about this. I fully agree.
Sander

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 19 Mar 2010 08:55:17 -0700 (PDT)

Hi Rémi,

Le 19 mars 2010 à 12:05, Syam Madanapalli a écrit :

> What's the 
> difference between running Stateless DHCPv6 vs carrying
> DHCP options in 
> ND messages?

As noted by Ralph (who was not arguing in favor of RAs, but 
> just stating a fact):
"There is one way in which RAs involve less overhead - 
> they can use multicast to carry all the options in one message rather than use 
> individual message exchanges for each host."

> Other differences can be 
> discussed, but there is at least this one.

Please note that in practice this difference of less overhead goes away if you consider very commonly used point-to-point links.

BTW, I removed long cc list and just kept v6ops because I think everybody is on this list already :-).

Regards,

Behcet

---

From: Rémi Després <[email-masked]>
Date: Fri, 19 Mar 2010 17:06:58 +0100

> Please note that in practice this difference of less overhead goes away if you consider very commonly used point-to-point links.

Well noted.
The value of the solution is mainly for "very commonly used" MULTIPOINT links ;-)

RD

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 19 Mar 2010 16:49:08 +0000

> But I'm not sure why you would want a user land rtsol. 
[...]
> My person reason for putting it in the kernel is to start DUD as soon as

wut?  How are you supposed to easily write /etc/resolv.conf from kernel-land?

rtsol belongs in userland, and the more complicated it becomes, the
stronger the reason to have it there.  If you need to interact with a
kernel from userland, you can easily define careful interfaces to do so.

> FAIL stamped all over it.

Amen to that.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Fri, 19 Mar 2010 17:59:15 +0100

>kernel from userland, you can easily define careful interfaces to do so.

I'm talking about real RAs, the ones with information about routers, prefixes,
and stuff like that.

I want that as soon as possible. And all of that stuff needs to be in the
kernel anyhow. Moving RA processing to user land just makes things more
difficult.

Problems start when you start mixing that with information that belongs in
/etc/resolv.conf.

The easy way out is to just issue another series of router solicitations from
user land. 

I think nobody yet remarked in this thread that RAs tend to be periodic
whereas DHCP is not. So you end up broadcasting (officially multicasting,
but everybody gets it anyhow) the same DNS entries over and over again.

---

From: Gert Doering <[email-masked]>
Date: Fri, 19 Mar 2010 18:08:01 +0100

Hi,

On Fri, Mar 19, 2010 at 05:59:15PM +0100, Philip Homburg wrote:
> whereas DHCP is not. 

I did...

> So you end up broadcasting (officially multicasting,

Which is good.  Because it is the only way to get updated information
to clients the moment they are updated, except of waiting for the 
clients to poll for them.

(Less important for DNS, more important for change of on-link prefixes)

Gert Doering
        -- NetMaster

---

From: John Jason Brzozowski <[email-masked]>
Date: Fri, 19 Mar 2010 13:30:15 -0400

Fred,

I would not object to advancing this document.  Given the diversity of how
hosts are currently configured with configuration information it might be
useful have this be a proposed standard.

John

> (3) Operators, enterprise and/or service provider, please advise on deployment

=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Mar 2010 18:31:39 +0100

On 3/19/10 2:09 AM, Brian E Carpenter wrote:
> router, it's the second address you *must* know in every host.
Once IPv6 went down the path of redrawing the lines between ARP, ICMP, 
DHCP, etc. from IPv4, it was bound to have made at least one error. It 
seems clear to me that this was one of those cases. I agree with Brian: 
the addresses every host IP stack MUST know to operate should be part of 
SLAAC.

- Mark

---

From: Mark Townsley <[email-masked]>
Date: Fri, 19 Mar 2010 18:42:05 +0100

> (Less important for DNS, more important for change of on-link prefixes)
I can think of cases where it could be important for DNS too. But, 
without going into that rathole here, suffice to say that DNS is so 
fundamental to IP, particularly in IPv6 where humans loathe typing in 
raw addresses far more than in IPv4, that I don't mind the client being 
updated with the latest-greatest DNS servers often.

- Mark

---

From: james woodyatt <[email-masked]>
Date: Fri, 19 Mar 2010 12:27:04 -0700

On Mar 19, 2010, at 05:41, STARK, BARBARA H (ATTLABS) wrote:
> [I wrote:]
> configuration info, including NTP, SIP server, DNS, etc.

Yes, but O=0 does not actually imply that there MUST be no DHCP service, despite the Note on page 19 of RFC 4861.  It merely implies that there MAY be no DHCP service.  Another router on the same link can assert by advertising to hosts with O=1 that there MUST be a DHCP service.

>                                                               Is this

Not at all.

> non-DNS info?

Right now, the only standard way to configure hosts dynamically with DNS server addresses is with DHCPv6.  Hosts that join networks where no routers are advertising O=1 are either configured with DNS server addresses manually, or they are forced to start their DHCPv6 clients to get configured-- despite the fact that all the routers are explicitly warning that there MAY be no DHCPv6 service available.

So.  An alternative way forward out of this mess would be to leave RFC 5006 in experimental category and deprecate the O bit entirely, i.e. update the router requirements to require all RA to be sent with O=1, and explicitly encourage hosts with DHCPv6 stateless clients to start them immediately on completion of SLAAC regardless of the state of AdvOtherConfigFlag.  I'd support that too.

> Is it suggesting that if clients do not support RFC5006

I don't see a need to revise the host requirements to make support for processing RDNSS options in router advertisements any more necessary for conformance than support for processing DHCP.

But if we *did*, then that would mean that a certain operating system I'm thinking about would no longer be able to claim compliance with IPv6 host requirements while still requiring domesticated primates to type numeric IPv6 addresses into a squirrelly little text window buried three layers down in System Preferences before they can watch the special dancing animation on their favorite IPv6 pr0n site.

I'm trying to be careful what else I say about that.

> frontier of IPv6 home networks.

Here's what the IPv6 router on my home network does today:

+ Advertises with O=1 and M=0.
+ Offers stateless DHCP6 service with its own global address as the DNS server for the link.
+ Advertises with RFC 5006 its own global address as the DNS server for the link.
  - Lifetime is set the same as the prefix lifetime.
+ Runs a recursive DNS forwarding server (access limited to the LAN prefix).

Currently, all the hosts on my home network that can process RFC 5006 messages also have DHCPv6 clients in them, so they process both sources of DNS server address, merge them together and get the single address that's advertised in both, and they configure themselves appropriately.

The interesting part happens when the delegated prefix changes, e.g. when I switch the WAN uplink from one network to another.  The addresses of the DNS servers available to hosts on the LAN link changes.  This gets reflected quickly in the RDNSS options that the router sends, and the hosts with RFC 5006 clients updates their DNS resolver configurations immediately.  Since I don't have any hosts with *only* a DHCPv6 client and no RFC 5006 client, I'm not sure what happens to such hosts when their DNS server addresses need to be changed away from the ones they learned from their DHCPv6 lease.  I suspect they just keep using the addresses they were initially offered until their lease expires, and this will produce suboptimal user experience until they go to renew.

---

From: Mark Smith <[email-masked]>
Date: Sat, 20 Mar 2010 10:16:02 +1030

On Fri, 19 Mar 2010 12:27:04 -0700

> The interesting part happens when the delegated prefix changes, e.g. when I switch the WAN uplink from one network to another.  The addresses of the DNS servers available to hosts on the LAN link c…

I think that issue would be resolved by having your CPE use it's LAN
interface ULA addresses to announce it's local DNS resolution service.
Doing that isn't explicitly mentioned in the basic CPE draft, however as
the CPE's DNs resolution service is an optional 'site local' service, I
think using the CPE's LAN interface ULA address to announce it would
make sense, and avoid the issue you mention.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Sat, 20 Mar 2010 10:31:37 +1030

On Fri, 19 Mar 2010 09:26:29 -0400

> the routers anyway, no matter the status of the RFC. 

One possible explanation is that RAs have been supported by all IPv6
implementations since they were originally released, however DHCPv6
clients, relays and servers have only become available in the last 5 or
so years. Now there is at least one implementation available, for all
major end-node OSes. However, if people who you're getting opinions from
are still making the assumption of the lack of DHCPv6 implementations,
then they're quite predictably going to say that RAs should carry
everything, because all IPv6 implementations support processing RAs,
despite existing RA processing not currently supporting any of the
option they'd like to put in RAs.

---

From: Mark Smith <[email-masked]>
Date: Sat, 20 Mar 2010 10:52:37 +1030

On Fri, 19 Mar 2010 15:07:49 +0100

> There is clearly no proof that it doesn't work, but there is a proof that efficiency can be improved by a very small complement.

So it would seem to don't place any value on deployment costs,
troubleshooting costs, developer time spent on duplication of
functionality that could be spent on new and different functionality
or bug fixing existing functionality, functionality interaction and
duplicate information arbitration should it not match. They're the
biggest costs of new features. Comparatively, the cost of standardising
things in the IETF is minuscule.

> Then, please let others doing it (it won't hurt you in any way), and the discussion will terminate.

Yes it will. I'm an operator. See all those costs I mentioned before?
I, and the organisation and network end-users I work for, will be forced
to wear them either directly day to day, or embedded in the costs of
products purchased. The IETF and vendors "force" certain costs upon
people like me and my customers/end-users. I'm willing to wear them and
defend them to my end-users if I see more value in the benefit than the
cost. Partially duplicating DHCPv6 functionality in RAs doesn't
satisfy that criteria, and I'd much rather try prevent that unnecessary
cost now than have to wear it for a very long period later (either
until I die or retire from networking).

---

From: james woodyatt <[email-masked]>
Date: Fri, 19 Mar 2010 18:25:30 -0700

On Mar 19, 2010, at 16:46, Mark Smith wrote:
> On Fri, 19 Mar 2010 12:27:04 -0700 james woodyatt <[email-masked]> wrote:
>> 

That might work fine for routers that are integrated with their own DNS forwarding servers.  The interesting case is routers that *DO NOT* have integrated DNS servers, which if I recall correctly, the current CPE router draft implicitly assumes.

In those cases, when the service provider moves the DNS servers, or when the WAN link is dropped and reacquired at a new connection point with a different delegated prefix and new DNS servers, the hosts on the LAN need to have their resolver configurations renumbered.  The RDNSS option in router advertisements permits this to happen immediately after reattaching to the service provider network for every host on the LAN with a short burst of link-local multicast packets, but DHCP requires a Reconfiguration message to be unicast to every client, which implies that all the hosts on the LAN are required to implement not just DHCP6, but DHCP Authentication.  Any hosts that can't do DHCP Authentication won't get their resolvers reconfigured until they renew their lease.  Bletch.

I think RFC 5006 is a much simpler solution for this scenario.  But I recognize that there are people who think that every IPv6 network, *everywhere*-- even the ones in our own homes-- should have *every* interface address managed and firewalled six ways to Sunday, in case the secret police come calling and wish to inspect the premises for evidence of terrorist activity.  I really don't know what to say to those people anymore.

---

From: Doug Barton <[email-masked]>
Date: Fri, 19 Mar 2010 19:09:43 -0700

On 03/19/10 18:25, james woodyatt wrote:
>>> The interesting part happens when the delegated prefix changes,
>>> e.g. when I switch the WAN uplink from one network to another.
>>> The addresses of the DNS servers available to hosts on the LAN
>>> link changes.  This gets reflected quickly in the RDNSS options
>>> that the router sends, and the hosts with RFC 5006 clients
>>> updates their DNS resolver configurations immediately.  Since I
>>> don't have any hosts with *only* a DHCPv6 client and no RFC 5006
>>> client, I'm not sure what happens to such hosts when their DNS
>>> server addresses need to be changed away from the ones they
>>> learned from their DHCPv6 lease.  I suspect they just keep using
>>> the addresses they were initially offered until their lease
>>> expires, and this will produce suboptimal user experience until
>>> they go to renew.
>> 
>> I think that issue would be resolved by having your CPE use it's
>> LAN interface ULA addresses to announce it's local DNS resolution
>> service. Doing that isn't explicitly mentioned in the basic CPE
>> draft, however as the CPE's DNs resolution service is an optional
>> 'site local' service, I think using the CPE's LAN interface ULA
>> address to announce it would make sense, and avoid the issue you
>> mention.
> 
> That might work fine for routers that are integrated with their own
> DNS forwarding servers.  The interesting case is routers that *DO
> NOT* have integrated DNS servers, which if I recall correctly, the
> current CPE router draft implicitly assumes.

Given the large number of problems these forwarders cause for
advancement to the DNS protocol (EDNS0, DNSSEC, new RR types, etc.) I
think continuing to encourage NOT including them is the best course of
action.

> In those cases, when the service provider moves the DNS servers,

On a rational network this does not happen often enough to be considered
a primary design goal.

> when the WAN link is dropped and reacquired at a new connection point
> with a different delegated prefix and new DNS servers,

Both RA and DHCP already handle this case.

> The RDNSS option in router advertisements permits this to happen
> immediately after reattaching to the service provider network for
> every host on the LAN with a short burst of link-local multicast
> packets, but DHCP requires a Reconfiguration message to be unicast to
> every client, which implies that all the hosts on the LAN are
> required to implement not just DHCP6, but DHCP Authentication. 

See above.

> I think RFC 5006 is a much simpler solution for this scenario.  But I
> recognize that there are people who think that every IPv6 network,
> *everywhere*-- even the ones in our own homes-- should have *every*
> interface address managed and firewalled six ways to Sunday, in case
> the secret police come calling and wish to inspect the premises for
> evidence of terrorist activity.  I really don't know what to say to
> those people anymore.

Um, wow.

-- 

	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!    http://SupersetSolutions.com/

---

From: Mark Smith <[email-masked]>
Date: Sat, 20 Mar 2010 13:33:22 +1030

On Fri, 19 Mar 2010 18:25:30 -0700

> That might work fine for routers that are integrated with their own DNS forwarding servers.  The interesting case is routers that *DO NOT* have integrated DNS servers, which if I recall correctly,…

In principle I'm generally against CPE having DNS resolvers in them, as
they've caused me enough trouble in the past, however, that's probably
fundamentally been caused by implementation issues, not so much an
issue with the idea.

I'm wondering if it is right for the CPE router draft to assume that,
if it is being assumed to be the common case. It seems to be a very
common thing for DNS resolvers to be implemented in the CPE, including
in some IPv6 capable CPE I've seen.

I also think there is a possibility that service providers may start
delegating forward and reverse DNS zones to customers' CPE e.g.
<customer>.cust.example.com and <delegated prefix>.<blah>.in-addr.arpa.
That, combination with things like Zeroconf/DNS-Service Discovery, will
mean CPE may also become authoritative DNS servers as well as resolvers.

> In those cases, when the service provider moves the DNS servers, or when the WAN link is dropped and reacquired at a new connection point with a different delegated prefix and new DNS servers, the hosts on the LAN need to have their resolver configurations renumbered.

I'd think service providers changing DNS servers addresses these
days would be a rare event. The service providers I've worked at have
either implemented anycast DNS or already have it, to avoid having to
change DNS addresses. One contributor to this problem is that for some
reason one of the troubleshooting steps helpdesks seem to automatically
do is get the customer to statically configure the DNS server IP
addresses, even though the networking equipment is providing it
automatically e.g. via PPP. Usually when that doesn't fix the customers
issue, the helpdesk don't get the customer to reverse it, so as time
goes on you have more and more customers with static DNS
configurations. That makes it pretty much impossible to change DNS IP
addresses these days. Even if only 5% of customers have static DNS
addresses, with 50K+ customers, your still looking at 2500 additional
helpdesk calls within hours of the change if you do it.

Because of that, even if you do implement new anycast DNS servers
with IPv4 /32s out of a range of addresses reserved for /32s, you will
also need to now anycast the old DNS server addresses as /32s even if
they formerly out of e.g. a /24 assigned to a LAN. My estimate would be
that if you want that /24 back to use as a /24, rather than a new range
of 256 /32s, you'll be waiting around 5 years before the customer
disruption caused by removing them is small enough.

I do agree that updating DNS addresses caused by a change of provider
is an issue. 

>  required to implement not just DHCP6, but DHCP Authentication.  Any
>  hosts that can't do DHCP Authentication won't get their resolvers
>  reconfigured until they renew their lease.  Bletch.
> 

Wind up their paranoia until they completely disconnect from the
Internet, and aren't a problem for you anymore :-) David Icke has a few
theories that might help with that. The CIA/NSA/etc. would be the least
of their worries if they find out about the reptilian humanoids
that are controlling the world.

;-)

Regards,
Mark.

---

From: Lindqvist Kurt Erik <[email-masked]>
Date: Fri, 19 Mar 2010 17:22:28 +0100

(not as co-chair but as myself) 

> configuration, would be the best thing.

I agree with what others have said. I believe there is a need for for both configuration options - yes, as Ralph has pointed out there are still some issues that needs to be clarified, but for me that would be part of the process of moving to PS. In my day job I often see a use case for SLAAC and I also see if used, not having the DNS option is often an issue. 

Best regards,

- kurtis -

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 22 Mar 2010 02:06:58 -0400

Hi Fred,
  I think this RFC is ready to be moved to Standards track. The one 
thing I think the document is missing is a domain search list. I would 
like this to be added into the standards track version of this RFC.

Thanks
Suresh

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Fred Baker
> Sent: Wednesday, March 17, 2010 8:19 AM
> To: IPv6 Operations
> Cc: Lindqvist Kurt Erik; Ralph Droms; 6man Chairs; Dave 
> Thaler; Jari Arkko; [email-masked]; 
> [email-masked]; [email-masked]; Daniel Park
> Subject: RFC 5006 status
> 
> Jari Arkko tells us that he is getting requests from various 
> sources to take RFC 5006 to Proposed Standard. It is now experimental.
> 
> (1) Please take a look at the document in the next few days; 
> if you have comments on it (eg, you think it should be 
> changed in some way), please comment to v6ops.
> 
> I'm adding a brief discussion to the agenda Monday morning 
> with a view to getting a quick thumbs-up/thumbs-down to 
> advise Jari, who can then take that to 6man later in the week 
> if appropriate.
> 
> 
> 
> BTW, I have had a flurry of email related to the agenda. The 
> current agenda may be found at

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 22 Mar 2010 11:14:47 -0500

Here is my input.  I do not support moving this document to Standards
Track.  

Folks have already asked what if DHCPv6 is also deployed in the IPv6
network and if both ND and DHCPv6 send DNS options who wins?  For side
note, please note, routers tend to be deployed with load balancing and
also one may have more than one default router in the network.  What if
DNS configuration is fat-fingered on one router but not the other. 

Hemant

---

From: Gert Doering <[email-masked]>
Date: Mon, 22 Mar 2010 17:27:57 +0100

Hi,

On Mon, Mar 22, 2010 at 11:14:47AM -0500, Hemant Singh (shemant) wrote:
> What if

"Things will break if configured wrongly" is a funny argument to me.

Regarding the original question, I'd expect client devices to merge
multiple different DNS servers into a list, and use that.  Ordered by
priorities.  Clients need to merge DNS server addresses from various
sources anyway - there's still v4 around, and for the next 5 years,
I expect people to use DNS over IPv4 *and* IPv6.  So admins might want 
to see a v4 and a v6 resolver in their clients' "/etc/resolv.conf"...

Gert Doering
        -- NetMaster

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 22 Mar 2010 10:56:13 -0700

This document needs to be standards track. There is no 'competition' between
auto-conf vs. dhcp, they serve different communities and need to stand
alone. The historic error in the IETF process was to require both stateful
and stateless to have any network operate. Each approach really need to
stand alone and be fully functional without dependency on the other. The
missing link on the auto-conf side is 5006, and it needs to be standards
track asap.

Tony

> Behalf Of Gert Doering
> Sent: Monday, March 22, 2010 9:28 AM
> To: Hemant Singh (shemant)
> Cc: Fred Baker (fred); IPv6 Operations; Lindqvist Kurt Erik; Ralph
> Droms (rdroms); 6man Chairs; Dave Thaler; Jari Arkko;
> [email-masked]; [email-masked];

---

From: Ole Troan <[email-masked]>
Date: Mon, 22 Mar 2010 11:06:25 -0700

Tony,

> missing link on the auto-conf side is 5006, and it needs to be standards

if that's your argument, why shouldn't every DHCP option be possible to encode in an ND message?
is DNS _that_ special?

cheers,
Ole

---

From: Lea Roberts <[email-masked]>
Date: Mon, 22 Mar 2010 11:31:24 -0700 (PDT)

> if that's your argument, why shouldn't every DHCP option be possible to encode in an ND message?

I believe DNS is _that_ special!  :-)

in all the various IPv6-only adventures in which I've participated 
(Internet2 Joint Techs, NANOG and ARIN), auto-conf works great but the 
network usefulness is rather limited without a DNS server.    /Lea

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 22 Mar 2010 15:49:54 -0500

If DHCPv6 and ND do not work together in the deployment, I hear ya,
Tony.  However where is text of "use one at a time" in any RFC to warn
users?  Further, then see my text about multiple default routers in the
network.  The more than one default router case is same as when DHCPv6
and ND run in the same network.  What does one do there?  I am also
replying to Gert here.  The simple problem is that what if a host
queries two DNS servers and gets back two different responses - which
one does the client use?  RFC5006 has further inertia towards becoming a
standard because now DNS64 is coming about and we have one more systems
one will screw up.

Hemant

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tony Hain
Sent: Monday, March 22, 2010 10:56 AM
To: 'IPv6 Operations'
Subject: RE: RFC 5006 status

This document needs to be standards track. There is no 'competition'
between
auto-conf vs. dhcp, they serve different communities and need to stand
alone. The historic error in the IETF process was to require both
stateful
and stateless to have any network operate. Each approach really need to
stand alone and be fully functional without dependency on the other. The
missing link on the auto-conf side is 5006, and it needs to be standards
track asap.

Tony

---

From: Gert Doering <[email-masked]>
Date: Mon, 22 Mar 2010 22:43:43 +0100

Hi,

On Mon, Mar 22, 2010 at 03:49:54PM -0500, Hemant Singh (shemant) wrote:
> The simple problem is that what if a host queries two DNS servers and 
> gets back two different responses - which one does the client use?  

Typically, hosts don't do that today.  They query the first DNS recursor
in their list (=priority) and if that one is too slow, they will go and
query the next one.

But in any case, if a network admin announces the addresses of two
different DNS resolvers that return *different* answers (and only one
of them is working), well, I'd consider that configuration broken by
human error.

> RFC5006 has further inertia towards becoming a

What does a specific DNS translation technology have anything to do with
the method that we use to tell the clients which DNS recursor to use?

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Mar 2010 12:34:40 +1300

> standard because now DNS64 is coming about and we have one more systems

I really think you are worrying about things that won't happen in a simple
unmanaged network where only SLAAC is used.

In a managed network, surely we can assume consistent management,
and fairly rapid action when inconsistency arises. We can't design
solutions that are 100% immune to fat fingers.

    Brian

---

From: "Hemant Singh (shemant)" <[email-masked]>
Date: Mon, 22 Mar 2010 22:08:36 -0500

>From: Brian E Carpenter [mailto:[email-masked]] 
>Sent: Monday, March 22, 2010 4:35 PM
>Cc: [email-masked]; IPv6 Operations

>solutions that are 100% immune to fat fingers.

Fat-fingering configuration of the RA was icing on the cake for two bigger problem I raised in my emails.  Still fat-fingering is a recognized problem in v6ops with (http://tools.ietf.org/html/draft-ietf-v6ops-rogue-ra-00). Snipped from the Abstract of this draft is the following text:

[However, unintended misconfigurations by users or administrators, or possibly malicious attacks on the network, may lead to bogus RAs being present, which in turn can cause operational problems for hosts on the network.]

The two bigger problems were (a) DHCPv6 and ND being used together in one network and (b) which was that folks sometimes miss that the ND RFC 4861 always refers to default router(s) with a plural.  In both (a) and (b) who wins if a client receives information from two authoritative sources?  I would certainly like such a RFC to be on Standards Track if the community desires it.  But unless potential pitfalls are documented, perhaps with a new paragraph to RFC 5006, and then the document goes thru a IETF review and gets a new RFC number, I am not comfortable with RFC 5006 for Standards Track just yet.  App behavior cannot be assured.  Again, unless I see documents in BEHAVE or other RFCs for DNS64 lookup etc. with specific text for app behavior, I am not convinced app behavior can break domain lookup.  My apologies in advance if I have missed any existing text in this regard for app behavior.

Hemant

---

From: Antonio Querubin <[email-masked]>
Date: Tue, 23 Mar 2010 00:53:45 -1000 (HST)

> if that's your argument, why shouldn't every DHCP option be possible to encode in an ND message?

Yes.  DNS info is required for any host to operate.  Without it SLAAC is 
really incomplete.

Antonio Querubin
808-545-5282 x3003

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 23 Mar 2010 14:42:39 +0100 (CET)

On Mon, 22 Mar 2010, Hemant Singh (shemant) wrote:

> Fat-fingering configuration of the RA was icing on the cake for two 
> bigger problem I raised in my emails.  Still fat-fingering is a 
> recognized problem in v6ops with 
> (http://tools.ietf.org/html/draft-ietf-v6ops-rogue-ra-00). Snipped from 
> the Abstract of this draft is the following text:
>
> [However, unintended misconfigurations by users or administrators, or 
> possibly malicious attacks on the network, may lead to bogus RAs being 
> present, which in turn can cause operational problems for hosts on the 
> network.]

So as rogue dhcp server. Rogue-RA draft does not cope with rogue dhcp 
servers, but similar problem can happen...

>
> The two bigger problems were (a) DHCPv6 and ND being used together in 
> one network and (b) which was that folks sometimes miss that the ND RFC 
> 4861 always refers to default router(s) with a plural.  In both (a) and 
> (b) who wins if a client receives information from two authoritative 
> sources?  I would certainly like such a RFC to be on Standards Track if 
> the community desires it.  But unless potential pitfalls are documented, 
> perhaps with a new paragraph to RFC 5006, and then the document goes 
> thru a IETF review and gets a new RFC number, I am not comfortable with 
> RFC 5006 for Standards Track just yet.  App behavior cannot be assured.

It can be assured with consistent configuration. Don't configure 
differently.

> Again, unless I see documents in BEHAVE or other RFCs for DNS64 lookup 
> etc. with specific text for app behavior, I am not convinced app 
> behavior can break domain lookup.  My apologies in advance if I have 
> missed any existing text in this regard for app behavior.

I think BEHAVE and other DNS64 users has to be asked if they are 
confortable with the RFC 5006 style DNS propagation or not.

Best Regards,
 		Janos Mohacsi

---

From: Marco Hogewoning <[email-masked]>
Date: Tue, 23 Mar 2010 15:31:41 +0100

> I agree with what others have said. I believe there is a need for for both configuration options - yes, as Ralph has pointed out there are still some issues that needs to be clarified, but for me t…

Having real users on a real network I can confirm this is the case. In general my residentials don't even check, they hook up their machine and browse to ipv6.google.com to test wether it works, they don't look or care how things are done so in general just keep using the IPv4 nameservers.

I agree SLAAC should offer the basics to operate and DNS is one of those items you can't do without.

Groet,

MarcoH

---

From: Mark Townsley <[email-masked]>
Date: Wed, 24 Mar 2010 09:41:32 +0100

> confortable with the RFC 5006 style DNS propagation or not.
And since 5006 is implemented, they'd be wise to take this into account 
regardless of what its status as an IETF document remains. The running 
code is already there, DNS64 needs to deal with it.

- Mark