On Tue, Oct 14, 2008 at 11:55:06AM +0200, Iljitsch van Beijnum wrote: >> Why? It seems perfectly fine to me, since the Solicits follow an >> exponential backoff. > > See my earlier emails.
Why? They don't answer the question. If we apply the thinking that all multicasts must be avoided, then there are a great many protocols outside of DHCPv6 to which we must also direct our attention. Your earlier emails have not convinced me in the slightest. >> Further, it seems pretty clear to me that router >> solicitation is on a long path towards deprecation, > > Where do you see evidence for that? I haven't seen this. History. We had IPv4 ICMP Router Discovery. It sucked, I remember it (but it only sucked less than manual configuration, which is what we had before that). We had RARP at one time in IPv4 as well. It also sucked less than the manual configuration effort, but again it still managed to suck more than later efforts. The development of IPv4 host configuration was a long line of finding answers that sucked less than their predecessors. RA, despite its subtle differences, sucks in precisely the same ways. It fails to suck less than DHCPv4; consequently, anyone who runs dual stack today uses DHCPv4 to configure IPv6 (using IPv4 nameservers)! For anyone to see IPv6 seriously as a native (single stack) client environment, it will have to suck less than or equal to IPv4. That won't happen so long as IPv6's framers continue to live in 1985 [1]. There are reasons that IPv4 networks today are built using VRRP default gateways, and that DHCP is the singly used host configuration protocol, by a wide margin over others. It is not because "the operators just don't understand how cool it would be if they did everything differently." It has been a dialogue between IETF protocols and network operators, and in starting from scratch with IPv6, the IETF has made the mistake of throwing out the meaningful results of this dialogue. > And even if people wanted that, I don't think it's possible to get to a > situation without RAs from the current situation, where the majority of > systems _only_ understand RAs, apart from manual configuration. It is true: IPv6 was a protocol born with a silver migration in its mouth. My position is that always engaging DHCPv6, despite RA contents, puts is in a migrate-able position. >> so having DHCPv6 operate by default seems to me >> the best way to position current clients for the impending migration. > > The important thing is that we don't just decide what WE think is best but > allow everyone to run their networks the way THEY want. Today, many people > do this without DHCPv6. Presumably, more people will want to use DHCPv6 as > implementations get better, but I don't see this ever reaching 100%. I don't see how running DHCPv6 without any RA input keeps anyone from building the network they want. Even in IPv4, you are still free to use RARP. > If you don't have such clients then you can set the A bit to 0 if you want > DHCP only so this is a reasonable line of thought but do you really want to > have three different types of hosts on your network: No. I only want one (precisely one). All clients should behave consistently (=compatibly). >> 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. > > That's why it's necessary that the behavior is simple and predictable but > still flexible so that something reasonable happens in all cases. The error in your reasoning is in thinking that "forked paths will simplify the network." It complicates it. We need a single place to look for host configuration, not two and certainly not three. Because RA's services are a subset of what is made possible with DHCP, it is appropriate to select the service that fulfills the complete requirements. This means either to proceed on a long-path to deprecate RA and select DHCPv6, or to extend RA to fulfill the complete requirements (turning it into a DHCPv6-alike in the process), or to scrap both and create a new single protocol. These are our real choices. I've chosen one which I believe is most expedient: select DHCPv6. What is inappropriate, is to contiue to follow a forked path. Clients will have to cross-implement along both lines because they can not dictate into what network they will be thrust. They have to implement 'all' not 'either/or'. This is the most severe kind of complication imagineable. Light sources cast shadows. Multiple light sources cast overlapping shadows; what we call 'penumbra'. True simplification for host configuration will come only by reducing the number of sources of information. So, I am confident in my position that RA will be deprecated in the future, and that we should do what we can today to plan for its absence. [1] - http://www.youtube.com/watch?v=gVlNIUhHUI8 There was music still on MTV! -- 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
pgpElY3L0yHwp.pgp
Description: PGP signature
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
