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

From: [email-masked]
Date: Sun, 18 Jan 2015 11:00:02 -0800

This is to initiate a one week working group last call of
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic.  
Please read it now. If you find nits (spelling errors, minor suggested
wording changes, etc), comment to the authors; if you find greater
issues, such as disagreeing with a statement or finding additional
issues that need to be addressed, please post your comments to the
list.

We are looking specifically for comments on the importance of the
document as well as its content. If you have read the document and
believe it to be of operational utility, that is also an important
comment to make.

---

From: Sander Steffann <[email-masked]>
Date: Sun, 18 Jan 2015 13:23:48 -0800

Hi Fred,

> believe it to be of operational utility, that is also an important

Ok: This document is of operational utility :)

There are still people new to IPv6 who read the 6to4 standard documents and think it is a good idea without knowing about the issues it has. When trying to educate those people an often heard response is "if it was so bad it wouldn't be a PROPOSED STANDARD". Moving the relevant RFCs to historic will help with changing the mindset and understanding of newcomers.

Cheers,
Sander

---

From: Tore Anderson <[email-masked]>
Date: Tue, 20 Jan 2015 14:16:15 +0100

* [email-masked]

> 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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Jan 2015 22:20:53 +0900

> something milder like "noticeable", "measurable", or something along

"Substantial" is definitely incorrect. From a content provider point of
view, I think the number is minimal. (If I were writing the draft I'd be
tempted to say "non-zero"). There is likely much more P2P 6to4 traffic
though.

> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not

"Measly" would also be better than "substantial" :-)

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 Jan 2015 09:14:57 +1300

> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not

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

---

From: Mark ZZZ Smith <[email-masked]>
Date: Wed, 21 Jan 2015 00:30:22 +0000 (UTC)

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

> measly 0.01% of their total IPv6 traffic being Teredo/6to4, so it's not

"Tore,

    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

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 21 Jan 2015 21:16:01 +0900

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:

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

---

From: Owen DeLong <[email-masked]>
Date: Wed, 21 Jan 2015 10:09:57 -0800

+1 — I agree with all of Lorenzo’s comments.

Owen

> On Jan 21, 2015, at 04:16 , Lorenzo Colitti <[email-masked]> 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.
> 
> I support this document in its current form. I only have three comments beyond seconding Tore's objection to the draft calling 6to4 "substantial":
> 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.)
> 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.
> 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] <mailto:[email-masked]>> wrote:
> 
> 
> 
> 
> From: Brian E Carpenter <[email-masked] <mailto:[email-masked]>>
> To: Tore Anderson <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> Cc:
> > * [email-masked] <mailto:[email-masked]>
> >
> >> http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic <http://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic>.
> >
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
>

---

From: James Woodyatt <[email-masked]>
Date: Wed, 21 Jan 2015 11:47:23 -0800

On Wed, Jan 21, 2015 at 4:16 AM, Lorenzo Colitti <[email-masked]> wrote:

> Rather than ask if it's necessary, I'd prefer to ask if there is any sane
reason to think RFC 6732 is anything more than an historical curiosity.

If 6to4-PMT isn't of any more than historical interest, then let's please
move its category to Historic so that its applicability will not be
confused with other practical non-standard protocol specifications
published by IETF in the Informational category, many of which rightly
enjoy widespread deployment today, e.g. PPPoE.

-- 
james woodyatt <[email-masked]>
Nest Labs, Communications Engineering

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 22 Jan 2015 11:24:24 +0100

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

---

From: Keith Moore <[email-masked]>
Date: Sat, 24 Jan 2015 08:43:46 -0500

I have no objection to this version of the document.
I think the principal value in approving it is to allow the WG to move 
past it.

Keith

---

From: Chuck Anderson <[email-masked]>
Date: Sat, 24 Jan 2015 09:06:14 -0500

> enjoy widespread deployment today, e.g. PPPoE.

+1 — I agree with Lorenzo’s comments 2. and 3. and James' comment here.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 26 Jan 2015 23:31:57 +0000 (UTC)

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

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

   - 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

"Tore,

    Brian"

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jan 2015 13:34:37 +1300

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

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

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

>    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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 27 Jan 2015 09:43:13 +0900

> be told that I wasn't important. I think s/substantial/measurable/

I see. Ok then Brian  you're a unique, precious snowflake, one in ten
thousand. :-P

But seriously - no opposition to s/substantial/measurable/ - because it is,
in fact, measurable.

> formally obsoleting it and no strong opposition.

I suppose my question was really only procedural: *can* we even obsolete an
individual submission? It's not a document based on IETF consensus, so if
IETF consensus was not necessary to publish it, then how can IETF consensus
be sufficient to obsolete it?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jan 2015 14:13:33 +1300

> be sufficient to obsolete it?

Terminology alert: it's an *independent* submission, not an *individual*
submission (the latter is an IETF stream draft but with no associated WG).

So, your question is valid. I suggest we leave it as "obsoletes" for now
and let somebody with a higher IETF pay grade decide. Next time I bump
into the Independent Series Editor (which will be later this week
in Rotorua NZ, as it happens) I will ask if there's a precedent.

    Brian

---

From: George Michaelson <[email-masked]>
Date: Tue, 27 Jan 2015 12:07:18 +1000

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
>
> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith <[email-masked]
> > wrote:
>
>
>
>
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jan 2015 16:35:19 +1300

Measurable, indeed.

Windows 8? Really?

Regards
   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 27 Jan 2015 12:36:44 +0900

Are these probes made to an IPv6-only hostname? If so, then of course we'd
expect OSes to attempt 6to4.

On Tue, Jan 27, 2015 at 12:35 PM, Brian E Carpenter <
[email-masked]> wrote:

> Eyeballs

---

From: George Michaelson <[email-masked]>
Date: Tue, 27 Jan 2015 13:37:33 +1000

Browser Match strings are a black art. Its entirely possible its a
misreport.
-G

---

From: George Michaelson <[email-masked]>
Date: Tue, 27 Jan 2015 13:39:18 +1000

> 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

>> >> Actually, to those end users, the impact might be both quite
>> significant
>> >> and noticeable.
>> >>
>> their
>> of

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 27 Jan 2015 16:54:56 +1300

> Functionally its dead technology. But its zombie dead. not stone-cold.

Good input. IMHO it confirms the position taken by 6to4-to-historic
(deprecate but do not block).

    Brian

---

From: "Metzler, Dan J" <[email-masked]>
Date: Tue, 27 Jan 2015 07:34:59 +0000

“Are these probes made to an IPv6-only hostname? If so, then of course we'd expect OSes to attempt 6to4.”

I would hope so.  If the whole premise of 6to4 being a dead technology were based on the idea that we are only talking about dual stack hosts, then this whole exercise is silly.
Probes to IPv6-only hostnames are exactly what matters, and I would argue that this thing is really a moving target until all ISPs are providing IPv6 connectivity.

Unless an alternative auto-configured solution is provided out-of-the-box by vendors, (not likely if WGs are claiming it isn’t needed), then 6to4 is likely to hang around; even if it isn’t the optimal solution.  I heard claims that it would be a good 5-6 years before vendors would be able to push an alternative solution out the door, and by that time IPv6 will have reached critical mass.  Well if that is the future we’re putting forward and we aren’t pursuing an alternative solution, then we are waiting for IPv6 to reach critical mass before 6to4 really becomes “dead”; or at least waiting for all ISPs to provide some kind of IPv6 connectivity.  (Or, we’re waiting for the relay operators to cut off their access.)  Until then it is likely that 6to4 will hang around in at various levels because there will always be a group of internet users that are using the existing 6to4 relays to be able to reach IPv6 only hosts, and over time we can expect the number of v6 only hosts to go up; not down.

I have no objection to the document as it advocates deprecating, not breaking 6to4-PMT, (the anycast stuff).  I would just point out that we are not waiting for content providers to do something.  We are waiting for ISPs to provide native IPv6, so that people who don’t read RFCs or care about them will get their IPv6 connectivity through methods other than Teredo and 6to4.  I don’t know how you measure the number of ISPs that are IPv4 only still, but to me that’s the important measurement, and the 6to4-PMT users are a subset of their customers who happen to have 6to4 capable endpoints and gateways.

Regards,
  Dan

From: v6ops [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Monday, January 26, 2015 9:37 PM
To: Brian E Carpenter
Cc: Tore Anderson; [email-masked]
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

Are these probes made to an IPv6-only hostname? If so, then of course we'd expect OSes to attempt 6to4.

On Tue, Jan 27, 2015 at 12:35 PM, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:
Measurable, indeed.

Windows 8? Really?

Regards
   Brian

On 27/01/2015 15:07, George Michaelson wrote:
> On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>
> wrote:
>
>> I'm fine with that.
>>
>>  *From:* Lorenzo Colitti <[email-masked]<mailto:[email-masked]>>
>> *To:* Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>>
>> *Cc:* Brian E Carpenter <[email-masked]<mailto:[email-masked]>>; Tore Anderson <
>> [email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
>> On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith <[email-masked]<mailto:[email-masked]>
>>> wrote:
>>
>>
>>
>>
>>
>> From: Brian E Carpenter <[email-masked]<mailto:[email-masked]>>
>> To: Tore Anderson <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
>> Cc:
>>> * [email-masked]<mailto:[email-masked]>
>>>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
>> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
v6ops mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/v6ops

---

From: James Woodyatt <[email-masked]>
Date: Tue, 27 Jan 2015 11:42:07 -0800

On Mon, Jan 26, 2015 at 11:34 PM, Metzler, Dan J <[email-masked]>
wrote:

>
>
> Unless an alternative auto-configured solution is provided out-of-the-box
> by vendors, (not likely if WGs are claiming it isn’t needed), then 6to4 is
> likely to hang around; even if it isn’t the optimal solution.  I heard
> claims that it would be a good 5-6 years before vendors would be able to
> push an alternative solution out the door, and by that time IPv6 will have
> reached critical mass.  Well if that is the future we’re putting forward
> and we aren’t pursuing an alternative solution, then we are waiting for
> IPv6 to reach critical mass before 6to4 really becomes “dead”; or at least
> waiting for all ISPs to provide some kind of IPv6 connectivity.  (Or, we’re
> waiting for the relay operators to cut off their access.)  Until then it is
> likely that 6to4 will hang around in at various levels because there will
> always be a group of internet users that are using the existing 6to4 relays
> to be able to reach IPv6 only hosts, and over time we can expect the number
> of v6 only hosts to go up; not down.
>

I hate to be That Guy, but I can't keep myself from wondering aloud if we
might see measurable *intentional* usage of 6to4 [RFC 3056] in the wild for
as long as we still see IPv4 in the wild.  When I'm feeling especially
depressed about this topic, I wonder if we might see 6to4 as the *last*
major application of IPv4 before we turn off its lights in the default free
zone.

p.s. My thanks to George Michaelson for capturing that information.  Very
illuminating.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 27 Jan 2015 11:53:41 -0800

> On Jan 27, 2015, at 11:42 , James Woodyatt <[email-masked]> wrote:
> 
> On Mon, Jan 26, 2015 at 11:34 PM, Metzler, Dan J <[email-masked] <mailto:[email-masked]>> wrote:
>  
> 
> I hate to be That Guy, but I can't keep myself from wondering aloud if we might see measurable *intentional* usage of 6to4 [RFC 3056] in the wild for as long as we still see IPv4 in the wild.  When I'm feeling especially depressed about this topic, I wonder if we might see 6to4 as the *last* major application of IPv4 before we turn off its lights in the default free zone.

I think that’s pretty unlikely.

6to4 really doesn’t do you much good if you’ve got IPv6 connectivity available, and I can’t imagine that a network would be the last vestigial holdout of transition rather than some arcane application or end device.

Owen

---

From: David Farmer <[email-masked]>
Date: Tue, 27 Jan 2015 14:04:56 -0600

> in Rotorua NZ, as it happens) I will ask if there's a precedent.

I think a metadata link obsoleting 6732 is appropriate either way.

6to4-PMT is basically a special case anycast relay and return relay 
bolted together and to a 66 prefix translator.  So, would a 6to4-PMT 
version of the relay operator recommendation be applicable.

   Current operators of a 6to4-PMT relay SHOULD review the information
   in the present document, and then consider carefully whether the
   6to4-PMT relay can be discontinued as traffic diminishes.

Or, maybe better yet consolidate the three different relay operator 
recommendations into a generic and unified 6to4 relay recommendation for 
all relay type, like;

Current operators of all 6to4 relays (anycast using 192.88.99.1, return 
using 2002::/16 , or 6to4-PMT) SHOULD review the information in 
[RFC6343] and the present document, and then consider carefully whether 
the 6to4 relay can be discontinued as traffic diminishes.

The further discussion of 6to4-PMT got me thinking.

Thanks.
-- 
================================================
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: Lorenzo Colitti <[email-masked]>
Date: Wed, 28 Jan 2015 09:48:10 +0900

On Wed, Jan 28, 2015 at 4:42 AM, James Woodyatt <[email-masked]> wrote:

> as long as we still see IPv4 in the wild.
>

Personally I doubt it. I think the reason we still have nonzero 6to4 usage
is because a) MS made it "a requirement" for some versions of Windows, b)
some CPE manufacturers included it and turned it on by default, and c) some
OSes prefer it to IPv4. That was all long ago, but old hardware dies hard.
I just saw a bug report from a Nexus Player user where the CPE was not only
announcing a default route 6to4 prefix with a 10.0.0.0/8 IPv4 address, but
a *link-local address as DNS server* (that was a new one even for me).

These days, if you're an enthusiast, you're more likely to use a configured
tunnel, and if you're a CPE manufacturer, you're likely to go for parity
with other CPE feature sets, which are essentially DHCPv6 PD and/or 6rd
(and declaring RFC3056 will help here). As the old hardware ages out, 6to4
will slowly disappear.

  When I'm feeling especially depressed about this topic, I wonder if we
> might see 6to4 as the *last* major application of IPv4 before we turn off
> its lights in the default free zone.
>

If we could agree on a definition of "major" that was measurable, I'd take
a bet against that. :-)

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 28 Jan 2015 11:07:12 +0100

Le 27/01/2015 03:07, George Michaelson a écrit :
> APNIC 1x1 capture, using 2002: as the source IPv6 address, and the
> Python httpagentparser module to detect OS and Version info.

Thank you.

That is 26501 unique OSs using 2002 in the first hextet of the src.

The number of `uniq` 2002::/48 prefixes was?

There could be more Clients behind 6to4 routers.

Alex

> On Tue, Jan 27, 2015 at 9:31 AM, Mark ZZZ Smith
> <[email-masked] <mailto:[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] <mailto:[email-masked]>>
>     *Cc:* Brian E Carpenter <[email-masked]
>     <mailto:[email-masked]>>; Tore Anderson <[email-masked]
>     <mailto:[email-masked]>>; "[email-masked] <mailto:[email-masked]>"
>     <[email-masked] <mailto:[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. 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.)
>         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.
>     On Wed, Jan 21, 2015 at 9:30 AM, Mark ZZZ Smith
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>
>
>         substantial
>         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
>         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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 28 Jan 2015 11:30:48 +0100 (CET)

> OSes prefer it to IPv4. That was all long ago, but old hardware dies hard.

I have a datapoint here. For instance at least one software version (the 
one that was on the one I used at the time) on the Linksys EA4500, if IPv6 
is set to the default "automatic", it'll do nothing unless it gets a 
DHCPv6-PD or other signalling. If you however turn it to "off" (I believe, 
this was two years ago), it'll start to do 6to4 and send out RAs on the 
wifi/LAN ports with the derived IPv4-GUA 6to4 IPv6 prefix.

So there might very well be plenty of people out there who changed 
something on their home gateway, didn't know what they did, but now 
they're running 6to4 and they have no idea about it and it's not something 
they want to do.

Here is my email about this I found from two years ago:

http://lists.cluenet.de/pipermail/ipv6-ops/2013-February/008520.html

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jan 2015 09:08:51 +1300

Hi Lorenzo,

...
> be sufficient to obsolete it?

I am now sitting next to the Independent Series Editor at the NZNOG
meeting in warm, sunny Rotorua and he sees no problem of principle
in doing this, but we should ensure that it's checked with the ISE
during the IESG process. He would probably check with the original
authors of RFC 6732 to be sure. Therefore this will need to be noted
in the document writeup when the draft is passed on from the WG.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 29 Jan 2015 16:26:34 +1300

On 28/01/2015 09:04, David Farmer wrote:
> 6to4-PMT is basically a special case anycast relay and return relay bolted together and to a 66 prefix translator.  So, would a
> 6to4-PMT version of the relay operator recommendation be applicable.
> 
> Or, maybe better yet consolidate the three different relay operator recommendations into a generic and unified 6to4 relay
> recommendation for all relay type, like;
> 
> Current operators of all 6to4 relays (anycast using 192.88.99.1, return using 2002::/16 , or 6to4-PMT) SHOULD review the
> information in [RFC6343] and the present document, and then consider carefully whether the 6to4 relay can be discontinued as
> traffic diminishes.

I'm reluctant to do that, because the decisions about forward and reverse relays
are quite independent and should not be viewed as a single decision point.

   Brian

---

From: Mark ZZZ Smith <[email-masked]>
Date: Sun, 1 Feb 2015 05:03:21 +0000 (UTC)

----- Original Message -----
From: Mikael Abrahamsson <[email-masked]>
To: IPv6 Ops WG <[email-masked]>
Cc: 
Sent: Wednesday, 28 January 2015, 21:30
Subject: Re: [v6ops] draft-ietf-v6ops-6to4-to-historic WGLC

* It's quite a while since I had access to one, however the FrizBox CPE were perceived to be a good IPv6 CPE in around 2010, yet they tried to do some 'interesting' things with IPv6/IPv6 access (ULAs with all zeros random part, dynamically *switch* between ULA and GUA prefixes based on the state of the ADSL interface). I have a very faint glimpse of memory that they also might have tried to do something like enabling 6to4 if native IPv6 wasn't available (perhaps if IPv6 was globally enabled).