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

[George Michaelson <[e-mail]>]

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
>
>