On Thu, Oct 23, 2008 at 08:15:54AM -0400, James Carlson wrote: > Unless your DHCPv6 server box also happens to be an IPv6 router for > the prefix in question, I don't think you should be trying to do > anything with RS/RA messages.
I agree completely, I would rather not ever transmit an RA. But so long as 'successful DHCPv6 configuration' relies upon 'successful RA configuration' (consistent configuration or not; they both have to succeed to final configuration state, independently), then I can see few alternatives. We can either make DHCPv6 succeed indepedently (by replacing RA with it), or we can make DHCPv6 servers transmit RA, hoping to approach some certainty the client is configured. "Neither", decreeing this situation to be broken by design, is not an option I will entertain for the long term. We like to sit in the IETF's ivory tower and glower over interoperation failures. Those are clearly the problem of implementers, operators, or both, who could not possibly understand the purity of the ideals which our protocols cling to. I think when the network is playing host to a hospital's infrastructure, or an army base, you take a different view. That corner case that you decreed broken by design may look different from the point of view of a man in a hospital bed, or a soldier. But even other people's lives don't seem to have that much thrust in getting the seriousness of any problem across. It is, after all, not your life on the line. So, perhaps what I refer to as the 'xkcd criteria' is a better way to express and understand what should be the primary motivation of protocol design; "When designing an interface, imagine that your program is all that stands between the user and hot, sweaty, tangled-bedsheets-fingertips- digging-into-the-back sex." [1] > How can the system "default" to using /64 in the absence of any router > prefix information? It was actually pretty easy, and there have been no interoperation failure reports. Protocol design ideals don't matter nearly as much as people do. > I understand the pragmatic part of doing that (broken configurations > with no advertising routers will still "work" well enough for local > destinations that users won't be upset), but I think it misses the > bigger picture. It isn't a misconfiguration issue. It is an outage resilience issue. I am unwilling to accept that DHCPv6 breaks when the router is down. Simply: That is an unacceptable delay according to the xkcd criteria. If it were merely a misconfiguration issue, we'd find some way to report the misconfiguration so it can be solved quickly (again supporting the xkcd criteria). > that. The lack of a prefix length and routing information in DHCPv6 > is one of the things that is done *better* than with DHCPv4, because > there's just one source of authoritative information. I am also after one source of authoritative information. I do not think you are correctly analyzing RA+DHCPv6 as being "single source". [1] http://xkcd.com/196/ (image tooltip quoted) -- 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
pgptWH8GOkMzH.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
