RE: IPv6 Deployment for the LAN

["TJ" <trejrco () gmail com>]

> > 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