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

["Metzler, Dan J" <[e-mail]>]

> -----Original Message-----
> From: v6ops [mailto:[e-mail]] On Behalf Of Mark ZZZ Smith
> Sent: Tuesday, February 3, 2015 5:16 PM
> To: George Michaelson; Lorenzo Colitti
> Cc: [e-mail]; Tore Anderson
> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
> 
> 
> 
> 
> So this was interesting data, however I've realised that I don't think it is quite
> measuring what I thought it was measuring if the test destination was IPv6
> only. If that is the case, then the choice was 6to4 or nothing to use to access
> the IPv6 only destination.
> 
> I think the more interesting case is when the destination is dual stack, and the
> end host has a choice of native IPv4 or 6to4 tunnelled IPv6. A host or
> application that chooses 6to4 over native IPv4 isn't following
> RFC3484/RFC6724 precedence. They would be the ones impacted by actively
> blocking 6to4 traffic somewhere between the host and destination, and that
> impact would be visible to the end-user if Happy Eyeball techniques weren't
> being used.	

Am I missing something?  Isn't that really flawed logic?  6to4 users that target native IPv6 (non-dual stack) would definitely be impacted by blocking 6to4 traffic.
The number of targets that are dual stack and still using 6to4 is likely to be small, and easily fixable.  This seems likely you're trying to ignore the relevant population?

Or are you really focused on something unrelated?
	
> 
> Would it be possible to conduct the same test with a dual stack site?
> 
> Thanks,
> Mark.
> ________________________________
> From: George Michaelson <[e-mail]>
> To: Lorenzo Colitti <[e-mail]>
> Cc: Brian E Carpenter <[e-mail]>; Mark ZZZ Smith
> <[e-mail]>; "[e-mail]" <[e-mail]>; Tore
> Anderson <[e-mail]>
> Sent: Tuesday, 27 January 2015, 14:39
> Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC
> 
> 
> 
> 
> 
> 
> 
> On Tue, Jan 27, 2015 at 1:36 PM, Lorenzo Colitti <[e-mail]>
> wrote:
> 
> Are these probes made to an IPv6-only hostname? If so, then of course we'd
> expect OSes to attempt 6to4.
> 
> Yes and yes. I thought about pruning, and decided to make it complete. Its
> certainly not a strong reflection of the real world dynamic, but it shows how
> many people are still sitting on vestigial 6to4 technology which can be woken.
> Since we know some ISPs had deployment models which included this, Its not
> surprising.
> 
> Functionally its dead technology. But its zombie dead. not stone-cold.
> 
> -G
> 
> 
> 
> 
> >
> >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
> >>
> >
> 
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops