Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC - 6to4 on Routers for IPv6-only Hosts

[Alexandru Petrescu <[e-mail]>]

Le 21/01/2015 01:30, Mark ZZZ Smith a écrit :
>
>
>
>
> ----- 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

I agree.

Just to note that this explanation covers a number of 6to4 users, but 
not all.

There are 6to4 users who have no v4 on their hosts - it is an 
intermediary router which does 6to4.

Alex


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