On 07/16/2011 07:02, John C Klensin wrote: > > > --On Friday, July 15, 2011 15:39 -0700 Doug Barton > <dougb@xxxxxxxxxxxxx> wrote: > >> To address your concern about whether or not vendors are paying >> attention to this discussion, and why historic status is >> substantively different than "off by default, no really, OFF >> BY DEFAULT," I'll put my FreeBSD developer hat on for a minute >> and tell you that we definitely do pay attention to stuff like >> this, and whereas we already have it off by default (and have >> for some time) moving it to historic gives us the cover we >> need to remove the code at some point down the road when that's >> appropriate. That's an extremely important distinction, and >> one of the reasons that as a "member" of v6ops I ultimately >> came down in support of the 2-document strategy. > > Doug, > > And that is exactly where we agree on the effect and disagree > about whether it is desirable. Right. > I think there is consensus that 6to4 is dangerous unless > carefully and intelligently configured and that is certainly > should not be turned on by default. If anyone has argued > against that position, they are in a tiny minority. > > Similarly, I think there is consensus that following the advice > in the "advice" document makes 6to4 much safer to use, even if > not entirely risk-free (I contend that there is no "risk-free", > perhaps as a corollary to the principle that, if we invent > something idiot-proof, someone will invent a better idiot). So > there should be no question about the desirability about > publishing the content of that document. Agreed so far, especially about the idiots. :) > The question, as far as the "advice" document is concerned, is > how to get the message out most effectively, most clearly, and > on as timely a basis as possible. I think that having it > "update" the base 6to4 specs is important because that is how > the RFC Series is threaded. Without that, there is an increased > risk of people finding the 6to4 specs and implementing them > without ever seeing the "advice" piece (just as, even with the > "updates"/"updated by" pointers, we still hear about new TCP > implementations based on RFC 793 alone). For the reasons > discussed above, I don't think anyone would find that outcome > desirable. You know the subtleties of the various document tracks infinitely better than I do, so I'm not even going to try and debate you on that. OTOH, I find the idea of someone implementing 6to4 from scratch at this point highly unlikely. I also think that declaring it historic would make the scenario you describe that much more unlikely. [snip] > But, while some people have argued that 6to4 has caused so much > damage by being misconfigured that it should, presumably as > punishment or to create a public example, be eliminated entirely > as an option My perspective, which I've described at length many times now, is not that 6to4 needs to be punished, but that the widespread deployment of IPv6 is being harmed as a result of the negative user experience that it creates for the majority of its users (particularly the unintentional ones) and therefore the network as a whole is better off if it goes away. To summarize my main points once again (since you seem determined to reopen the debate on 6to4's utility): 1. There is next to zero IPv6-only content at this time. 2. Therefore the number of people who actually *need* IPv6 is so close to zero as to not be a factor. 3. Of the tiny number of people that actually do need IPv6, there are plenty of other tunnel options. 4. By the time that there *is* IPv6-only content the market will have sorted out access for the average user. Thus, 6to4 hurts way more than it helps at this point. Furthermore you have the huge problem that neither end of the 6to4 equation has *any* motivation to fix it. The ISP side can simply block tunnels (or even simpler, ignore the problem). The content side can simply not deploy AAAA records. I do think that the -advice document is a good thing, and for those that care I think it's great that the IETF is going to help them out. But all statements of the form "all we need to do to fix 6to4 is X" are non-starters because the people with the ability to actually fix it are not going to. > -- for FreeBSD users, the exact effect of your removing the code -- To be clear, I didn't say that we *will* remove it, only that making it historic gives us that opportunity at some point down the road *if* that becomes appropriate. > I haven't seen nearly as strong as case, or > anything even close to consensus, for that position. If it was > actually what the community believed, then the "advice" document > would be a complete waste of time except possibly as a > retrospective on how 6to4 might have been better specified (a > retrospective that we would want to publish as (immediately) > Historic). Once again repeating myself, but I disagree. The idea of publishing both documents represents a fine compromise between the 2 extreme positions, and allows those who want to continue using it to do so in the best way possible. It's also not the first time the IETF has published a document that says, effectively, "We don't think you should do this, but if you're going to do it anyway, here's how to do it right." > If the thing is still useful, even in limited circumstances and > used correctly, then the IETF should not provide you with > "cover" to remove the code because it is not in the best > interest of the community for you to remove the code. Might > both your removing the code and moving 6to4 to Historic in the > future be appropriate? Sure. I also look forward to the day > when we can move IPv4 to Historic (just as the various > specifications that make up NCP should have been moved years ago > if we paid attention to that sort of housekeeping). So the debate is on the timing. I (and others) think that the time is now. My opinion is that there is also a pretty strong community consensus that the time is now, modulo a very vocal group of people who do not. But fortunately I'm not the one who has to make the decision about what there is and is not consensus for. :) [snip] > FWIW, I note that there are at least a few other things that > shipped for years with FreeBSD that could cause a lot of damage > if misconfigured and were hard to configure correctly, but were > nonetheless included in the code in version after version and > even were enabled by default. Getting rid of them would not > have required any IETF action -- there were other > implementations of the same protocols that could have been > included in the base systems instead. But they weren't removed > or replaced (the folks who produced them eventually produced > better versions). Putting my FreeBSD hat back on for a second, we're always interested in improving our code base, and would certainly not want to intentionally do anything to "cause a lot of damage." If there are concrete concerns anyone should feel free to file a Problem Report at http://www.freebsd.org/send-pr.html, or use the 'send-pr' utility in FreeBSD. > But I don't recall seeing the sort of venom > that is directed toward 6to4 being focused on them. Perhaps > there weren't enough complaints or you have solid data that 6to4 > has caused even more damage. Once again repeating myself ... I have no venom towards 6to4. This isn't a personal attack. And yes, various people and organizations that have vested interests in seeing IPv6 deployed have posted the data about why 6to4 causes way more problems than it solves, and I believe them. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf