I suggest dropping "stateful" from the description because of the potential
for confusion inherent in providing a "stateful protocol for *other*
configurations" with "stateless DHCPv6" [RFC 3736].
This confusion arises from the unfortunate decision to differentiate RFC 2462 address assignment from DHCP-based address assignment by designating the former "stateless" and the latter "stateful".
You can't fix this by pretending it didn't happen. This terminology has been in use since 1996, so if we want to get rid of it now we need to spell the issue out letter for letter.
That
difference is more accurately captured in RFC 2461bis by describing RFC 2462
address assignment as autonomous.
People may think you're talking about AS numbers...
In any event, perhaps the best way to simplify the protocol would be to drop
the "O" bit altogether.
I don't believe any host implementation that's already out there really cares about whether the O and M bits are set. So I guess deprecating either or both wouldn't really make any difference to existing implementations, and obviously not to non-existing ones either. Thus the question becomes: what is it that we want to accomplish? One thing we absolutely want is to skip DHCP if we know there is no DHCP server. Whether or not we care in advance whether a DHCP server is going to give us address information, additional config or both is something I can't answer, maybe someone who implements IPv6 in hosts can.
However, I think we might be painting ourselves in a corner by assuming RA and DHCP will be the only discovery/configuration options we'll ever need. *NOW* is the last time we get to change anything in this regard without having to deal with backward compatibility. As soon as OSes are released with DHCPv6 support this will no longer be the case.
Another thing that we may want to consider is a few bits that indicate to hosts whether any address/configuration information has changed. This way, connected hosts know they should initiate a new discovery/configuration cycle, and hosts that have been disconnected for a few moments, hours (even days?) know the configuration they used when they were last connected is still valid so they can immediately start communicating while going through a slower d/c cycle to refresh the info (to be on the safe side). This should also avoid configuration storms after outages.
That is, make no attempt to control how a host goes about finding the additional configuration information.
So always try DHCP even if we know often there will be no DHCP server? This means people will have/want to turn off DHCP support manually to get rid of the delay and the unnecessary traffic. (IPv6 is already on the chatty side on the link anyway.)
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
