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

[Alexandru Petrescu <[e-mail]>]

Le 27/01/2015 03:07, George Michaelson a écrit :
> 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.

Thank you.

That is 26501 unique OSs using 2002 in the first hextet of the src.

The number of `uniq` 2002::/48 prefixes was?

There could be more Clients behind 6to4 routers.

Alex

>
> -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] <mailto:[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] <mailto:[e-mail]>>
>     *To:* Mark ZZZ Smith <[e-mail]
>     <mailto:[e-mail]>>
>     *Cc:* Brian E Carpenter <[e-mail]
>     <mailto:[e-mail]>>; Tore Anderson <[e-mail]
>     <mailto:[e-mail]>>; "[e-mail] <mailto:[e-mail]>"
>     <[e-mail] <mailto:[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] <mailto:[e-mail]>> wrote:
>
>
>
>
>
>         ----- Original Message -----
>         From: Brian E Carpenter <[e-mail]
>         <mailto:[e-mail]>>
>         To: Tore Anderson <[e-mail] <mailto:[e-mail]>>;
>         [e-mail] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>         _______________________________________________
>         v6ops mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
>
>     _______________________________________________
>     v6ops mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>