On 14 Jun 2011, at 18:59, Lorenzo Colitti wrote:
On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt <jhw(_at_)apple(_dot_)com>
wrote:
Very few of the people using 6to4 in this way will show up in Google's user
behavior analysis, of course, because Google doesn't run its own 6to4
return-path relay as I-D.ietf-v6ops-6to4-advisory recommends.
We would not see these users even if we operated reverse path relays as
recommended in the draft - from the point of view of the server, in both
cases it's just a TCP connection to a 2002::/16 address, regardless of
whether the relay is inside the Google network or outside it.
Running the relay inside your network lets you correlate the failure rate you
observe to the direction of the path the failures occur in, though. That data
may be valuable to you. And since it's HTTP we're talking about, it might be a
consolation to know that it's your side of the network generating the most
traffic.
Those users would become visible if we added AAAA records with 6to4
addresses, but that's a bad plan because it would likely lead to the
double-digit connection failure rates that Geoff observes. It would also
become visible if Google operated an open anycast relay, which we do not
plan to do.
Your (Google's) problem is the relays. So, if we take this thought a step
further, by deploying (no, I'm not suggesting you do this, obviously) a
6to4-reachable presence you may actually reduce the total traffic by volume
reaching you over native IPv6, if it transpires that 6to4 is a good portion of
the majority of tunnel traffic, the vast majority of IPv6 traffic reaching you.
That's not to speak of address selection algorithms which would do the right
thing (in theory) given the choice of native or 6to4, of course.
The way to find these people is to crawl the BitTorrent networks. What's
that old maxim? "You can't test what you don't measure." Do you measure
the BitTorrent networks?
No, we don't. The measurements we conduct have the purpose of determining
the impact of adding AAAA records to web sites, so we don't measure the
population of users that has 6to4 but does not use it to make HTTP
connections to dual-stack websites. We do measure the impact of 6to4 on the
reliability of websites indirectly, e.g., by observing the difference
between OSes that prefer IPv4 over 6to4 and OSes that don't.
That's a real shame, because the use of peer-to-peer applications is a solid
reason to turn various tunnel techniques on. One popular Windows BitTorrent
client makes it a single-button operation; others simply take the IPv6
connectivity for granted, when available. See:
http://thepiratebay.org/blog/146
Also, is there a way we can put this debate to rest using real data? What if
we asked someone like Hurricane Electric how much traffic on their network
is native IPv6 vs. 6to4?
I agree, this would be a good thing.
That said, I would argue that most or all 6to4 traffic could just as well
use IPv4, since both parties to the communication obviously have access to a
public IPv4 address. What is the advantage of using 6to4 over IPv4 that
makes it worth suffering an 80% failure rate?
Others have beaten me to this one but I will say one thing in your favour: NAT
traversal techniques are ubiquitous and, curse them, actually fairly
transparent. This is probably a good thing and it does support your view that
at least in the case of BitTorrent or other vanilla address-neutral protocols
the end-user transparency really doesn't usually justify the added tunnels for
v4-to-v4 communication, regardless of technical impropriety. However this does
nothing to address other real concerns, most of them brought up by Keith
already. Most importantly, new protocols or uses of the Internet shouldn't be
sabotaged by the need for some sort of imaginary all-or-nothing transition to
IPv6.
One final thought: assuming we ever get to the stage of minority native IPv6
worth service providers' time to set up IPv6 reachability for, and not just the
big ones either, what exactly do all the tunnel brokers of the world do about
the sudden demand for their services?
Cheers,
Sabahattin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf