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

[George Michaelson <[e-mail]>]

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]> wrote:

> On Thu, Feb 5, 2015 at 8:41 AM, Brian E Carpenter <
> [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.
>