On 14 Jun 2011, at 18:59, Lorenzo Colitti wrote: > On Tue, Jun 14, 2011 at 10:30 AM, james woodyatt <jhw@xxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf