"an equivalent approach is to extend RS/RA ..." Just FWIW - IMHO that would be better than the deprecation of RAs.
(Although I personally am OK with both RAs and DHCPv6 ... I think we just could use a cleaner definition of the M & O bits and how the hosts act on them) /TJ >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of >David W. Hankins >Sent: Friday, October 17, 2008 12:51 PM >To: DHC WG >Cc: IPV6 List Mailing >Subject: Re: [dhcwg] Brokenness of specs w.r.t. client behavior with M&O >bits > >On Fri, Oct 17, 2008 at 07:21:34AM -0400, Ralph Droms wrote: >> 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. > >Yes. I think it also suffices as a problem statement. :( > >> 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? > >It's not clear what YES or NO mean in this context. Yes to the first and no >to the second? No to the first and yes to the second? > >I think you mean by context only the first question. Someone needs a lesson >in "simple english." > >> 2. NO: How does the IETF want to change this consensus and how should >> the change process be conducted? > >1) How _should_ it work? >2) How do we migrate? > >3) Write it down in an RFC. > >> * 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 > >I'm not sure that specifying M/O fixed to 1 is worthwhile, but generally the >deprecation of the flags is the correct direction. > > >Because I type at 80wpm and can't be stopped: > >There is a larger deficit in IPv6 single-stack operations that this solution >puts us on track towards addressing. That deficit is today filled in dual- >stack networks by DHCPv4. I am going to continue with some "next work" >items I believe are mandatory for IPv6 single-stack's adoption; > >1) PIO-equivalent information in DHCPv6 replies (even if prefix length > is simpler for most implementations today). >2) Default gateway configuration in DHCPv6 replies. >3) Deprecation of RA, at the same time: >4) DHCPv6 rapid-commit support (from Solicit to a Reply) which > includes; > a) PIO-equivalents. > b) An indication for the client to commence SLAAC, and transition to > Information-Request for configuration ("NoAddrsAvail" in any > IA_NA, or similar (explicit perhaps) mechanism). > >This would cause there to exist a single protocol which RA/DHCPv6 should >have been from the very start (an equivalent approch is to extend RS/RA so >that RA is identical to a DHCPv6 Advertise, and additional messages >negotiate assigned addresses - I believe selecting >DHCPv6 and backporting SLAAC is more expedient). > >-- >Ash bugud-gul durbatuluk agh burzum-ishi krimpatul. >Why settle for the lesser evil? https://secure.isc.org/store/t-shirt/ >-- >David W. Hankins "If you don't do it right the first time, >Software Engineer you'll just have to do it again." >Internet Systems Consortium, Inc. -- Jack T. Hankins -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
