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
