I agree with Joseph that these should be combined and published. As for dealing with conflicting M&O, just XOR the received set. When the state changes from 1 to 0 (actually in either direction), after a random delay re-query DHCP to verify the lease time/config information. In a managed configuration, this would be a simple way to abruptly revoke outstanding leases, without allowing a rogue RA to drop existing state. The most the rogue RA would do is generate extraneous traffic to the DHCP server.
I would also like to clarify a point raised by Iljitsch; the reason the number of people complaining about too many changes is the same as those complaining about not enough, is due to both arguments being raised by the same people. Basically people are whining that their favorite change isn't happening, so no other change should be allowed either. This is essentially why we ended up with the state where both an RA and DHCP are required, rather than both mechanisms being self-contained and available to deal with different deployment scenarios. Some people demand central control, and they should have all the capabilities within DHCP to do so, while others want to minimize points of configuration to maintain, and they should also have a complete set of capabilities. While RFC 5006 fixes the DNS piece, there is no hint that SRV records allow completing that picture. FWIW: the people that are promoting the concept that IPv6 is just IPv4 with more bits, are simply refusing to recognize that they need to learn something new. They have tied their value in the marketplace to IPv4, and are trying to convince the market they are still relevant. Tony > Hello, Ralph and all. > > I would like to insert another option into the following list. > draft-ietf-ipv6-ra-mo-flags-01.txt > I am not clear why this WG document failed to proceed. However, I view > this document as nice base docuement since I think that it seems that > we do not have clear reason to deprecate M&O bits and it is more > desirable to let host's local policy override M&O bits in received RA. > > One thing I would like to point is that our draft > "draft-cha-ipv6-ra-mo-00.txt" just aims to clarify old > specifications(RFC2461/2462) and provide better guidance to > implementors. So, I would say that our draft can be merged with > "draft-ietf-ipv6-ra-mo-flags-01.txt" or extended to contain the whole > framework w.r.t processing the bits. > > Joseph > > > 2. NO: How does the IETF want to change this consensus and how should > the > > change process be conducted? > > > > There have been some suggestions for changes to the current > consensus > > behavior: > > > > * Deprecate the M/O flags; require that future DHCPv6 clients ignore > > the M/O flags; require that routers send RAs with M/O flags set to 1 > > * Revert to previous definitions and behaviors in RFC 286* > > * draft-cha-ipv6-ra-mo-00.txt > > > > > 2008/10/17 Ralph Droms <[EMAIL PROTECTED]>: > > I've been tracking this discussion about the M/O flags, which seems > to be > > going in several different directions. I thought it might be useful > to try > > to get some agreement on what needs to be done so we can focus on > coming to > > consensus on a course of action. It also seems like a small group of > > participants has gone pretty deep into some technical details, which > might > > be irrelevant depending on the consensus of the IETF. > > > > Here's a quick, informal survey to assess consensus about how to > proceed. > > Please reply to the list so we can focus our discussion. Thanks. > > > > 1. Is the following text an accurate summary of the previous IETF > > consensus on the definition and use of M/O bits: > > > > The M/O flags indicate the availability of DHCPv6 service for > > address assignment and other configuration information, > > respectively. The IPv6 specifications make no requirements on the > > behavior of DHCPv6 clients in response to the values of the M/O > > flags received in RAs. > > > > 2. Does the IETF choose to continue to accept this consensus or > should > > the definition of client behavior in response to the M/O flags be > > revisited? > > > > 2. YES: Is that consensus adequately described in the IPv6 RFCs or > should > > the IPv6 RFCs be revised in some way to describe the consensus > > requirements? > > > > 2. NO: How does the IETF want to change this consensus and how should > the > > change process be conducted? > > > > There have been some suggestions for changes to the current > consensus > > behavior: > > > > * Deprecate the M/O flags; require that future DHCPv6 clients ignore > > the M/O flags; require that routers send RAs with M/O flags set to 1 > > * Revert to previous definitions and behaviors in RFC 286* > > * draft-cha-ipv6-ra-mo-00.txt > > > > > > > > -------------------------------------------------------------------- > > 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 > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
