Re: IPv6 Deployment for the LAN

[Nick Hilliard <nick () foobar org>]

On 18/10/2009 11:05, Nathan Ward wrote:
> Remember RA does not mean SLAAC, it just means RA.

This is not ideal because two protocols are being mandated instead of just 
one: RA for client-side autoconfiguration and DHCPv6 for everything else.

This is pointless.  We have a good working model in ipv4: namely, the 
Joesoap in charge of the LAN decides what addressing parameters are to be 
used on the network, and it all uses a single protocol: dhcpv4.  you can 
filter it out from rogue clients using dhcp-guard on a decent switch, and 
everyone is happy with it.

However, in IPv6, we are being told that this is not good enough: that 
there need to be two protocols, one of which tells the client enough 
information about the network so that the client can choose its own 
address, route packets but not enough to allow DNS (i.e. functional 
internet connectivity).  So then we decided that we needed another protocol 
to give the client everything else that it needed.  And in order to avoid 
egos from tripping over other egos, each camp kept on their own turf: 
dhcp6 was hobbled to the extent that it couldn't feasibly be called a host 
configuration protocol (no default route, no address assignment and no 
subnet size options), and the RA folks at least initially tried to keep 
useful functionality out of the RA spec.

Or at least this was the plan.  Of course, it was a completely broken plan 
for a variety of reasons, including:

- there were two protocols required for stateless network management 
instead of one
- we already had a really good working model in ipv4
- address selection was performed by the client, not the administrator
- we found out in the early 1990s with RIP that you need to be careful 
about announcing default routes, and because you now have to protect 
against two protocols instead of just one, this makes things more difficult
- no-one thought it might be useful to ask the operators what they thought 
about using two protocols instead of one.  Did it ever occur to the people 
defining the standards that most LAN operators are not particularly smart 
people, and that they would have trouble with this?

So, as a result, RA grew about 6 arms and 8 legs (most of them the 
left-side variant), and the DHCPv6 camp continued with their diplomatic 
tip-toeing around the RA camp until one day, someone threw King Looie 
Katz's tail into the dirt: no longer were Hooie, Fooie or Kooie Katz going 
to play nice!  So, now we have protocol proposals in the pipeline that will 
enable DHCPv6 to be sufficient to functionally run stateless address 
configuration rather than to continue to be nothing more than a necessary 
headache.  Hooray!

Of course, there are still several people in ietf-land who think that this 
is all a terrible mistake, and that RA and DHCPv6 should have been 
complementary to each other.  To these people, I will be happy to listen to 
their opinions on condition that they do two things: 1) agree to filter out 
all ethertypes except 0x86dd on their laptops at ietf meetings (and spare 
me the platitudes that they aren't responsible for what the vendors 
implement) and 2) attempt to run a large IPv6 multi-lan network with 
current operating systems and switching gear for a period of one month.

Most seriously, there's not nearly enough eating-one's-own-dog-food going 
on here.

So, if someone in protocol standards-land had actually asked the operators 
what they wanted, they would have been told that they needed a protocol 
which took decisions about addressing and configuration away from the 
client.  You plonk your computer on a lan, and you are told what address to 
use and what configuration parameters to use.  You don't start inventing 
your own, because honestly, it's a pain to manage.

I appreciate there are conflicting views on this particular point;  I've 
heard the arguments and remain entirely unconvinced that RA + anything 
makes for a better stateless host configuration protocol than dhcpv6 will, 
or ought to have from day one.  Meanwhile, because of all this pointless 
bickering about whether dhcpv6 should have had this or that or the other 
option, we're 13 years down the road since ipv6 was defined and we still 
don't have what I would consider to be a sane and fully standardised host 
auto-configuration model.

I find it amusing that sane autoconfiguration was supposed to be one of the 
primary selling points of ipv6 in the first place.

Nick