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

[Owen DeLong]

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

> On 9/10/2012 5:25 AM, Gert Doering wrote:
>> Hi,
>> 
>> On Sat, Sep 08, 2012 at 12:42:17PM -0700, Doug Barton wrote:
>>> 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.
>> 
>> You seem to have misspelled the "anti-SLAAC contingent" in that sentence
>> above.
> 
> The original promise for SLAAC was that it would be route and prefix
> only. Everything else would be DHCP. As far back as 12 years ago people
> like me were saying that we would like to have a DHCP-only solution, and
> that the problem with address and route only was that it was unlikely to
> meet the needs of most real world end user systems. We were told to get
> with the program, this is a new protocol, needs new ways of thinking, etc.

OK... So what. Mistakes were made.

We are where we are now and focusing on the mistakes of the past does
not help us move forward.

The best way forward from here is to acknowledge that there are places
where there is value to SLAAC+RDNSS, places where there might be
value to SLAAC without RDNSS, and places where DHCP has value.

There is value to having ROUTE information options in DHCP, whether
the IETF purists like it or not.

So, the best thing to do is make SLAAC with optional RDNSS support
available and make DHCP available and add ROUTE information options
to DHCP. I'm fine with adding a DHCP-only option as well, but I have
to wonder why bootstrapping DHCP with an empty RA is really a
problem?

Seems to me that an empty-RA bootstrap for DHCP provides a much
cleaner way to inform systems of which configuration mechanism
is preferred on the local network and provides maximum operator
flexibility with minimum confusion at a relatively low cost.

> Twelve years later I've been thoroughly proven correct on both counts,
> and yet the v6 true believers in the IETF are still blocking a complete
> DHCP solution.

If you want to continue to focus on the "I told you so" aspect of the
situation, there's plenty of that to go around and you should go do
it with a bunch of IETF purists to keep them busy while the rest
of us look at getting real work done.

> 
> I'm not anti-SLAAC, never was. I think it's an interesting idea for
> provisioning low-end devices that only need to talk to other low-end
> devices on the same network. But what was apparent from the very
> beginning was that RA was never going to meet the needs of the kinds of
> end-user systems that have real humans sitting behind them. This is true
> both on purely technical grounds due to things like search domains,
> etc.; and also on "layer 9" grounds due to the administrative separation
> in most large'ish enterprises between the people who run the network and
> the people who run DHCP.
> 

With RDNSS, SLAAC actually meets the needs of 99+% of residential
and SMB applications. It's much less overhead than DHCP and offers
some real advantages in terms of allowing them to do easy renumbering
and some other tasks which are not so well supported in DHCPv6 without
really understanding a lot about how DHCP works in IPv6.

>> But that's precisely why the IETF is not going anywhere: folks like you 
>> advocate DHCP, and are not willing to accept that other people might be 
>> happy with SLAAC+RDNSS, effectively blocking both.
> 
> Yes, I was opposed to RDNSS, for the same reasons I have been repeating
> for 12 years now. It's not enough, and it's a slippery slope. However,
> my being opposed to RDNSS hasn't done 1 tiny thing to prevent
> implementors from going forward with a standard that already exists.
> It's the market that has spoken on that point, bearing out the truth of
> what I have been saying all along.

It is enough to bridge the gap between the current state of SLAAC which
supports maybe 3% of use cases and the ability to address something
north of 90% of use cases without needing DHCP.

OK, it's not a good fit for your organization or the sites you manage.
Got that. Don't use it.

It's actually not a slippery slope and slippery slope arguments don't usually
carry much weight anyway. I can't imagine wanting to put anything else
into RDNSS/SLAAC because at that point, you're approaching enough
implementation overhead that you might as well just go with DHCP if
you need the additional complexity.

RDNSS is fait accompli in terms of being documented and blessed by
the IETF. Attempting to dissuade vendors from implementing it will
only serve to disadvantage those vendors in a world that wants those
features.

You'd do much better to focus on getting the things you want added
to DHCP and a bunch of people here are even willing to help push
for them.

Owen