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

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

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

From: v6ops [mailto:[e-mail]] On Behalf Of Mark ZZZ Smith
Sent: Friday, February 6, 2015 2:13 AM
To: George Michaelson; Lorenzo Colitti
Cc: [e-mail]; Tore Anderson
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

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 <[e-mail]<mailto:[e-mail]>>
To: Lorenzo Colitti <[e-mail]<mailto:[e-mail]>>
Cc: Brian E Carpenter <[e-mail]<mailto:[e-mail]>>; Mark ZZZ Smith <[e-mail]<mailto:[e-mail]>>; "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>; Tore Anderson <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, 5 February 2015, 14:48
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

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




On Thu, Feb 5, 2015 at 9:52 AM, Lorenzo Colitti <[e-mail]<mailto:[e-mail]>> wrote:
On Thu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter <[e-mail]<mailto:[e-mail]>> wrote:
On 05/02/2015 12:23, Mark ZZZ Smith 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.

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.

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