ietf
[Top] [All Lists]

Re: [v6ops] Last Call: <draft-ietf-v6ops-6to4-to-historic-04.txt> (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC

2011-06-16 10:14:40
On Tue, Jun 14, 2011 at 3:40 PM, Mark Smith <
ipng(_at_)69706e6720323030352d30312d31340a(_dot_)nosense(_dot_)org> wrote:

I don't know if it is intentional, however if I use Google's public
8.8.8.8 and 8.8.4.4 resolvers, and prefer 6to4 over native IPv4
(via /etc/gai.conf under Linux/glibc), it seems that the video content
of all youtube videos is now being delivered over IPv6.


Yes, YouTube videos are currently being served on dual-stack hostnames. The
percentage of YouTube users that uses 6to4 is less than 0.02%. The
percentage of YouTube users that uses native IPv6 is approximately 0.2% -
over 10x more.

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?

I'm having and have been having 100% success rate (or near enough to it
that I can remember) using 6to4 for a number of years, including with
an IPv6 MTU of as large as my PPPoE connection will support i.e. my
6to4 tunnel has an IPv6 MTU of 1472. Since noticing that youtube videos
are coming over IPv6, I've paid a bit more attention to the "quality of
experience" I've had, and have not found any reasons to change my
preference back to native IPv4 instead of 6to4.


Sure - you're one of the 80% for whom it works. But that wasn't my question
- my question was "what is the advantage?" You said that you have near
enough 100% success rate, but I bet that your IPv4 success rate is near
enough 100% as well. So what are you gaining by using 6to4 to talk to
YouTube?
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>