Re: DHCP failures (was RE: Do you want to have more meetings outsi de US ?)

[Jari Arkko <jari.arkko@piuha.net>]

Tony,

> It is very unlikely that a device would only implement DHCP

Hmm. So by "only implement DHCP" I presume that you mean
DHCPv6 + standard RA implementation, right? Reading on...

> so the only
> case to worry about is a device that does not implement DHCP (being a
> slightly more complex message exchange), while the network operator insists
> that their network only supports that.
>   
I think we need a better understanding of what the options
are to analyze this fully. From what I can gather, we have
talked about

1. Standard RA only, no DHCP at all (at least on v6 side; but in dual
stack nodes the IPv4 side may provide, for instance, DNS information).

2. Standard RA + DHCP (a couple of variants exist).

3. Standard RA + options for DNS discovery a la draft-jeong.

4. Standard RA but no prefixes + DHCP + extensions for prefix information.

5. DHCP + extensions for prefix information and default routers.

My understanding is that current hosts/networks and majority of
implementations
fall in categories 1 and 2. It would be very, very desirable that a new
solution tolerates such nodes on the other side. For instance, a host
that only does 1 arrives in a network that supports solution 3, 4 or 5,
what happens? If the network only supports 4 or 5, we have a problem.
Similarly, if a host that only does 2 arrives at the network that only
supports 3 we have a problem.

But to get back to your first statement "It is very unlikely that a device
would only implement DHCP", what did you actually mean? Case 2
is less likely than case 1. But from what you wrote afterwards it
seemed like you really meant that case 3 is much more likely to
appear in real-life than case 2. If so, I don't agree...

> I am not particularly concerned about that case. The reason a manufacturer
> would choose to not implement DHCP would be that it is a simple node (light
> switch or the like), and the most likely case is that the network operator
> that insists on DHCP would not want to allow these trivial devices anyway
> because they will not have the UI to deal with the rest of the
> DHCP-as-a-trust-anchor scenarios. Multi-purpose OSs will easily do both, and
> are most likely to need the ability to switch as they move between
> operational environments. 
>   

Mumble. I agree about the multi-purpose OSs, on the long term. But we
also need to support the current ones.


> Get over it and define both mechanisms. Let the operational community decide
> what they will and will not support in their deployments. If the device
> manufacturers want to deploy into networks that use DHCP-as-a-trust-anchor,
> they will have to implement DHCP. If that is not worth their time, the
> network needs to support a full set of services via the RA approach that is
> more likely in networks without an elite network management staff that likes
> to get paid well for their arcane knowledge of a more complex environment. 
>
> I am not saying DHCP is wrong, just that forcing a one-size-fits-all answer
> is wrong.
>   

As I said in my e-mail, having multiple solutions is not out of the
question -- but working out what this means for interoperability
is a requirement. And as always, the case for needing a new
way to implement something has to be made in terms of
tangible benefits.

Jari