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.
Um, DHCPv6 does configure the client - perhaps not until the +M or +O option is recieved.
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.
And RA Guard will fix it for IPv6. Did we have DHCP Guard @ day 1?
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
Incorrect, DHCPv6 can assign addresses.
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
Perhaps, But I submit that "good" and "working" do not mean "ideal".
- address selection was performed by the client, not the administrator
If SLAAC is chosen, yes.
- 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?
With the addition of RFC5006, you can actually choose just one (once hosts implement it). Just not the one you seem to favor.
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!
And I am OK with all that as well, although THAT also complicates scenarios for implementers. (Now hosts will need to support two discrete host-configuration protocols that actively step on each others' capabilities).
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.
I'll filter all non-0x86dd if you filter all non-0x800. And I will be more successful as you are then blocking ARP :). The other missing piece of that is most of us aren't going "IPv6 ONLY" just yet - so if we need to rely on IPv4 for a bit longer that is, while far from optimal, atleast "kinda OK". (e.g. - cheating off of IPv4 for DNS).
Most seriously, there's not nearly enough eating-one's-own-dog-food going on here.
Totally agree there!
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.
It is still the router, a piece of managed infrastructure sending out the information - not like we are encouraging hosts to make up their own prefix info here ... and hosts choosing the low-order bits shouldn't matter that much.
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.
Well, obviously not _fully_ standardized as we are still adding stuff ... but I would argue the sanity part is OK. And again, it still (esthetically and architecturally) seems to make a lot of sense for the router to send out information about the router. With the added bonus of "it can and does work today", regardless of the arguments for/against it. /TJ