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

[Brian E Carpenter <[e-mail]>]

Hi Lorenzo,

First a general comment - I have a bunch of proposed text improvements
from David Farmer and I will try to get a version out with all those
that are non-controversial during this week, and whatever consensual
changes I find in the recent threads.

More in line...
On 22/01/2015 01:16, Lorenzo Colitti wrote:
> 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.

Sure. But if I was one of the ~100k users concerned, I wouldn't want to
be told that I wasn't important. I think s/substantial/measurable/
should fix this.

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

Well, reviewing the emails I've archived, I see mild support for
formally obsoleting it and no strong opposition.

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

Probably true as a specific reason. I hear "lack of demand" as the
usual excuse today. Will rephrase.

>    3. It might be useful to cite that another reason 6to4 is being
>    deprecated is that IPv6 is actually being deployed these days (finally).

But there are still many IPv6 deserts in the world, so I'm a
bit wary of trying to find an objective way of saying that.

   Brian

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