On Jun 10, 2011, at 10:28 AM, Brian E Carpenter 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'm a content provider. I'm am prepared to turn on more ipv6 services that are visible to consumers. 6to4 is a visible and measurable source of collateral damage. If consenting adults want to use it that's fine, I would greatly appreciate it if the facility were: * off by default * considered harmful when not deliberately used. The gradually declining determinism that we fully expect to experience from ipv4 access networks and mobile broadband in particular we expect to be hard enough to manage without those users riding in over 6to4. I think the two documents at present encourage: * vendors an implementors to consider not using or a least disabling by default 6to4 auto-tunneling in existing and future implementations. * the deployment of additional 6to4 anycast relays which if done would help address issue that existing users of 6to4 who will be with us for a while as well as those who would prefer to use it would benefit from. > 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 > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf