On Fri, 5 Nov 2004, JINMEI Tatuya / [ISO-2022-JP] ����� wrote:
Information Configuration Behaviour:
configuring other information excluding addresses through
Information-request and Reply exchanges
For full clarity, I'd suggest s/Reply/Information-reply/ above, as I think it was what you meant.
But your main point still stands, and I agree this is a problematic case. I'd first note I don't think it's a true-or-false thing; we're just going to define the most reasonable behavior, and this is its first step. The background of this statement is the dependency described in Section 6, which was originally stated in RFC2462, that if we invoke Host Configuration Behaviour we basically should not invoke Information Configuration Behaviour.
I'm not sure if I followed this background statement. My assumption has always been that 'host configuration behaviour' would always also include information config as well; a "less specific prefix" in a way :). But I may have missed some earlier consensus or did not read too carefully. (There would certainly be no way to stop Full DHCPv6 client from getting back all the ancillary information in addition to the addresses, right?)
As you pointed out, I don't think this restriction is always reasonable. But when we wrote revision 01, we basically tried to follow the original sense of RFC2462, and we could not find a better behavior. Hence the current statement.
OK..
But if we (the wg) can agree on being more flexible, I can think of a better approach. For example, if a host which sets M-Policy to 1 cannot get any Advertisement to Solicit messages for some period, it may make sense to fall back to Information Configuration Behaviour as you indicated.
Hmm, not maybe as good as I'd hope, but that's a start..
One possible problem of this approach is that RFC3315 requires the client to send Solicit forever, until it gets an Advertise or Reply, by specifying MRC and MRD being 0 (Section 17.1.2 of RFC3315). So, at least protocol-wise, the fall-back behavior does not (or may not) conform to the RFC.
Not necessarily: there is nothing in the spec which would prevent sending *additional* messages, e.g., an information-request, and in parallel, also continue sending Solicits forever, right? :-)
I'd guess that would be the 'easiest' solution to this particular problem. Would the client get any feedback from the server if the server did not support solicit, which could be used to trigger sending a parallel information-request, or is the timeout the only option?
But, if we can also agree on modifying RFC3315 and RFC3736 a bit, I can even think of a bit smarter approach:
- DHCPv6 servers that only support Information Configuration Behaviour should also support the Advertise message and the IA_xxx options, but it always return an empty Advertise message to Solicit with a status code being NoAddrsAvail. (This is a modification to RFC3736) - If a DHCPv6 client that supports both Host/Information Configuration Behaviours only receives such an Advertise message, it MAY fall-back to Information Configuration Behaviour. (This is a modification to Section 17.2.1 of RFC3315, which requires the client ignore such Advertise).
Although the first modification requires additional implementation complexity to DHCPv6 servers that only conform to RFC3736, the resulting behavior is still "stateless", and in that sense, should be lightweight. So I think it's acceptable.
These might be acceptable as well, but then there could still be implementations which do not deal with this, and you'd have to depend on both ends getting it correct; it would be best if just one end would be enough, like above.
Anyway, there is no doubt that we need further discussions on this point. I'm open to other ideas.
Certainly. Perhaps this could be brought up in DHC wg as well? It seems that the most important discussion in this WG is what we consider the RFC2462 interpretation of M/O behaviour to be, and if it's inappropriate, whether we'd like to modify it.
Presumably, initiating DHCPv6 requires running a non-trivial user-land process. Hence, I'd dare to say that the transitions are a bigger problem with M/O flags, as has already been discussed a bit in security considerations.
Thus I'd like to see some further text, e.g. 1-2 sentences, describing why M/O transitions are a bigger problem than other inconsistent information.
I think I said this before, but anyway, personally I'm not really sure if it's a good idea to mention such an implementation-specific thing in a document describing protocol behaviors. However, I don't oppose to that idea now that this is in an Appendix.
I share the concerns, but being in the appendix, and already comparing the situation to something else (which may not be comparable in many situations), the text seems called for..
-- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
