Subject: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt

From: "Fred Baker (fred)" <[email-masked]>
Date: Sat, 13 Dec 2014 06:56:58 +0000

Begin forwarded message:

> From: Keith Moore <[email-masked]>
> Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-6to4-to-historic-09.txt
> Date: December 12, 2014 at 4:56:26 PM PST
> To: Brian E Carpenter <[email-masked]>
> Cc: "Fred Baker (fred)" <[email-masked]>, "[email-masked]" <[email-masked]>
> 
> Section 1:
>    There would appear to be little evidence of substantial active use of
>    the original form of 6to4 described in [RFC3056]. 
> 
> This statement is unsupported, and I believe, superfluous.    Such a statement might be supportable via traffic measurements, depending on how the measurements were done.   But traffic measurements are often misinterpreted, and without a reference describing actual methods and results there's no way for the reader to assess the validity of the statement.   Whether it's a defensible statement also depends on what "substantial" means.    Anyway, the document would be stronger without it, as the document shouldn't really be about RFC 3056.
> 
> Recommendation: delete this sentence.
> 
>    [RFC6343] analyses the known operational issues in detail and
>    describes a set of suggestions to improve 6to4 reliability, given the
>    widespread presence of hosts and customer premises equipment that
>    support it.  However, experience shows that operational failures have
>    continued despite this advice being available.  Fortunately the
>    advice to disable 6to4 by default has been widely adopted in recent
>    operating systems, and the failure modes have been largely hidden
>    from users by many browsers adopting the "Happy Eyeballs" approach
>    [RFC6555].  Nevertheless, a substantial amount of 6to4 traffic is
>    still observed and the operational problems caused by 6to4 still
>    occur.
> 
>    Although facts are hard to obtain, the remaining successful users of
>    anycast 6to4 are likely to be on hosts using the obsolete policy
>    table [RFC3484] (which prefers 6to4 above IPv4), without Happy
>    Eyeballs, with a route to an operational anycast relay, and accessing
>    sites that have a route to an operational return relay.
> Taken together these statements seem confusing at best.   Here's my attempt to sort things out:   
> 
> Measures that have been taken in the past (recommending disabling 6to4 by default, use of happy eyeballs) have had some useful effect.  
> However some hosts are still observed (again, without any reference to the observations) to use 6to4 and have operational problems doing so.   
> Presumably the hosts that are still having operational problems are those that have, for whatever reason, failed to implement those measures (perhaps because they are running obsolete code, perhaps because they are behind routers that implement 6to4).   (Perhaps it is believed that publishing additional RFCs discouraging 6to4 use will help reduce those problems, as if somehow users will upgrade their systems and/or routers because we publish more RFCs.)
> 
> Much of the latter paragraph seems completely unsupportable.   The RFC3484 prefix selection table doesn't affect address selection for applications requiring or deliberately preferring IPv6 (say to circumvent NAT) and having only a single IPv6 address.  (Perhaps the authors are under the impression that the only hosts anyone wishes to communicate with using anycast 6to4 are those which also have IPv4 addresses, or the only apps using IPv6 are those which could work equally well through IPv4 NAT?)   Happy Eyeballs isn't generally applicable to all applications using IPv6, and even when it's useful only helps if there are multiple source/destination address pairs from which to choose.   Again, it's not correct to assume that either end of traffic using 6to4 has an IPv4 address that would work better for that application.  Just to pick one example, I've seen bittorrent use IPv6 addresses, including 6to4 addresses, when doing so would circumvent NAT brain-damage.
> 
> Of course successful use of 6to4 does require routes to working relays in both directions.
> 
> Recommendation: reword the former paragraph and (especially) delete the latter one.
> 
>    IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969]
>    explicitly builds on the 6to4 mechanism, and could be viewed as a
>    superset of 6to4, using a service provider prefix instead of
>    2002::/16.  However, the deployment model is based on service povider
>    support, such that 6rd can avoid the problems described here.  In
>    this sense, 6rd can be viewed as superseding 6to4 as described in
>    section 4.2.4 of [RFC2026].
>  
> While 6rd is indeed useful, and it seems like a good solution for access providers wishing to provide their customers with an interim IPv6 solution until they deploy native IPv6, it is  misleading to call it a "superset" of 6to4 or to claim that it supersedes it.  6rd would be better described as a subset, since it's potentially applicable in fewer situations than 6to4 is.   Or perhaps it would be better to say that 6rd and 6to4 have different use cases.   In particular, 6rd doesn't provide any help to a user needing to reach IPv6 hosts if the ISP to which he's currently connected doesn't support it.
> 
> Recommendation: delete the paragraph.  6rd is irrelevant to this document.
> 
>    Given that native IPv6 support and various reliable transition
>    mechanisms are now becoming common, the IETF sees no evolutionary
>    future for the 6to4 mechanism.
> 
> Whether native IPv4 support or reliable transition mechanisms are "becoming common" depends on your definition of "common", but we're still a long way from a point where such mechanisms are generally available and applicable to ordinary users.   The main reason that there's no evolutionary future for the 6to4 mechanism is exhaustion of IPv4 address space and widespread deployment of NAT including carrier-side NAT.    (The problems with use of anycast could be fixed if there were much to be gained by fixing them, but the inevitably-increasing use of carrier-side NAT means there's really no point in doing so.)   Also, the paragraph could be taken to mean that these "reliable transition mechanisms" are good substitutes for 6to4, when reality is that there is currently no good replacement for 6to4.
> 
> Recommendation: reword to say "Given that due to exhaustion of IPv4 address space carrier-side NAT is now becoming common, the IETF sees no evolutionary future for the 6to4 mechanism"
> 
> Section 3:
> 
>                           With the increased deployment of IPv6, the
>    mechanism has been shown to have a number of fundamental
>    shortcomings.
> 
> Some of these shortcomings are not specifically shortcomings with 6to4, but rather shortcomings of original address selection rules (which incorrectly assumed that any v6 path would work at least as well as any v4 path), the Internet architecture itself (poor support for multihomed hosts which manifests in several ways and persists to this day) 
> 
>    o  Use of relays. 6to4 depends on an unknown third party to operate
>       the relays between the 6to4 cloud and the native IPv6 Internet.
> 
> I think this is redundant with the 3rd bullet, and the 3rd bullet states it better.
>    o  The placement of the relay can lead to increased latency, and in
>       the case the relay is overloaded, packet loss.
> 
> While this statement is true on its face, it's sort of meaningless or misleading.    It begs the question "increased latency as compared to what?"   6to4 actually did a fairly good job of finding nearby relays in both directions if they were available - often providing lower latency better than configured tunnels except those provided by one's own ISP.   
> 
> The real problem was with the original address prefix selection algorithm and its implicit assumption that any IPv6 path would be better than any IPv4 path.    If ISPs around the world had deployed native IPv6 15 years ago but initially with suboptimal routing, the same problem of decreased latency would have appeared due to hosts' blind preference of v6 over v4.   
> 
> For that matter, the intended purpose of 6to4 (or for that matter IPv6) never was to facilitate communications between hosts or application peers that could just as well use IPv4.
>    o  There is generally no customer relationship between the end-user
>       and the relay operator, or even a way for the end-user to know who
>       the relay operator is, so no support is possible.
> 
> Agreed.
>    o  A 6to4 relay for the reverse path and an anycast 6to4 relay used
>       for the forward path, are openly accessible, limited only by the
>       scope of routing. 6to4 relays can be used to anonymize traffic and
>       inject attacks into IPv6 that are very difficult to trace.
> 
> Two things: The first statement is true but as far as I can tell only half of it is relevant - the "reverse" (6->4) path relay doesn't permit anonymizing traffic as far as I can tell.  The "forward" (4->6) path relay permits anonymizing traffic if the relay doesn't check that the IPv4 source address on the inbound packet is consistent with the IPv6 source address on the inbound packet.   Otherwise, the degree of anonymizing possible is about the same as with NAT44 - the rest of the network can't tell which host the traffic came from but it can tell which network it came from.
> 
>    o  6to4 may silently discard traffic in the case where protocol (41)
>       is blocked in intermediate firewalls.  Even if a firewall sent an
>       ICMP message unreachable back, an IPv4 ICMP message rarely
>       contains enough of the original IPv6 packet so that it can be
>       relayed back to the IPv6 sender.  That makes this problem hard to
>       detect and react upon by the sender of the packet.
> 
> Well, of course it's not 6to4 discarding the traffic, it's the firewalls.   Place the blame where it belongs.   And these problems exist with protocol 41 tunnels in general, including 6rd tunnels, not just 6to4 tunnels.   (It seems especially odd for this document
> to be recommending 6rd as a replacement of sorts for 6to4 while at the same time
> citing 6to4 for shortcomings that are also present with 6rd.)
> 
> There are really two issues here:
> - "accidental" blocking of 6to4 by firewalls (i.e. because of naivete or misconfiguration rather than because of explicit policy)
> - hosts/apps not coping well with blocking of 6to4 by firewalls
> 
> Recommendation: separate into two bullets:
> 
> - 6to4 traffic was sometimes silently discarded by firewalls, either because they blocked
> protocol 41 indiscriminately, or because they blocked incoming traffic flows that weren't initiated by outgoing traffic flows, and were not configured to recognize outgoing flows over protocol 41.   Sometimes this blocking was deliberate, sometimes accidental due to underspecified configuration.
> 
> - Whether or not by accident, when encapsulated traffic was blocked by a IPv4-only firewall, an ICMPv4 response from the firewall was unlikely to be useful to the sender's IPv6 stack, and an IPv4-only firewall generally wouldn't know how to send ICMPv6 responses encapsulated in IPv4, to the sending host.   
> 
> 
> 
>    o  As 6to4 tunnels across the Internet, the IPv4 addresses used must
>       be globally reachable.  RFC 3056 states that a private address
>       [RFC1918] MUST NOT be used. 6to4 will not work in networks that
>       employ other addresses with limited topological span.  In
>       particular it will predictably fail in the case of double network
>       address translation (NAT444).
> 
> This bullet seems very muddy. 
> 
> "As 6to4 tunnels across the Internet"  should say "the IPv4 Internet".   The Internet isn't just IPv4.
> 
> The second sentence seems out of place.   It's not immediately clear what RFC 3056's statement about RFC 1918 addresses has to do with the argument that's being made.
> 
> - The general issue is that 6to4 doesn't work to provide IPv6 access to hosts or routers lacking a globally-scoped and globally-reachable IPv4 address.   This in combination with widespread use of NAT made 6to4 much less useful than it would otherwise have been, and is perhaps the biggest single problem with 6to4.
> 
> - A related problem was that it wasn't clear from the 6to4 specifications that hosts and routers supporting 6to4 needed a reliable way to detect that they had globally-scoped and globally-reachable IPv4 addresses.  RFC 1918 addresses were excluded by RFC 3056, but other unsuitable IPv4 addresses were not as easily recognized.   
> 
> - Some 6to4 implementations were once known to enable 6to4 by default for any non-RFC1918 address, having the effect of enabling a IPv6 address and interface that would never work, and (in the absence of modern address selection rules or happy eyeballs) causing traffic to be blackholed.   However this problem has largely been fixed.
> 
> As far as I can tell, the problem with double NAT is just one example of the general problem.   Even a single layer of NAT breaks 6to4.
> 
> Recommendation: reword the above bullet into two separate bullets, along the lines above.
> 
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 14 Dec 2014 09:08:31 +1300

Hi Keith,

Document editor hat off:

On 13/12/2014 19:56, Fred Baker (fred) wrote:
>> This statement is unsupported, 

Well, proving a negative is always hard. I personally have seen no
evidence of any usage whatsoever of the pure RFC 3056 mechanism.
I used my contacts in the IP trace collecting world to see if any
trace files from ISPs or IXPs are available that would allow 6to4
usage to be measured, and failed. I have also never seen any
information suggesting the existence of the type of operator
agreements needed for routing according to sections 5.2.2.1 or
5.2.2.2 of RFC 3056.

> and I believe, superfluous.

That's defensible. But some kind of introductory sentence is needed.
Any suggestion?

> Such a statement might be supportable via traffic measurements, depending on how the measurements were done.   But traffic measurements are often misinterpreted, and without a reference describing actual methods and results there's no way for the reader to assess the validity of the statement.   Whether it's a defensible statement also depends on what "substantial" means.    Anyway, the document would be stronger without it, as the document shouldn't really be about RFC 3056.
>>

>> Taken together these statements seem confusing at best.   

Well, it's a matter of judgment of course, but I disagree. I don't see
any confusion.

> Here's my attempt to sort things out:   
>>
>> However some hosts are still observed (again, without any reference to the observations) to use 6to4

We have observations from a couple of sources (Google, which
whether you like it or not, sees traffic from a very large
proportion of ordinary users, and Geoff Huston's work, which
obviously sees a much more restricted cross-section of users).
It's above my pay grade to decide, but this document doesn't seem
like the place for a detailed report on those observations.

> and have operational problems doing so.

Actually, the operational problems that we know about are reported
indirectly by operators, via help desk hassles, not by users.

>> Presumably the hosts that are still having operational problems are those that have, for whatever reason, failed to implement those measures (perhaps because they are running obsolete code, perhaps because they are behind routers that implement 6to4).

Undoubtedly. I'm big-headed enough to believe that if RFC 6343 had
been universally and completely implemented, there would be no more
problems ;-). But we know, for example, that ~10% of the Windows market
is still Windows XP, which means RFC 3484.

> (Perhaps it is believed that publishing additional RFCs discouraging 6to4 use will help reduce those problems, as if somehow users will upgrade their systems and/or routers because we publish more RFCs.)

No, of course not, from one day to the next. It will still take
years for this to work through the network as a whole.

>>
>> Much of the latter paragraph seems completely unsupportable.   The RFC3484 prefix selection table doesn't affect address selection for applications requiring or deliberately preferring IPv6 (say to circumvent NAT) and having only a single IPv6 address.

No. It affects ordinary users with ordinary applications.

> (Perhaps the authors are under the impression that the only hosts anyone wishes to communicate with using anycast 6to4 are those which also have IPv4 addresses, or the only apps using IPv6 are those which could work equally well through IPv4 NAT?)

I am under that impression as far as the large majority of users goes, yes.

> Happy Eyeballs isn't generally applicable to all applications using IPv6, and even when it's useful only helps if there are multiple source/destination address pairs from which to choose.   Again, it's not correct to assume that either end of traffic using 6to4 has an IPv4 address that would work better for that application.

I only make that assumption for the large majority of users, who do
most things through an HTTP browser.

> Just to pick one example, I've seen bittorrent use IPv6 addresses, including 6to4 addresses, when doing so would circumvent NAT brain-damage.

Definitely. That's the largest known use case for peer-to-peer 6to4.
afaik, the draft does nothing to damage that use case.

>> Recommendation: reword the former paragraph and (especially) delete the latter one.

I disagree.

>> While 6rd is indeed useful, and it seems like a good solution for access providers wishing to provide their customers with an interim IPv6 solution until they deploy native IPv6, it is  misleading…

I agree that the word "superset" is slightly off target. But it is an
objective fact that 6rd builds on 6to4; I could root out early email
from 6rd's designer to justify that.

The 6rd use case is (and always has been) to get the benefits of 6to4
without the problems, by relying on ISP support. However, I also
agree that the last sentence "In this sense..." is a bit OTT.

>> Recommendation: reword to say "Given that due to exhaustion of IPv4 address space carrier-side NAT is now becoming common, the IETF sees no evolutionary future for the 6to4 mechanism"

That's a judgment call. I'm like "shrug".

>>    mechanism has been shown to have a number of fundamental

I have an alternative proposal for all the bullet points. Just replace the
whole list with this:

 With the increased deployment of IPv6, the
 mechanism has been shown to have a number of fundamental
 shortcomings that are fully described in [RFC6343].

Anyway, with my document editor hat on: I await instructions
from the WG Chairs and AD.

    Brian

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

---

From: Keith Moore <[email-masked]>
Date: Sat, 13 Dec 2014 19:48:08 -0500

> evidence of any usage whatsoever of the pure RFC 3056 mechanism.

I've certainly used it, I think before RFC 3056 was even published.   
Before NAT became commonplace, it was a great way to facilitate remote 
access to my hosts at home.   Even after NAT became the norm while 
roaming, it was useful to communicate between individual hosts residing 
on networks that each had 6to4-capable routers.   Of course, that's not 
evidence of substantial use.

I think it would be hard to establish evidence of substantial use (or 
lack thereof), because that would require measurement of not only the 
number of IPv4 protocol 41 packets, but also the number of such packets 
where both source and destination IPv6 addresses in the IPv4 payload had 
2002: prefixes.   And you'd need to measure it at several well-chosen 
and geographically dispersed points to have confidence in the conclusion.
> That's defensible. But some kind of introductory sentence is needed.

My understanding is that the things that motivated writing this document 
were that:
(a) anycast 6to4 was observed to be often unreliable, and
(b) this had the effect of discouraging deployment of IPv6 access to 
services already accessible via IPv4, and perhaps discouraging user 
acceptance of IPv6 in general.
Something along those lines seems like an appropriate introduction to 
this document.

> like the place for a detailed report on those observations.

I am presuming that Google most sees traffic exchanged with Google's 
servers, which are mostly accessible via either IPv4 and IPv6. That's 
just one kind of use of 6to4, it's not an indication of overall 
"success" using anycast 6to4.

Again, the justification / use case for 6to4 isn't to facilitate 
communication that could just as easily be done using IPv4, it is to 
facilitate communication that could not be done using IPv4, or for which 
using IPv4 would be suboptimal in some way.   So if we're trying to 
measure "success" of 6to4, what needs to be measured is communications 
between peers that don't both have IPv4 addresses, and/or communications 
that would be adversely affected by v4 NAT. HTTP and SMTP aren't 
examples of that kind of traffic.

(Google might be in a good position to see how well 6to4 works with 
webrtc, but that would have to be done by looking at things like how 
often a webrtc connection "fell back" to a STUN/TURN path when there was 
a v6 path available using 6to4 on one or both ends.  )

> is still Windows XP, which means RFC 3484.

Aside: it's really unfortunate that updating old versions of several 
operating systems often cannot be done without one or more of of: 
hardware upgrade, significant service disruption, significant harm to 
usability, user training, admin training, changes in administrative 
procedures, and sometimes tremendous expense due to the need to qualify 
the new hardware/software combination in certain environments (e.g. 
medical, aviation).   There needs to be a way to fix serious defects, 
with minimal disruption, even in older software.   Obviously IETF can't 
fix this, but IETF might actually be able to have some influence over 
this.   (end of rant)

> No. It affects ordinary users with ordinary applications.

There's a widespread, strong, and unfortunate tendency to think that 
"ordinary users with ordinary applications" means pretty much web and 
email, or only client-server apps where the servers are in the "cloud", 
and I don't think that's valid at all.  Ordinary users play distributed 
games, chat, use audio and video telephony, exchange files in various 
ways, all of which benefit from availability of direct peer-to-peer 
communications between users' hosts.   Ordinary users install arbitrary 
apps, with a broad spectrum of uses and communications patterns, on 
their computers and phones.    Moreover, the Internet isn't supposed to 
be only a client-server network.   It is designed to allow arbitrary 
hosts to exchange data with other arbitrary hosts, and we need to defend 
the Internet architecture from attempts to characterize it as, or 
constrain it to be, client-server.

There's also the problem that we've suffered through use of a 
NAT-impaired IPv4 network for so long that we've come to accept as 
"ordinary" applications that suffer from NAT-impairment.   But we 
shouldn't be assuming that IPv6 usage patterns will resemble what is 
"normal" in the NATted IPv4 world.

> I am under that impression as far as the large majority of users goes, yes.

Obviously, I do not share that impression.
> most things through an HTTP browser.

The Internet doesn't just exist to support HTTP, or client-server apps.  
And relative traffic measurements are not a good proxy for the 
importance of particular applications or protocols.

> afaik, the draft does nothing to damage that use case.

You might notice that I didn't actually object to any of the specific 
recommendations made in the current draft, just to the way that the 
situation with 6to4 is characterized.

> from 6rd's designer to justify that.

No argument there.

> agree that the last sentence "In this sense..." is a bit OTT.
I just think that this paragraph inaccurately conveys the notion that 
6rd is an adequate substitute/replacement for all uses of 6to4, when 
it's not.   However, 6rd is generally a good substitute/replacement for 
6to4 for users whose ISP is providing the 6rd service *, and I have no 
problem with this document saying that.

* presuming that the hardware that they supply to customers actually 
supports that service, unlike one of my current ISPs.

> That's a judgment call. I'm like "shrug".

This sentence could give the reader the impression that there are 
commonly available replacements/substitutes available for 6to4, and 
that's simply not the case at the present time.

And why not place the blame where it belongs?   The main reason that 
6to4 isn't more widely applicable, and is not worth fixing, is that the 
IPv4 Internet has become so dysfunctional that you can't even count on 
it to carry packets intact from source to destination anymore.   We had 
an opportunity to facilitate a much easier transition to native v6, and 
we blew it by not insisting that all v4 NATs (especially carrier-side 
NATs) support a well-engineered, standard, v6 transition mechanism.

>   shortcomings that are fully described in [RFC6343].

While I might quibble with the word "fully", overall that seems like a 
reasonable approach.  In general I find the RFC6343 discussion of 6to4 
issues more readable, more comprehensive, and more objective than those 
in 6to4-to-historic.    Not rehashing those issues in the context of 
this draft makes good sense to me.

Keith

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 18 Dec 2014 10:28:03 +0100

Le 13/12/2014 21:08, Brian E Carpenter a écrit :
[...]
> obviously sees a much more restricted cross-section of users).

When people say google stats, do they mean IPv6 or 6to4 use?  I am still 
looking for relevant and recent statistics about the use of 6to4[*].

Because the earlier 6to4 statistics (vyncke, potaroo and others [**]) 
show a fair share of 6to4 use in IPv6.

Alex
[**]
https://labs.ripe.net/Members/mirjam/content-ipv6-measurement-compilation

[*]I am aware of the following IPv6 stats, but cant see 6to4 in there:
http://v6demon.ipv6observatory.eu/
http://labs.apnic.net/ipv6-measurement/
http://6lab.cisco.com/index.php
http://www.google.com/intl/en/ipv6/statistics.html
http://www.worldipv6launch.org/measurements/
http://v6launch.ripe.net/
http://www.ipv6actnow.org/info/statistics/
http://www.akamai.com/ipv6
http://www.arbornetworks.com/asert/category/ipv6/
(there is an additional set of per-country efforts to show IPv6 
statistics for Brazil, US, France and maybe others).

---

From: Erik Kline <[email-masked]>
Date: Thu, 18 Dec 2014 19:47:39 +0900

They're probably referring to the data available at
https://ipv6.google.com/ipv6/statistics .

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Dec 2014 16:30:21 +0100

In your letter dated Thu, 18 Dec 2014 10:28:03 +0100 you wrote:
>Because the earlier 6to4 statistics (vyncke, potaroo and others [**]) =
>

I got some statistics for one of our websites. It shows around 30 6to4
addresses out of around 10000 unique IPv6 addresses. Per month.

Based on browser strings, this seems mostly Vista installs. Though there 
is also some MacOS.

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 18 Dec 2014 16:36:11 +0100

> Based on browser strings, this seems mostly Vista installs. Though there 

I checked the IPv6Gate logs earlier today and found both 6to4 and Teredo
at small quantities compared to other requests coming in from almost any
kind of combination of OS, including OSX, Ubuntu and various kinds of
Windows, including "Windows NT 6.3" which thus means that people on
purpose turn 6to4 and Teredo on to get access to *.sixxs.org and
apparently what a lot of naughty (oh, shocker) things they can't get
behind their firewalls...

Greets,
 Jeroen

---

From: "Metzler, Dan J" <[email-masked]>
Date: Thu, 18 Dec 2014 16:45:28 +0000

Hi Alex,

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of Alexandru
> Petrescu
> Sent: Thursday, December 18, 2014 3:28 AM
> To: [email-masked]
> Subject: Re: [v6ops] stats on 6to4 use (was: Fwd: I-D Action: draft-ietf-v6ops-
> 6to4-to-historic-09.txt)
> 
> > We have observations from a couple of sources (Google, which whether
> > you like it or not, sees traffic from a very large proportion of
> > ordinary users, and Geoff Huston's work, which obviously sees a much
> > more restricted cross-section of users).
> 

I don't see how you're going to find any meaningful statistics in the near future.

The problem with using Google for 6to4 stats, to represent internet usage, is that 6to4 is decentralized.  Any stats that anyone posts are a snapshot in time, of one small portion of the internet. (Even if it is Google.)
1) Since 6to4 is a transition technology, it will likely have its ups and downs anyway. There is constant pressure for the number to go up as people implement 6to4 enabled systems.  There is also constant pressure for it to go down as people implement native IPv6 or other transition technologies.  The result is use may be up one day, down the next, and up again the next.
2) In order for a company like Google to become a reliable indicator of 6to4 usage on the internet, Google would have to become the central hub of the internet.  As much as Google fans may like to think so, it isn't really that.
3) And, in order for a company like Google to become a reliable indicator of 6to4, they would need to implement IPv6 only.  (Get rid of their IPv4 infrastructure.)  This is necessary to force 6to4 hosts to actually use the 6to4 connection, and to my knowledge it is not that either.

Keep in mind that properly configured modern hosts will prefer IPv4 over 6to4 in most cases, even if 6to4 is used for access to IPv6 only sites.
(Some older hosts like Windows Vista, might prefer 6to4 over IPv4, but these would be pretty sparse, and are likely the kind of hosts that show up in reports from dual stack networks.)
That means you can measure a given location, and get use of 6to4 at that location, at that point in time, but that limits the usefulness of such a measurement.

> 
> Because the earlier 6to4 statistics (vyncke, potaroo and others [**]) show a
> fair share of 6to4 use in IPv6.
> 

While this indicates that 6to4 is in use, it is likely a conservative estimate.
If a site like Google would entirely shut off their IPv4 connectivity, and advertise only IPv6 for a while, that would provide more interesting statistics.

- Dan

---

From: "Metzler, Dan J" <[email-masked]>
Date: Thu, 18 Dec 2014 16:54:15 +0000

Hi Philip,

> From: v6ops [mailto:[email-masked]] On Behalf Of Philip Homburg
> Sent: Thursday, December 18, 2014 9:30 AM
> To: Alexandru Petrescu
> Cc: [email-masked]
> Based on browser strings, this seems mostly Vista installs. Though there is
> also some MacOS.

If your websites are dual stack, then this is more an indicator of hosts that are configured with 6to4 preferred over IPv4.
In that case, it does not really say anything about 6to4 usage as a whole.

If your websites are IPv6 only, then the numbers are more meaningful.

---

From: Philip Homburg <[email-masked]>
Date: Thu, 18 Dec 2014 18:45:17 +0100

In your letter dated Thu, 18 Dec 2014 16:54:15 +0000 you wrote:
>If your websites are dual stack, then this is more an indicator of hosts that
>are configured with 6to4 preferred over IPv4.

They are dual stacked.

Of course, you can try to extrapolate, what's the percentage of Vista in
overall web clients, ...

The main thing is, there is some use. So it is unwise to actively break 6to4
for those people. At the same time, it is such a small percentage. It is 
probably not worth optimising for those people either.

Personally, I was mostly curious about the browser stats.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Dec 2014 11:09:24 +1300

> https://ipv6.google.com/ipv6/statistics .

Yes, and Lorenzo confirmed on this list that the traffic
identified there as 6to4/Teredo is overwhelmingly 6to4 today.

   Brian