Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

[Lorenzo Colitti <[e-mail]>]

On Thu, Oct 24, 2013 at 2:56 PM, Victor Kuarsingh <[e-mail]> wrote:

> It's quite obvious that in environments like sensor nets, home nets and
> other places, SLACC/RAs supply significant value.  In other areas, like
> an operator access network (edge element addressing), it's a different
> case.  Operators, such as the one I worked or, would never (rarely?) let
> an element auto-configure itself onto the network.
>

Right - and there's the rub.

It seems to me that we have two different ways of configuring things (RA
and DHCPv6) that don't differ in functionality but differ in how suitable
they are for different environments. One mechanism (RA) is dynamic,
self-configuring, serverless and fate-sharing, and the other is static,
operator-controlled, and centralized.

Operators and enterprises want the one they feel gives them more control
and are willing to provision the infrastructure to make it reliable (e.g.,
centralized configuration repositories; DHCPv6 servers and relays; VRRP so
they don't need fate-sharing, etc.). But the one that offers more control
falls over in home networks, because the infrastructure to run it is either
not available or unreliable: there's nothing anyone can do to make the
DHCPv6 server (or the DHCPv6-provided router or DNS server) keep working if
the user has unplugged it or tripped over the power cord, and there's
nothing that can withdraw a stateful DHCPv6 lease if the original server
has been unplugged, because nobody knows the nonce any more.

I think we need to accept that neither protocol is sufficient in all
environments. We have to realize that DHCPv6 just isn't suited to dynamic,
self-organizing environments like home networks. We can keep hacking it
with more semantics like unsolicited updates, but at the end of the day
we'll simply end up with something that looks like RAs - multicast updates
to everyone on the link (equivalent to multicast RAs), configuration
requests/replies (equivalent to RS/RA), and so on. Then we'll have to
implement DHCPv6 guard to stop rogue servers, and even then there will be
no fate-sharing with routing. On the other hand, RA doesn't offer the
wealth of different option types that DHCPv6 has, and while it's possible
to do fine-grained configuration with unicast RAs, today most RA
implementations don't support fine-grained per-client configuration via
unicast RA or "RS relaying" to a central server to fetch per-client RA
information.

I see two possible ways out of this:

1. Decide a clear split between what goes into RA and what goes into
DHCPv6, and then stick to it. For example, we could say that configuration
information that is required to obtain basic connectivity on a network must
be available in RA so it can be dynamically updated and shares fate with
routing, and that everything that's not strictly required for the host's
connectivity can go into DHCPv6. I don't know if it will be possible to
draw a line here. If operators insist that DHCPv6 by itself must be
sufficient, then we have no choice but to duplicate information.

2. Attempt to say that RAs and DHCPv6 are simply containers and propose a
unified option format so we can have the same options in both of them. I
know this was already proposed once and was shot down, but I wasn't around,
so I don't know why. (CCing a few people who might know).

Cheers,
Lorenzo