On Mon, Oct 13, 2008 at 06:03:14PM +0200, Iljitsch van Beijnum wrote: > On 13 okt 2008, at 17:40, Thomas Narten wrote: >> Question: just when are they supposed to invoke DHCPv6?
This is essentially Joseph's question (one of them). He is stating, "I am an implementer, someone tell me what to do." He's even willing to write it down into an RFC so that the answer receives peer review and hopefully we have a clear and consistent (=interoperable) solution for other implementers. >> All the time? >> Only if the M or O bits are set? This simply isn't clearly >> defined. This is broken and teh IETF really needs to make a >> recommendation. > > Seems to me that this is simple enough: no bits, no DHCP. "Always" is not > an acceptable out of the box behavior. (!!!) Why? It seems perfectly fine to me, since the Solicits follow an exponential backoff. Further, it seems pretty clear to me that router solicitation is on a long path towards deprecation, as it is incomplete by design, so having DHCPv6 operate by default seems to me the best way to position current clients for the impending migration. > Then if there is M you do stateful DHCPv6, if there is O stateless. The > only problem would be if bot O and M are set. The other problem is when there is an A bit. Does M imply revocation of A? Some seem to think so; that A would only be set in this case for backwards compatibility with clients that lack DHCPv6 stateful support. The other other problem is when there are two distinct routers, having two distinct sets of prefixes (each representing a unique administrative domain, what Joseph understands (rightly?) to be a valid 'dual homing' setup), of which one, the other, or both are advertising inconsistent bit values (especially the M&O bits). The other other other... There are problems...there are corner cases in the penumbra cast by these "simple" designs' overlapping reach. They are not trivial, and they are almost certainly misunderstood by most. I like the idea that DHCPv6 should simply always be invoked. It casts a clear light, with very little shadow. -- 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
pgpFPKYB73UIQ.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
