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

[Brian E Carpenter <[e-mail]>]

Measurable, indeed.

Windows 8? Really?

Regards
   Brian

On 27/01/2015 15:07, George Michaelson wrote:
> Ask and ye shall receive
> 
> Here is a days summary of os, browser, os+browser as determined by the
> APNIC 1x1 capture, using 2002: as the source IPv6 address, and the Python
> httpagentparser module to detect OS and Version info.
> 
> -George
> 
> os,Windows+7,22287
> os,Windows+8.1,1743
> os,Windows+Vista,939
> os,Windows+8,894
> os,Windows+XP,431
> os,Macintosh+[na],124
> os,iOS+[na],44
> os,Linux+[na],29
> os,Windows+NT 6.4,6
> os,Windows Phone+8.1,2
> os,ChromeOS+6310.68.0,2
> 
> browser,Chrome,18297
> browser,Firefox,3774
> browser,Microsoft Internet Explorer,2872
> browser,Opera,1439
> browser,Safari,110
> browser,AndroidBrowser,5
> browser,[na],2
> browser,SeaMonkey,2
> 
> os+browser,Windows+7.Chrome,15539
> os+browser,Windows+7.Firefox,3033
> os+browser,Windows+7.Microsoft Internet Explorer,2432
> os+browser,Windows+8.1.Chrome,1305
> os+browser,Windows+7.Opera,1277
> os+browser,Windows+8.Chrome,644
> os+browser,Windows+Vista.Chrome,537
> os+browser,Windows+8.1.Firefox,311
> os+browser,Windows+Vista.Microsoft Internet Explorer,230
> os+browser,Windows+XP.Chrome,216
> os+browser,Windows+Vista.Firefox,148
> os+browser,Windows+XP.Firefox,134
> os+browser,Windows+8.Firefox,116
> os+browser,Windows+8.Microsoft Internet Explorer,87
> os+browser,Windows+8.1.Opera,64
> os+browser,Windows+8.1.Microsoft Internet Explorer,63
> os+browser,Macintosh+[na].Safari,60
> os+browser,Windows+XP.Microsoft Internet Explorer,54
> os+browser,Windows+8.Opera,45
> os+browser,iOS+[na].Safari,44
> os+browser,Macintosh+[na].Chrome,36
> os+browser,Windows+XP.Opera,25
> os+browser,Windows+Vista.Opera,24
> os+browser,Macintosh+[na].Firefox,24
> os+browser,Linux+[na].Chrome,16
> os+browser,Linux+[na].Firefox,8
> os+browser,Windows+7.Safari,6
> os+browser,Linux+[na].AndroidBrowser,5
> os+browser,Windows+NT 6.4.Microsoft Internet Explorer,4
> os+browser,Macintosh+[na].Opera,4
> os+browser,Windows+XP.SeaMonkey,2
> os+browser,Windows+NT 6.4.Chrome,2
> os+browser,Windows+8.[na],2
> os+browser,Windows Phone+8.1.Microsoft Internet Explorer,2
> os+browser,ChromeOS+6310.68.0.Chrome,2
> 
> 
> On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith <[e-mail]>
> wrote:
> 
>> I'm fine with that.
>>
>> If it is easy enough, I think it would be interesting to get a bit more of
>> an insight into who/what is still using 6to4 either in preference to or in
>> (HE) parallel to native IPv4 by e.g., collecting User-Agent for 6to4 users.
>>
>>   ------------------------------
>>  *From:* Lorenzo Colitti <[e-mail]>
>> *To:* Mark ZZZ Smith <[e-mail]>
>> *Cc:* Brian E Carpenter <[e-mail]>; Tore Anderson <
>> [e-mail]>; "[e-mail]" <[e-mail]>
>> *Sent:* Wednesday, 21 January 2015, 23:16
>>
>> *Subject:* Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
>>
>> Yes, those users will definitely be impacted. Which is why the document
>> does not suggest dropping the packets or turning off the relays, except by
>> saying things like "operators SHOULD [...] consider carefully whether the
>> [...] relay can be discontinued as traffic diminishes". That's quite
>> reasonable guidance, I think.
>>
>> Remember: 0.01% is really a very small number. Multiplying it by 1 billion
>> (like Brian did) makes it seem large, but that's just a trick of the light.
>> Look at it this way: if all the relays in the world were turned off
>> overnight and all the 6to4 users were unable to reach a given website, that
>> website's reliability would still be 99.99% of what it was before.
>>
>> I support this document in its current form. I only have three comments
>> beyond seconding Tore's objection to the draft calling 6to4 "substantial":
>>
>>    1. Is it necessary to formally deprecate RFC 6732? It's an individual
>>    submission. (Not that I support RFC 6732 in any way, to be sure.)
>>    2. I don't think the sentence "some content providers have been
>>    reluctant to make content available over IPv6" is true, or at least any
>>    true for any non-trivial value of "some". 6to4 was a problem for content
>>    providers a few years ago, but we've moved past it.
>>    3. It might be useful to cite that another reason 6to4 is being
>>    deprecated is that IPv6 is actually being deployed these days (finally).
>>
>>
>>
>>
>> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith <[e-mail]
>>> wrote:
>>
>>
>>
>>
>>
>> ----- 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
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
>>
>>
>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>>
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>