Keith is correct, and the further issue is that the *-only-* reason the
'poorly managed' relays are in the path is that the content providers are
refusing to deploy the matching 6to4 router that would take a direct
connection from the customer.
6to4 direct between the content and consumer is still an 'unmanaged' tunnel
which takes exactly the same path as IPv4 would, so the 'badness' is not due
to managed vs. not. In the grand scheme of things, the last thing the
content providers want is for the network to wrest control over streams into
a walled-garden model. Unfortunately they are not thinking this through,
they are just whining because the deployment of a second prefix on their
content servers does not conform to their IPv4-think dream world.
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Sent: Tuesday, June 14, 2011 10:56 AM
To: Ole Troan
Cc: Michel Py; IETF-Discussion
Subject: Re: one data point regarding native IPv6 support
On Jun 14, 2011, at 1:43 PM, Ole Troan wrote:
making 6to4 historic does not affect 6rd. I think the draft says that
I don't think we are saying that native necessarily is better than
we are saying unmanaged tunnels crossing the Internet is bad.
I think this misses the point. Most internet traffic is "unmanged".
The fact that in the case of 6to4 the traffic is protocol 41 doesn't
The real problem here is that there are relay routers that advertise
connectivity to one or both anycast addresses via BGP, that aren't
A related problem, I suppose, is that to a user, 6to4 looks like "the
network". And if there's a problem, the user will blame "the network"
and ask "the network" support people to fix it. And quite often the
problem is not in the access network but in another network. But (and
please forgive my ignorance of operational issues) I don't see how
that's inherently different from any case where there's a BGP
advertisement to somewhere that blackholes traffic. Except maybe that
there are a growing number of 6to4 users who can complain, and that all
6to4-related problems tend to get lumped together in the minds of
support people even if they're caused by different networks and
Ietf mailing list
Ietf mailing list