--On Saturday, June 11, 2011 05:28 +1200 Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> wrote: > John, > > On 2011-06-11 05:05, John C Klensin wrote: > > ... >> But, to the extent to which the motivation for moving 6to4 to >> Historic is what Tony describes as "kill-what-we-don't-like", > > Unfortunately, as I know from the enormous amount of technical > feedback I got from living, breathing operators while drafting > draft-ietf-v6ops-advisory, the motivation is "kill something > that is causing real operational problems and failure modes." > I wouldn't be endorsing draft-ietf-v6ops-6to4-to-historic if > there wasn't a very sound operational argument for it. > > I think nobody wants to kill the successful use of 6to4, but > we need to stop the operational problems getting worse. It > appears that the default help desk advice to disable 1PV6 is > generally an echo of problems caused by on-by-default 6to4. Brian, This is not in my primary area of expertise and I am painfully aware that it has been almost a decade since I have been able to look in on these things from the viewpoint of an ISP with default-free backbone arrangements, small end-site customers, and almost everything in between. >From the above and other comments you have made, I don't think we disagree very much on the substance here. I'm certainly not about to try to make the case that 6to4 is a wonderful option to be widely preferred. As a variation on your comment above, I don't want to see the IETF denounce or kill the successful use of 6to4 and don't believe anyone else does either (or at least should). Where we disagree is about a procedural matter and the stance the IETF takes formally and, perhaps still, about where the motivations to deploy IPv6 "for real" comes from. Let me see if I can describe my position and recommendation in another way: Even among those of us who believe that IPv6 conversion has ceased being optional and has to be considered the only option at this stage, we really have few clues about what is going to cause a given ISP, or a given end-node customer, to switch over. Most of our arguments are faulty, at least for some particular set of cases. Your capitalism/competition one is an example -- there are places where it will work and places where it won't. The applications support and availability of IPv6-capable (and IPv6-native) servers is another -- sometimes ISPs are waiting for customer demand and/or enough deployment on customer sites before they think about making the switch and the customers are waiting for more evidence that the applications issues are sorted out and will work reliably. We talk about the advantages to the folks who switch early, but we are aware that some folks don't want to be the first to switch. And so on, for a rather long list. Part of this adds up to a conclusion that we are lots better at protocol design than we are at predicting the future or gaming out the decision processes under various circumstances. We had better be -- our track record for those predictions is bad enough that, if our protocol design and engineering were worse, we should all find other occupations. At the same time, my very limited and quite anecdotal experience suggests that the decision in several dual-stack setups to automatically prefer IPv6 when it is available (following IETF advice if I recall) combines with sometimes-sketchy IPv6 connections and routing to cause connectivity problems that can overwhelm the sorts of folks who staff first-level help desks. 6to4 is certainly part of that problem --and a little worse if it is set up without user or ISP knowledge-- but the implicit argument in both ..-6to4-advice and 6to4-historic that 6to4 is the dominant cause of those problems isn't convincing. Maybe it is the case, maybe it is the dominant case (and, again, I don't have enough firsthand experience in recent years to claim to know) but certainly it is not the only one. I accept the claim that it can easily be misconfigured, but that may not be sufficient to demonize it. I don't think the technical content of either draft-ietf-v6ops-6to4-to-historic or draft-ietf-v6ops-6to4-advisory is especially bad. Indeed, the analysis in ...-6to4-advisory seems quite good to me -- the sort of thing the IETF should, IMO, be doing a lot more often. I'm just suggesting that we should not write off _any_ option that has proven useful to folks in preparing to transition, planning for transitions, or actually transitioning. To that end, the abstract of ...6to4-advisory is just the right think to do. Advising that 6to4 is a really lousy default, that implementations should allow it to be turned on only after appropriate warnings and only if the advice in Section 4 of ..-6to4-advice is followed _really_ carefully may be entirely appropriate. Put differently, your analysis appears good enough that I can see no argument against branding 6to4 as "really dangerous -- use only if actually understood and needed, then with great caution, and then only if there is some reason why 6rd is inappropriate or unavailable". But "Historic" is a really blunt instrument, especially since we use it primarily for protocols that are no longer in use and/or that have been demonstrated to be of no redeeming value. This situation is, IMO, an almost perfect example of why 2026 permits us to identify a protocol specification as "NOT RECOMMENDED" (yes, I think 2119 is defective in listing the conformance language (MUST/ SHOULD/ MAY/...) but not the recommendation terminology, but that is another topic). So my personal preference, in a more perfect world, would be to fold these two drafts together, drop "Historic" and any even slightly hyperbolic language, issue the combination as a standards-track A/S that updates 3056 and 3068 and makes a clear and carefully explained "NOT RECOMMENDED" statement. If, in conjunction with that move, you or others see value in downgrading 3056 and 3068 to Experimental and including comments to the effect that they are normally useful only for exploratory/experimental use, I wouldn't have any problem with that at all. I actually don't feel very strongly about the above. I probably would not have said anything in this thread if you hadn't raised the capitalism/competition argument. But, if there is a situation where 6to4 really is appropriate and the IETF makes what appears to be a strong statement deprecating it, we either convince someone to further defer thinking through and migrating to IPv6 or we help contribute to the impression that the IETF is out of touch with real world realities. I don't consider either of those outcomes desirable and presume you don't either. On the other hand, my impression from conversations with operations is that it certainly would not be either the first or the most extreme case in which we've shown the IETF to be out of touch and at least some users and implementers who find value in 6to4 are likely to continue doing whatever they think it is appropriate to do regardless of what labels the IETF decided to put on the specs. best, john p.s. Editorial nit: I'd love to know what a "domestic customer" in Sections 2 and 4.2.4 of ...-6to4-advice is. The term is as likely to be construed as "within a particular country" (New Zealand?) as "residential" (which I'm guessing is what you mean). As far as I can tell from skimming the document "residential, small office, or home office (SOHO)" would be more appropriate and consistent with terminology in common use. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf