Hello, Thomas. Thank you for your analysis and suggestions.
IMO, as long as M&O flags are configured correctly, there is no reason to ignore the bits. So, I do not think that one of two options should be selected and specified exclusively. What I am saying is that it will be ok if there is an option (configurable policy) in client side for user to run DHCPv6 client irrespecive of the flags because user can swith its policy to ignorance of flags in case that running client fails by misconfigured flags. (You can refer to the draft-ietf-ipv6-ra-mo-flags-01.txt ) As I discussed 71st and 72nd meetings, I do not think that RFC 2461/2462 are clear enough for implementors to be guieded. ; Specifically speaking, there are no considerations regarding how to revoke clients and handle with conflict flags from different routers. So, I think that we should discuss these issues as well as when to invoke clients. > Our options are: > > 1) We could ignore/deprecate the M&O bits and simply have any > client that implements DHCP invoke DHCP without even bothering to > see what the M&O flags say. I.e, the way DHCPv4 works today. > > IMO, this approach would work fine. Indeed, it has the advantage > that the client won't do the wrong thing due to misconfigured > routers sending out M&O bits with the wrong setting. The main > downside is that operators would have no way of signalling to > clients that DHCP isn't available and they shouldn't waste > resources trying to invoke it. In the past, there has been > endless(?) debate about how significant the "waste" would be. > > 2) We could restore the M&O bits, and tie DHCP invocation to the > settings of those bits. This is what 2461/2462 did, and was the > original model. But, there is still a number of choices to be made > here: > > a) Treat the M&O bits as SHOULDs, meaning exactly that. If the bits > are set, one SHOULD invoke DHCP, but it is NOT a MUST > requirement. If one choses (for whatever reason) not to honor > the bits, so be it, but it is not a protocol violation per se. > > This is the approach 2462 took, though it used lower case > shoulds. > > b) Treat the M&O bits as MUST. You MUST invoke DHC if they are set, > and it is a protocol violation to not do so (if you have > implemented DHC, i.e., you have a non-complient DHCP > implementation). > > c) One could also say one MUST NOT invoke DHCP *unless* the M&O > bits are set. > > Some people/operators wanted such behavior because they wanted a > way of indicating that no DHCP servers are present, and that > clients shouldn't waste network resources invoking DHCP (this > was asserted to be a potential issue on some types of wireless > WANs). > > Others argued that a robust client would be foolish to rely on > the proper settings of those M&O bits, as it could lead to > (unncessary) failures if routers were misconfigured, but DHCP > servers were available. [this leads back to the call for option > 1) above] > > In summary, the current specs are not clear on when a client should > invoke DHCPv6 and when not. That is broken and should be fixed. I also > suspect that it it less important *which* approach we adopt, than that > we do actually choose one and document it. Joseph -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
