Hello, Thomas and Ted. Please see my inline comments.
<snipped from Ted's posting> On Sep 18, 2008, at 6:01 AM, Thomas Narten wrote: >> Perhaps this point might be a major conflict. As we both know, >> consecutive DHCPv6 SOLICIT messages are sent exponentially >> back-offed if no valid replies are received within timeouts. Since >> this always holds, I would like to ask you why M/O flags should not >> be deprecated. > > Because the WG doesn't feel that the flags were so problematic that > they needed to be deprecated? There certainly has been concern that > existing implementations that do support the M&O bits should not > become non-complient through deprecation of the M&O flags. Why would they become non-compliant? I think it's because DHCPv6 clients would not attempt to discover DHCPv6 servers if the managed bit wasn't set. So there's an easy solution: deprecate the bits, but require that both the M and O bits be set in all RA messages. (Joseph) What if DHCPv6 service is not provisioned for the link? For existing implementations which do not provide user interface for manual(or static) configuration, iit might be desirable that M/O bits in RA messages should be cleared. > IMO, if we were to start over knowing what we know today, I'd be in > favor of not having the M&O bits at all. But we are not starting from > scratch... It's never too late. It's simply unclear what the M&O bits do right now. By leaving this lack of clarity, we practically guarantee that interoperability problems will arise, because the RFCs provide no guidance on how the implementor should deal with transitions or conflicts in M&O bit settings. (Joseph) I agree. I pointed out that DHCPv6 client in the Vista behaves poorly when there exists conflict in M & O bits in RA messages from different routers int the Philadelphia meeting. >> Sure, this would work. Though one can question whether the additional >> implementation complexity is worth the benefit. Deprecating M&O would definitely be simpler. > If your real concern is that DHC continues to be invoked forever (even > when no DHC servers are available), wasting network resources, IMO, > the better place to make changes is in the DHC specification. I.e., > the DHC client should backoff more aggressively and "poll" for the > appearance of a new server very infrequently. I don't know what Joseph's objections are, but my reason for being interested in this is that I see a potential dead zone in the protocol that clients can get into but can't get out of. Because DHCP relay is required for a solicit to go off-network, if no DHCPv6 infrastructure exists at a site, there will be no concentration of solicits on a central server, and the number of packets per second will be fairly small even on a crowded network. So my reason for wanting to address the problem Joseph is talking about is simply that as it stands, there is no clear recommendation for implementors as to how to handle transitions, and I suspect that some implementations will wind up doing the wrong thing, because in fact the implementor may not even think about the problem Joseph has raised. I would actually prefer your solution to Joseph's: just deprecate the M&O bits, and require that they be set on to prevent whatever old implementations are already deployed from failing to attempt DHCPv6. But if the IPv6 WG does have consensus that DHCPv6 should not happen if the M bit isn't set, and that DHCPv6-lite shouldn't happen if the O bit isn't set, then I think something is needed to address the concern that Joseph has identified. And if the IPv6 WG cannot reach consensus on this point, I don't think that's a reason to leave things as they are, because things are broken as they are. (Joseph) Ted, I appreciate your opinion. Thomas, I would like to request your answer on this point. The main reason, I think, that the DHCPv6 WG doesn't have a consensus on this is that the RFC that's supposed to address this problem is not a DHC RFC. > This would be appear to be as simple as changing the value of > SOL_MAX_RT: > > Parameter Default Description > ------------------------------------- > SOL_MAX_RT 120 secs Max Solicit timeout value > > See Section 17.1.2 in RFC 3315. This would make DHCPv6 recover very slowly from a server outage, and I don't think it's necessary - 120 seconds is a pretty long time. If you have 200 clients on a link, that's fewer than 2 solicits per second. However, I am definitely sympathetic to those who would prefer not to see these solicits at all. (Joseph) Agreed. Joseph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
