On 27-mei-2005, at 15:18, Bernie Volz ((volz)) wrote:
Why?
Well, why not?
I'm not too familiar with the internals of DHCPv6, but I can imagine
that it would be moderately useful if a client knows in advance
whether it's going to do full DHCP and may receive stateful
information, or it's only going to obtain some stateless information.
I'm not sure if we would be designing this today that we'd include an
O bit, but it's here, and using it in this way comes reasonably close
to its original meaning AND may provide some benefits, so why go
through the trouble of doing something radical now?
If we update the DHCPv6 protocol to allow "other configuration"
options
to be returned in an Advertise for a Solicit, Information-Request/
Reply
and Solicit/Advertise are then essentially the same in a stateless
DHCPv6 environment (though the Solicit does require a client
identifier
and likely may require a IA_* option).
So we need to do more protocol work in order to send larger packets
so we can get rid of a bit that doesn't bother anyone? Hm...
I think if we have two bits, we'll just be back to some of the edge
conditions (what if M is set, but O isn't, etc).
I think I addressed that in my message yesterday, for the most part.
If we ignore all other input and just look at the bits, then:
M O stateful clients stateless clients
0 0 do nothing do nothing
1 0 send Solicit do nothing
0 1 send Information-Request send Information-Request
1 1 send Solicit send Information-Request
The compelling advantage here would be that it's possible to run a
server that only understands stateless DHCPv6. (I'm assuming that you
need a server that implements full DHCPv6 to answer Solicits even if
it otherwise only serves up stateless information.)
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
