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

[Lorenzo Colitti <[e-mail]>]

Are these probes made to an IPv6-only hostname? If so, then of course we'd
expect OSes to attempt 6to4.

On Tue, Jan 27, 2015 at 12:35 PM, Brian E Carpenter <
[e-mail]> wrote:

> 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
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>