[ipv6hackers] "Stick to limited IPv6 deployments, businesses warned"

[Owen DeLong]

On Sep 10, 2012, at 00:03 , Doug Barton <dougb at dougbarton.us> wrote:

> On 9/8/2012 12:49 PM, Owen DeLong wrote:
>> 
>> On Sep 8, 2012, at 12:42 , Doug Barton <dougb at dougbarton.us> wrote:
>> 
>>> On 09/05/2012 23:48, Owen DeLong wrote:
>>> 
>>>> SLAAC+RDNSS is very useful. SLAAC without RDNSS not so much since you
>>>> then have to deploy DHCP anyway just to get the basic functionality
>>>> SLAAC should have originally included.
>>>> 
>>>> Yes, lots of enterprises want DHCP for a variety of reasons (though I
>>>> think that if they had SLAAC+RDNSS, many of the ones that currently
>>>> think they need DHCP would realize they don't).
>>> 
>>> I work with a lot of enterprises on large-scale DHCP. It's actually
>>> pretty common for them to want many more options set than just what the
>>> resolving name servers are.
>>> 
>> 
>> So? No one is arguing against complete DHCP implementation.
> 
> Actually quite a few people are. That's part of the problem. :)
> 

I haven't seen ANYONE make that argument in this thread or on this list.

>> I'm arguing for RDNSS implementation. They are not mutually exclusive.
> 
> No, but having the 2 things overlap for any given number of options
> makes implementors' jobs much harder.
> 

Not really.

You have a few choices, all of which are arguably valid. Pick your favorite
and implement that way:

	If you get either RDNSS or DHCPv6 DNS servers, but not both, the
	choice is simple... Use what you got.

	If you get nothing, the choice is simple... You have nothing to use.

	If you get both, then:

	A	Use RDNSS, ignore DHCP DNS servers
or	B	Use DHCP DNS servers, ignore RDNSS (probably the sanest default)
or	C	Merge the two lists and use any of the DNS servers provided as needed
			(My preference, but I'm sure someone will think it's a terrible idea for
			some reason).

However, in reality, an one of those three choices is pretty easy to implement and
would provide a functional environment for the end user.

>>> The other issue that comes up often in these discussions is the idea of
>>> administrative separation between the people who run the routers, and
>>> the people who handle things like DNS and DHCP. Most enterprises want
>>> this separation preserved.
>>> 
>> 
>> And they can have it with DHCP.
> 
> No, they can't. SLAAC is mandatory at this point in the process (well,
> RA is, but you get the idea).
> 

So? Why is that a problem? If you have a router, you have RAs. If you don't have
a router, you don't need RAs, actually.

If you have routers, then the RAs only HAVE to advertise default routers. They don't
have to contain any prefix information. If that's what you want, then do it that way.

>> What's wrong with making RDNSS available to the environments that want it?
> 
> Having 2 ways to provision the same thing makes implementors' jobs harder.
> 

Or easier.

I like having more ways to do things and picking the one that works best for the
given circumstance. It's not like you have to do both unless you are building
hardware or software to provide the services.

If you're talking about vendor implementation, then I don't have that much
sympathy. They've had more than 10 years to get this stuff written at this
point and it just isn't that hard.

>>> SLAAC was an interesting idea for the simple provisioning of dumb
>>> devices. Anything more exciting requires DHCP. It's very unfortunate
>>> that the anti-DHCP contingent is still fighting a battle that they lost
>>> 12 years ago, and delaying wider IPv6 rollout as a result.
>>> 
>> 
>> I completely disagree here. There are many environments where 99%
>> of the desktop users just need an address, DNS servers, and a default
>> route. In a lot of those environments, the guy running DNS is the same
>> guy running the routers. SLAAC+RDNSS is useful in those environments.
> 
> And those same environments could have gotten the same minimal
> configuration from DHCP, just like they do for IPv4 now.
> 

Right, but to do that, I have to actually provide a DHCPv6 server and upgrade
all of my Pre-Vista, Pre-10.7 systems, install DHCPv6 client software on all my
Solaris and Linux boxes, and...

Or, I could just use SLAAC.

>> Why is it that the DHCP-heads can't understand that pro-SLAAC is not
>> inherently anti-DHCP?
> 
> Maybe because the pro-SLAAC folks have waged war against a complete
> DHCPv6 implementation from day 1?
> 

I have actually waged war FOR the complete DHCPv6 implementation
since day 1, but I will point out that the DHCP heads haven't done themselves
any favors in their various efforts in the opposite direction, either.

At this point, it's time to drop the stupid wars and complete both protocols.

Both sides of these stupid wars are culpable, but I've never been on either one.

I'm in favor of completing both protocols and letting administrators do what they
want with each or both as they see fit.

>> I say implement it all and let each environment pick the solution that works
>> best for them.
> 
> ... and once again, that's a terrible idea because it makes
> implementors' jobs harder (speaking with my ACME Implementor hat on).
> 

Who cares. It's not that much harder and it's worth having for a variety
of reasons. DHCPv6 alone isn't going to make it. There's too much
support  out there for SLAAC and trying to block RDNSS support only
succeeds in creating additional opposition against DHCPv6 getting
routing information.

It's just dumb.

Time to end the war, implement them both and move on.

> If there are 2 ways to provision everything for v6, then as an
> implementor of end user systems I have to spend all the time to write
> code to support both. I don't want to do that. I'd much rather implement
> a DHCP that gives me a 1-stop shop for everything I need, and fall back
> on SLAAC for minimal configuration if necessary.

And I'd much rather implement a SLAAC that gives me a 1-stop shop for the
things I care about and ignore all the silly DHCP crap. So what?

The only meaningful difference between what I'm asking for and what
you are saying is that I consider DNS Recursors part of a minimal
configuration.

Implement it with RDNSS and we're in complete agreement. At that point,
I would consider SLAAC complete.

As to DHCP, I'd actually like to see it support:

Routing Information -- 0 or more instances allowed, each containing:
	128 bits -- Prefix Data
	8 bits -- Prefix Length
	128 bits -- Next Hop
	16 bits -- Preference/Metric/I really don't care what you call it.
		I also don't care if you make it 16 bits, or larger, either, but 8 bits is too small.

> In the early days of v6 the weaknesses of SLAAC were pointed out, as
> well as the advantages of DHCP. The v6 technorati continue to stay deaf
> to those arguments, and v6 adoption continues to suffer because of it.

I disagree. I will say that the DHCP heads have remained deaf to the
usefulness of SLAAC in a number of environments and the high overhead
involved in propping up DHCP where it is not necessary.

However, the best thing is that if we just finish RDNSS support in various
SLAAC implementations, add Routing Information to DHCP and it's complete.
If we do that, everyone except the stupid anti-DHCP and anti-SLAAC
crowd is happy and we can all move on.

Owen