Thomas, IPv6 is IPv4 with longer addresses. Why would we want to make life more complex with more choices wrt starting DHCPv6?
I vote for 1. - Alain. On 10/13/08 11:40 AM, "Thomas Narten" <[EMAIL PROTECTED]> wrote: > 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. [...] > > 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. > > Thomas > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
