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
pgppZYOqdgkIJ.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
