In message <92F90CDD-6DA4-4B7F-BBCC-5DA43A43AF0B@xxxxxxxxx>, Joel Jaeggli write s: > > 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 ar > e 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 app > reciate it if the facility were: > > * off by default > > * considered harmful when not deliberately used. You don't need to make the protocol historic to achieve this. > The gradually declining determinism that we fully expect to experience from i > pv4 access networks and mobile broadband in particular we expect to be hard e > nough to manage without those users riding in over 6to4. > > I think the two documents at present encourage: There are at least 4 documents that address aspects of this issue. You need to add "happy eyeballs" to the mix (which works, see Google Chrome) and my 6to4 DHCP option draft. > * vendors an implementors to consider not using or a least disabling by defau > lt 6to4 auto-tunneling in existing and future implementations. We don't need vendors to stop implementing (historic). We just need it turned off by default (advisary). > * the deployment of additional 6to4 anycast relays which if done would help a > ddress issue that existing users of 6to4 who will be with us for a while as w > ell as those who would prefer to use it would benefit from. * the ability to signal that 6to4 will not work with the address you are being give. * the ability to signal that there is a managed 6to4 relay at this address. > > 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf