Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

[Mark ZZZ Smith <[e-mail]>]

----- Original Message -----
From: Brian E Carpenter <[e-mail]>
To: Tore Anderson <[e-mail]>; [e-mail]
Cc: 
Sent: Wednesday, 21 January 2015, 7:14
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

On 21/01/2015 02:16, Tore Anderson wrote:
> * [e-mail]
> 
>> This is to initiate a one week working group last call of
>> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic.  
> 
> I have read this document, and I think it is ready to move forward.
> 
> Its operational need for this document is less pressing now than when
> the -00 version was published back in 2011. Nevertheless, I find it
> valuable and correct to put the final nail in 6to4's coffin at this
> point in time. While the operational community for the most part has
> already realised that 6to4 has no future, there might be some who have
> not been paying attention and formal deprecation of the protocol may
> help prevent them from making the mistake of attempting to base
> production systems on it.
> 
> I have one minor comment though: In section 1, it says «a substantial
> amount of 6to4 traffic is still observed by IPv6 content providers».
> While I do see 6to4 traffic, it is quite far from being of "substantial"
> levels. I would therefore recommend replacing "substantial" with
> something milder like "noticeable", "measurable", or something along
> those lines.
> 
> For what it's worth, today the Google public IPv6 graph shows just a
> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not
> just me.

"Tore,

However, that fraction of Google traffic multipled by Google users
represents something like 100000 users. I don't think we can dismiss
that number of people too easily. It's a matter of taste whether
that's "substantial" or "noticeable".

    Brian"

Actually, to those end users, the impact might be both quite significant and noticeable.

I think one explanation for the use of 6to4 tunnelled IPv6 is that their hosts aren't preferring native IPv4 over tunnelled IPv6 (assuming Google make their services equally available over both, which I think they do), as per RFC3484 address selection rules.

The other explanation for it could be that these users have Happy Eyeballs enabled browsers and the browser is choosing to try to use both IPv4 and IPv6, despite the IPv6 being tunnelled rather than native. From a Happy Eyeballs robustness perspective, that would be quite a reasonable thing to do I think.

If the end-hosts aren't following RFC3484's default preferences, then breaking 6to4 might cause the sorts of timeouts that HE is designed to overcome. RFC3484 is quite old now (2003), and as a minor data point I first encountered the implementation of them in around 2008/2009 if I recall correctly on my Linux system (as I was using 6to4 at the time and wanted to use tunnelled IPv6 in preference to native IPv4 - gai.conf(3) is the way you change that). So if some hosts are still preferring tunnelled 6to4 IPv6 over native IPv4 then perhaps they're also not going to be running a HE enabled browser either.

Perhaps it might be possible for somebody at Google to produce a list of the browser User-Agent strings for people still using 6to4 to see if the browsers being used are HE enabled, which might also give some insight into RFC3484 support in the underlying OSes.

Regards,
Mark.














_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops