On 27-mei-2005, at 18:16, Bernie Volz ((volz)) wrote:
1 1 send Solicit send Information-Request
But what happens if the stateful server is down and stateless is
running?
Buy more servers?? Some solutions are simple. :-)
Though I would never recommend that a link have both of these
types of servers.
I would assume that both types of servers wouldn't existing
alongside. AFAIK, there is no reason that a server that does full
DHCPv6 couldn't/shouldn't do answer stateless DHCPv6 queries as well.
Only when there is no need for stateful DHCPv6, it would make sense
to run a light-weight stateless server. For instance, on a
residential type router.
We could easily resolve this by adjusting the DHCPv6 protocol as
proposed (ie, stateful and stateless servers can respond to Solicit
with
Advertise with just other configuration parameters).
Wouldn't that put RFC 3376 out of business?
We really want to communicate three states in terms of the DHCPv6
service available on the link: No DHCPv6, Stateful DHCPv6, and
Stateless
DHCPv6 -- not 4.
Ok, I agree with you that those three are needed. I also think the
fourth one is slightly useful, but that one isn't very imporant.
Do we all agree that no DHCPv6/stateful DHCPv6/stateless DHCPv6 are
all useful?
Note that this says nothing about what a client
supports (if the client can only do stateless, that's all it can do!).
Right.
Clients would run DHCPv6 unless the "No DHCPv6" is set.
:-)
So, perhaps we should deprecate M=1 *AND* O=1. Clients should
always run
DHCPv6 if EITHER M = 1 OR O = 1. If M=1, run stateful (if supported,
stateless otherwise). If O=1, run stateless (if supported).
It already says in RFC 246x that O = 1 is implied when M = 1. I.e.,
the useful combinations are:
M = 0, O = 0
M = 0, O = 1
M = 1, O = x
In any case, I would still fix the DHCPv6 protocol to allow Advertises
to return other configuration parameters when no addresses are
available
AND to require stateless DHCPv6 servers to support Solicit (with
Advertise with just other configuration parameters).
I'm offering no opinions on that one.
I still believe deprecating the 2nd bit (O) is better.
Disagree for various reasons. The way I see it, people may be
interested in implementing clients and servers that just do stateless
DHCPv6 (RFC 3376). Sure, it's probably doable to make any combination
of stateful/stateless server and stateful/stateless client do
something reasonable, but I'm convinced that knowing in advance (by
virtue of the M = 0, O = 1 combination) on both the server and the
client that we'll be stateless makes for much simpler implemenations.
It also makes troubleshooting easier: with the O bit present, the M
bit is a reliable indicator whether or not hosts will take addresses
from a DCHPv6 server. Without the O bit the M bit is overloaded and
the only way to determine whether the DHCPv6 server also supplies
addresses (and possibly messes this job up) is by looking at a DHCPv6
interaction.
Predictability is a highly regarded commodity in operational
environments.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
