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