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

From: Mark ZZZ Smith <[email-masked]>
Date: Tue, 3 Feb 2015 23:15:33 +0000 (UTC)

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.

Would it be possible to conduct the same test with a dual stack site?

Thanks,
Mark.
________________________________
From: George Michaelson <[email-masked]>
To: Lorenzo Colitti <[email-masked]> 
Cc: Brian E Carpenter <[email-masked]>; Mark ZZZ Smith <[email-masked]>; "[email-masked]" <[email-masked]>; Tore Anderson <[email-masked]> 
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 <[email-masked]> 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 <[email-masked]> 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 <[email-masked]>
>>> 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 <[email-masked]>
>>>> *To:* Mark ZZZ Smith <[email-masked]>
>>>> *Cc:* Brian E Carpenter <[email-masked]>; Tore Anderson <
>>>> [email-masked]>; "[email-masked]" <[email-masked]>
>>>> *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 <[email-masked]
>>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: Brian E Carpenter <[email-masked]>
>>>> To: Tore Anderson <[email-masked]>; [email-masked]
>>>> 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:
>>>>> * [email-masked]
>>>>>
>>>>>> 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
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>>
>>_______________________________________________
>>v6ops mailing list
>>[email-masked]
>>https://www.ietf.org/mailman/listinfo/v6ops
>>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Feb 2015 09:18:15 +0900

> Would it be possible to conduct the same test with a dual stack site?

What would we learn from such an exercise? The OS / user-agent breakdown of
the 0.01% of hosts that use 6to4 when talking to dual-stack destinations?
Even if we knew that, what would we do with it?

---

From: "Metzler, Dan J" <[email-masked]>
Date: Wed, 4 Feb 2015 12:36:58 +0000

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Mark ZZZ Smith
> Sent: Tuesday, February 3, 2015 5:16 PM
> To: George Michaelson; Lorenzo Colitti
> Cc: [email-masked]; Tore Anderson
> 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?
	
> Cc: Brian E Carpenter <[email-masked]>; Mark ZZZ Smith
> <[email-masked]>; "[email-masked]" <[email-masked]>; Tore
> Anderson <[email-masked]>
> 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.
> 
> >>> 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
> >>>> 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
> >>>> *Cc:* Brian E Carpenter <[email-masked]>; Tore
> >>>> Anderson < [email-masked]>; "[email-masked]" <[email-masked]>
> >>>> 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.
> >>>> 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":
> >>>>
> >>>>> 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».
> >>>>> 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,
> >>>>
> >>>> 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

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 4 Feb 2015 23:23:59 +0000 (UTC)

While I appreciate that the draft isn't advising to block 6to4, I think it would be useful to gain some more detailed insight into the consequences of blocking 6to4 (i.e., which OSes/browsers might be impacted). Depending on the results, it may also mean that making a strong statement not to block 6to4 traffic in the draft would be beneficial, reinforcing what is in RFC6343.
Indirectly I think it would also be a measure of the deployment of the RFC3484/RFC6724 rules on various OSes. 
      From: Lorenzo Colitti <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]> 
Cc: George Michaelson <[email-masked]>; Brian E Carpenter <[email-masked]>; "[email-masked]" <[email-masked]>; Tore Anderson <[email-masked]> 
 Sent: Wednesday, 4 February 2015, 11:18
 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

On Wed, Feb 4, 2015 at 8:15 AM, Mark ZZZ Smith <[email-masked]> wrote:

What would we learn from such an exercise? The OS / user-agent breakdown of the 0.01% of hosts that use 6to4 when talking to dual-stack destinations? Even if we knew that, what would we do with it?

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 4 Feb 2015 23:38:11 +0000 (UTC)

From: "Metzler, Dan J" <[email-masked]>
 To: Mark ZZZ Smith <[email-masked]>; George Michaelson <[email-masked]>; Lorenzo Colitti <[email-masked]> 
Cc: "[email-masked]" <[email-masked]>; Tore Anderson <[email-masked]> 
 Sent: Wednesday, 4 February 2015, 23:36
 Subject: RE: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

* Actually, my fear would be that a number of people still using 6to4 might not know they're using it, because it has been enabled by default on IPv6 residential CPE when there isn't a native IPv6 service available. In markets such as Australia, where the customer usually chooses the model of and owns/"operates" the CPE, disabling 6to4 would be beyond most of their capabilities. IOW, actions that may break 6to4 may have the greatest impact on the "technically incompetent", and therefore strong advice not to block 6to4 in this draft may be worth providing.
* That may be a bit of an unrealistic fear on my behalf, however it seems the level of detail the current observations about 6to4 provide are that it isn't being used much and it isn't reliable. I'm curious to know the next level of detail down - who/what is (still) trying to use it, in particular when native IPv4 should now have been preferred for quite a long time.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Feb 2015 12:41:14 +1300

> While I appreciate that the draft isn't advising to block 6to4, I think it would be useful to gain some more detailed insight into the consequences of blocking 6to4 (i.e., which OSes/browsers might…

otoh, if we leave the text as it is now we have a fair chance of getting through
the IETF Last Call and the IESG, and finally getting this done.

    Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Feb 2015 08:52:22 +0900

On Thu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter <
[email-masked]> wrote:

> > While I appreciate that the draft isn't advising to block 6to4, I think
> it would be useful to gain some more detailed insight into the consequences
> of blocking 6to4 (i.e., which OSes/browsers might be impacted). Depending
> on the results, it may also mean that making a strong statement not to
> block 6to4 traffic in the draft would be beneficial, reinforcing what is in
> RFC6343.
>

+1. We can always explore that question in a separate document once this
one is published. If it turns out that blocking provides no benefit and/or
is harmful, then nothing changes. If it turns out that it can be done
safely, then we can issue an operational guidance document advising it.

---

From: George Michaelson <[email-masked]>
Date: Thu, 5 Feb 2015 13:48:02 +1000

I think I agree with Lorenzo.

I did run the numbers over 40 days of data, considering *ONLY* the fetches
made to a dualstack URL.

stf         2766
v4 23002469
v6     474779

6 to 4 (stf) in this measure is (as Lorenzo says) of the order 0.01% of the
total load seen on a dual-stack URL, and its only 0.57% of total IPv6. In
this measure, IPv6 is around 2% of total request traffic, which is lower
than even our pessimistic world-rate, but I did no complex analysis of this
by economy or anything, its an un-weighted simple sum.

The point being, that over a 40 day period 2,700 odd people insisted on
using 6to4, given a dual-stack URL out of 23,000,000 connections.  I
believe would be going too far to consider this right now as a damage risk.

A Top-10 OS/Browser list:

Windows 7.Chrome          1574
Windows 7.Firefox              328
Macintosh [na].Safari          250
Windows 8.1.Chrome         162
Windows 7.Microsoft IE        95
Windows 8.Chrome              81
Windows Vista.Chrome        74
Windows 7.Opera                 52
Windows XP.Chrome           34
Windows 8.1.Firefox             23

---

From: David Farmer <[email-masked]>
Date: Thu, 5 Feb 2015 20:52:47 -0600

> On Feb 4, 2015, at 21:48, George Michaelson <[email-masked]> wrote:
> 

+1, but more below.

> I did run the numbers over 40 days of data, considering *ONLY* the fetches made to a dualstack URL.
> 
> stf         2766
> v4 23002469
> v6     474779
> 
> 6 to 4 (stf) in this measure is (as Lorenzo says) of the order 0.01% of the total load seen on a dual-stack URL, and its only 0.57% of total IPv6. In this measure, IPv6 is around 2% of total request traffic, which is lower than even our pessimistic world-rate, but I did no complex analysis of this by economy or anything, its an un-weighted simple sum.
> 
> The point being, that over a 40 day period 2,700 odd people insisted on using 6to4, given a dual-stack URL out of 23,000,000 connections.  I believe would be going too far to consider this right now as a damage risk. 
> 

I appreciate the data, but your previous data for the IPv6 only URL was one day and this is 40 days for the Dual Stack URL.  It would be better to have the same time basis for the two data sets to determine a ratio estimating the 6to4 (2002::) hosts preferring IPv4 over 6to4.

This data seems to only include successful connections, as you have browser strings which implies they got though a TCP handshake to get to an HTTP exchange.  Would you also have failed(partial) connect attempts with only a SYN and nothing after, for 6to4, v6, and v4 source addresses to the Dual Stack URL and the IPv6 only URL?  This would give us a rough idea of a ratio for 6to4 return relay failures presumably.  

Obviously, 6to4 forward relay failures are impossible to measure with this technique, as you shouldn't even see any packets get to you with a failed 6to4 forward relay.  Anyone have any ideas how to measure 6to4 forward relay failure rate?

The draft hypothesizes that;

    The advice to disable 6to4 by default has been widely adopted in recent 
    operating systems, and the failure modes have been widely hidden from 
    users by many browsers adopting the "Happy Eyeballs" approach.

So, would you have any historic data, from maybe 2011 or 2012, to help support this first part and then anyway to look for Happy Eyeballs activity to support the second part? Something tells me that measuring Happy Eyeballs from the server end is going to be really hard, but I figure It can't hurt to ask.

Finally, nothing so far contradicts the drafts hypotheses or conclusions, especially to not recommend filtering 6to4 anycast relay traffic or routes.  So, please keep the draft moving forward.

I appreciate any additional data you might be able to produce.

And, thanks again for the data so far.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 6 Feb 2015 08:12:38 +0000 (UTC)

Hi George,
Thanks very much for the new data.
(Off topic for the draft) I do find the entries in the list of OS/Browsers a bit surprising - it either implies that they didn't have native IPv4 connectivity and only had 6to4, or weren't following RFC3484/6724 rules, which is surprising given how modern they all look.
Some searches have shown up some articles from Microsoft saying that they've been following RFC3484 rules since at least Windows Vista, and there are some registry hacks that can disable that, so perhaps that might explain the Windows entries Vista and later.
I found an article that said that since Mac OS X 10.6.5, native IPv4 is preferred over 6to4 IPv6, perhaps the Macintosh's in your list are pre-10.6.5.
Thanks,Mark.
      From: George Michaelson <[email-masked]>
 To: Lorenzo Colitti <[email-masked]> 
Cc: Brian E Carpenter <[email-masked]>; Mark ZZZ Smith <[email-masked]>; "[email-masked]" <[email-masked]>; Tore Anderson <[email-masked]> 
 Sent: Thursday, 5 February 2015, 14:48
 Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

I did run the numbers over 40 days of data, considering *ONLY* the fetches made to a dualstack URL.
stf         2766v4 23002469v6     474779
6 to 4 (stf) in this measure is (as Lorenzo says) of the order 0.01% of the total load seen on a dual-stack URL, and its only 0.57% of total IPv6. In this measure, IPv6 is around 2% of total request traffic, which is lower than even our pessimistic world-rate, but I did no complex analysis of this by economy or anything, its an un-weighted simple sum.
The point being, that over a 40 day period 2,700 odd people insisted on using 6to4, given a dual-stack URL out of 23,000,000 connections.  I believe would be going too far to consider this right now as a damage risk. 
A Top-10 OS/Browser list:
Windows 7.Chrome          1574Windows 7.Firefox              328Macintosh [na].Safari          250Windows 8.1.Chrome         162Windows 7.Microsoft IE        95Windows 8.Chrome              81Windows Vista.Chrome        74Windows 7.Opera                 52Windows XP.Chrome           34Windows 8.1.Firefox             23

On Thu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter <[email-masked]> wrote:

+1. We can always explore that question in a separate document once this one is published. If it turns out that blocking provides no benefit and/or is harmful, then nothing changes. If it turns out that it can be done safely, then we can issue an operational guidance document advising it.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 07 Feb 2015 00:22:17 +1100

In message <[email-masked]>, Mark
 ZZZ Smith writes:
> (Off topic for the draft) I do find the entries in the list of
> OS/Browsers a bit surprising - it either implies that they didn't have
> native IPv4 connectivity and only had 6to4, or weren't following
> RFC3484/6724 rules, which is surprising given how modern they all look.

If you have a IPv4 and a IPv6 address and the v4 connection attempt
fails then the v6 address will be tried and if the only viable
source address is 6to4 then that will be used.

> Some searches have shown up some articles from Microsoft saying that
> they've been following RFC3484 rules since at least Windows Vista, and
> there are some registry hacks that can disable that, so perhaps that
> might explain the Windows entries Vista and later.
> I found an article that said that since Mac OS X 10.6.5, native IPv4 is
> preferred over 6to4 IPv6, perhaps the Macintosh's in your list are
> pre-10.6.5.
> Thanks,Mark.
> 6 to 4 (stf) in this measure is (as Lorenzo says) of the order 0.01% of
> the total load seen on a dual-stack URL, and its only 0.57% of total
> IPv6. In this measure, IPv6 is around 2% of total request traffic, which
> is lower than even our pessimistic world-rate, but I did no complex
> analysis of this by economy or anything, its an un-weighted simple sum.
> it would be useful to gain some more detailed insight into the
> consequences of blocking 6to4 (i.e., which OSes/browsers might be
> impacted). Depending on the results, it may also mean that making a
> strong statement not to block 6to4 traffic in the draft would be
> beneficial, reinforcing what is in RFC6343.
>
> one is published. If it turns out that blocking provides no benefit
> and/or is harmful, then nothing changes. If it turns out that it can be
> done safely, then we can issue an operational guidance document advising
> it. 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Metzler, Dan J" <[email-masked]>
Date: Fri, 6 Feb 2015 14:55:31 +0000

“(Off topic for the draft) I do find the entries in the list of OS/Browsers a bit surprising - it either implies that they didn't have native IPv4 connectivity and only had 6to4, or weren't following RFC3484/6724 rules, which is surprising given how modern they all look.”

Vista/Windows Server 2008 – Follow RFC 3484  (Have to manually change the prefix selection table to get more modern behavior)
Windows 7/Windows Server 2008 R2 without IPv6 readiness update (KB2750841) – Follow RFC 3484
Windows 7/Windows Server 2008 R2 with IPv6 readiness update (KB2750841) – Follow RFC 6724
Windows 8/8.1/Windows Server 2012 – Follow RFC 6724

Of course some change the default prefix tables.  The above only reflect defaults, and that isn’t just for Windows.
NCSI (Microsoft Happy Eyeballs like implementation?) affects results here, but not sure what happens with Chrome and Firefox running on Windows.

-          Dan

Sent: Friday, February 6, 2015 2:13 AM

Hi George,

Thanks,
Mark.

________________________________
From: George Michaelson <[email-masked]<mailto:[email-masked]>>
To: Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
Cc: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Tore Anderson <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, 5 February 2015, 14:48
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

stf         2766
v4 23002469
v6     474779

Windows 7.Chrome          1574
Windows 7.Firefox              328

On Thu, Feb 5, 2015 at 9:52 AM, Lorenzo Colitti <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote: