In message <92F90CDD-6DA4-4B7F-BBCC-5DA43A43AF0B(_at_)bogus(_dot_)com>, 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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
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(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf