Subject: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

From: Fred Baker <[email-masked]>
Date: Wed, 27 Apr 2011 13:18:24 -0700

I think this should be reworded as "
> 9. "why 6to4 is preventing IPv6 roll out"

> -----------------------------------------
>   - My opinion: There needs to be a clear motivation for why 6to4 is actively preventing 6to4 roll out.
>     I think this clear motivation is somewhat lacking in the current text. The current focus, the way
>     I read it, is on why 6to4 isn't a great protocol, rather a clear description of why 6to4 is actively
>     preventing native IPv6 roll out. There also needs to be a clear end date for implementation of the
>     deprecation, to avoid a transition on a transition. 
> 
>   - But I would suggest that the authors amend the text so that it:
>     i) better motivates that use of 6to4 is actively preventing roll out of native IPv6
>     ii) includes a clear date for full deprecation (perhaps immediately),
>     iii) clarifies what it means to deprecate a protocol whilst still allowing it as a "last resort"
>     (or indeed consider changing it to straight deprecation)
> 
> Action: I'll try to word smith some descriptive text. Appreciate some help Erik/Tore?

Erik/Tore?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Apr 2011 09:19:00 +1200

>> Action: I'll try to word smith some descriptive text. Appreciate some help Erik/Tore?

Quoting the -advisory draft:

  "In many cases, the user may be
   quite unaware that 6to4 is in use, and when the user contacts a help
   desk, in all probability the help desk is unable to correctly
   diagnose the problem.  Anecdotally, many help desks simply advise
   users to disable IPv6, thus defeating the whole purpose of the
   mechanism, which was to encourage early adoption of IPv6."

As far as I can see the evidence *is* anecdotal, so I am not sure
this whole point is strong enough for a normative document. The same
goes for the assertion that 6to4 is diverting effort from real
deployment.

     Brian

---

From: Tore Anderson <[email-masked]>
Date: Thu, 28 Apr 2011 16:22:22 +0200

* Fred Baker

>> Action: I'll try to word smith some descriptive text. Appreciate some help Erik/Tore?

I'll try:

Content providers have no way of performing a gradual IPv6 deployment,
as the presence of an AAAA record in DNS serves as a crude on/off
switch. When an AAAA record is published for a web site, a significant
number of end users on the Internet will attempt to use the 6to4
connectivity in preference to IPv4. This will, due to the performance
and reliability problems 6to4 suffers from
[I-D.ietf-v6ops-6to4-advisory], cause an overall decrease in end-user
reachability and experienced service quality and/or performance of the
web site. In order to avoid this service degradation, a content provider
may simply choose to avoid publishing AAAA records altogether
[I-D.vandevelde-v6ops-harmful-tunnels].

A content provider may compartmentalise the problem by deploying the
technique described in
[I-D.ietf-v6ops-v6-aaaa-whitelisting-implications], however this can not
solve the problem completely as it is impossible to ascertain that there
are no 6to4-users in a whitelisted network. Finally, operating an AAAA
whitelist comes with a considerable maintenance burden, which in itself
might cause a content provider to opt not to deploy neither a whitelist
nor any AAAA records.

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 28 Apr 2011 10:29:24 -0700

Hello Tore,

If such addition is to be made to the draft, I'd suggest to say that impact of this particular problem is limited to nodes not implementing RFC 3484 for the address selection (that is, by market share, a small minority of the nodes), and the operating systems and applications which do not implement RFC 3484 shall be updated.

Thank you,
Dmitry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tore Anderson
Sent: Thursday, April 28, 2011 7:22 AM
To: Fred Baker
Cc: [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

* Fred Baker

I'll try:

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27
_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Tore Anderson <[email-masked]>
Date: Thu, 28 Apr 2011 20:10:05 +0200

* Dmitry Anipko

> If such addition is to be made to the draft, I'd suggest to say that
> impact of this particular problem is limited to nodes not
> implementing RFC 3484 for the address selection (that is, by market
> share, a small minority of the nodes), and the operating systems and
> applications which do not implement RFC 3484 shall be updated.

Hi Dmitry,

I have no problems with that. I'll leave it up to Ole on how to work
that into the text, though.

You're right it's a minority of users that prefer 6to4 over IPv4, but
it's currently about 3 out of 10 Mac users (if my numbers from Norway is
indicative of the global Mac OS X version distribution), which probably
means it's millions of users world-wide. That said,
no released Mac OS X version implements RFC 3484 to the best of my
knownledge; however Apple did fortunately make a change in recent 10.6
Snow Leopard that specifically de-preferred 6to4 to IPv4.

Best regards,

---

From: Ole Troan <[email-masked]>
Date: Thu, 28 Apr 2011 20:37:57 +0200

> Snow Leopard that specifically de-preferred 6to4 to IPv4.

that's only measured at a web site. 
if I understoof Geoff's (cc'ed) analysis correctly, there is a lot of other traffic too.
http://www.potaroo.net/ispcol/2011-04/teredo.html

created by applications doing their 'own' thing and not following the default policy table.

cheers,
Ole

---

From: Martin Millnert <[email-masked]>
Date: Thu, 28 Apr 2011 16:07:41 -0400

Ole, 

part of this is slightly off-topic, to point 9, but highly on-topic in
general.

On Thu, 2011-04-28 at 20:37 +0200, Ole Troan wrote:
<snip>
> created by applications doing their 'own' thing and not following the default policy table.

Yes and no.
Yes, there is a substantial amount of Teredo traffic, yet the protocol
is virtually never used for HTTP.
No, I find no suggestion in his article that this traffic is created by
"applications doing their 'own' thing and not following the default
policy table".  

To take a very real example: the various torrent DHT "clouds" are
teeming with IPv6 end-point addresses.  Connecting to these with Teredo,
if available, is in accordance with 3484, if that is the only v6
connectivity a host has.  The alternative is, of course, to not connect
to them at all.   Same goes for a host using any other form of IPv6
connectivity to make a connection.
  These are not hostnames resolving to A/AAAA records. And even if they
were, as Geoff points out in his article, Windows 7/Vista will not even
resolve the AAAA record, if Teredo is the only non-link-local v6
connectivity a host has! Now we may discuss an operating system not
following the default policy table, but not applications.

Let me drive my point home:

People say/argue Teredo (and 6to4) is bad because many connections fail,
among other problems, but Teredo isn't the black sheep in the automated
v6-tunneling family, and it does address a very real problem (lack of
IPv6 connectivity). I haven't heard a single content provider say they
will hold back deployment of AAAA records because of it.
  The responsible thing for IETF to do wrt. any deprecation of Teredo is
to provide a realistic alternative solution *before* doing so (to
include in a phase-out plan of the protocol, for example), unless it
wants to be tilting at windmills.

If Teredo can be replaced by another protocol addressing the same
problem space, which somehow has a much better connection rate, I would
be all for that :)  If not, the problem does not really truly lie with
the IETF, short of a Teredo-advisory.

I do think this may be showing that 3484 is insufficient when it comes
to addressing (no pun intended) the *varying* connectivity needs of
various applications:  
  Some applications, predominantly such with plenty of redundancy, are
quite fine with a v6 where connections fail 1 out of 3 times. To me this
mostly shows how insufficient non-end-to-end NATed IPv4 is on the
Internet today.
  Other applications really depend on their connections to succeed if
attempted, and would probably prefer to fail with
-EINADEQUATECONNECTIVITYPRESENT, rather than launch a connection attempt
using last-resort connectivity.

More skilled socket API folks than I are highly welcome to school me on
the following idea:
  If OS socket API:s were to provide a way for applications to require
better-than-last-resort connectivity (or inverse, accept last-resort
connectivity), that could be useful for application developers IMO.  
I guess it could be a two-dimensional approach, with the ability to make
or relax this requirement on both the source and the destination
address.

Blizzard recently seems to have figured out to suggest native IPv6 to be
used ("Use IPv6" box default checked with this connectivity present at
the box), but not 6to4/Teredo ("Use IPv6" defaults to unchecked).
This seems IMO like a useful approach in addressing this problem, i.e,
application-specific, since only the application itself can know its
requirements.

Best,
Martin

---

From: Fred Baker <[email-masked]>
Date: Thu, 28 Apr 2011 13:31:51 -0700

> part of this is slightly off-topic, to point 9, but highly on-topic in

Correct me if I'm wrong; the comment is specific to Teredo and not to 6to4, correct?

</chair>
Speaking strictly for myself, I would seriously wonder why the alternative to any overlay architecture is not native deployment. The concern raised with 6to4 is the set of use cases in which it doesn't work as expected, for any of a variety of reasons, and as a result inhibits consumer interest in IPv6 or distracts service provider attention from native deployment. If your statement is that the IETF is irresponsible in pointing out a deployment solution that isn't working as well as hoped for without providing an alternative, I think the IETF has set forth (and service providers are in the process of deploying) a replacement.

What I do not expect the IETF to do is recommend one overlay architecture instead of another. In RFC 6180 (aka draft-arkko-ipv6-transition-guidelines), Jari and I tried to point out things that were known to work in deployment as general advice in "how to get over a bump in the deployment roadmap", but our point was explicitly not to say "deploy this overlay and stop". To our minds, and I understood the working group's mind, the finish-line is "the universal deployment of native IPv6".
<chair>

---

From: Geoff Huston <[email-masked]>
Date: Fri, 29 Apr 2011 06:36:01 +1000

> created by applications doing their 'own' thing and not following the default policy table.

I believe I can confirm this. The recent Ipv6 study by Arbor Networks found a hefty proportion of
peer-to-peer traffic using Ipv6. What I have found is by passive listening to 2400::/12,
where what I see is dominated by high-numbered port TCP connection events, predominated 
from Teredo source addresses.

Extrapolating a bit, what I understand is that a number of popular peer-to-peer
applications now offer IPv6 as an option, and latch onto the V6 interfaces that are present
on the host.

Geoff

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 28 Apr 2011 13:44:20 -0700

As far as I see, these data don't invalidate the statement that for the problem Tore described (IPv6 deployments are affected by 6to4), it is still true that only applications and operating systems not implementing RFC 3484 are affected?

-----Original Message-----
From: Geoff Huston [mailto:[email-masked]] 
Sent: Thursday, April 28, 2011 1:36 PM
To: Ole Troan
Cc: Tore Anderson; Dmitry Anipko; [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

Geoff

---

From: Tore Anderson <[email-masked]>
Date: Thu, 28 Apr 2011 23:02:32 +0200

* Dmitry Anipko

> As far as I see, these data don't invalidate the statement that for
> the problem Tore described (IPv6 deployments are affected by 6to4),
> it is still true that only applications and operating systems not
> implementing RFC 3484 are affected?

Hi again,

Ole pointed out, quite correctly, that my data only revolves around
measurements done from a web site's vantage point. Shame on me for
forgetting for a second that the internet is more than just the web.

Ole is also correct in that applications can do whatever they like.
Opera <= 10.10 is a very good example of this happening, it preferred
Teredo and 6to4 over IPv4, even when running on Windows (which
implements RFC 3484). Fortunately, Opera users have shown themselves to
be good at upgrading, so for HTTP traffic, the problem of applications
doing their own thing is for the most part solved now.

However, I have no idea what the situation is like for any non-HTTP
services; I'm not aware of any focused research here. But if there's a
great number of applications that do their own resolving in a
non-RFC3484 manner, the situation could very well be significantly worse
than it is for HTTP is right now. And even if every single application
for the service in question is well-behaved and uses the operating
system-provided resolver interfaces, there's still too many users using
OSes that do not implement RFC3484 to ignore.

Best regards,

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 28 Apr 2011 14:28:06 -0700

Hello Tore,

>> Ole pointed out, quite correctly, that my data only revolves around
measurements done from a web site's vantage point
>> However, I have no idea what the situation is like for any non-HTTP
services; I'm not aware of any focused research here.

I'm trying to understand - how does this change the problem statement you made in the proposed addition to the draft: "as the hosts behind the 6to4 router will not be aware that its 6to4 connectivity is restricted in scope to other 6to4 sites, and could therefore attempt to use this connectivity for destinations on the global IPv6 Internet"? 

If these data don't affect the problem statement, then you've agreed that the impact of that problem is scoped only to operating systems and applications not following RFC 3484, and I think it would be useful if the proposed text reflected that.

If it does change the problem statement, then does the text you proposed to include in the draft need to be updated to reflect the change, whatever that change is?

>> there's still too many users using OSes that do not implement RFC3484 to ignore

Sure, this sounds like a strong reason for such OSes to be updated to implement RFC 3484, rather than a reason to deprecate 6to4.

Thank you,
Dmitry

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: Thursday, April 28, 2011 2:03 PM
To: Dmitry Anipko
Cc: Geoff Huston; Ole Troan; [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

* Dmitry Anipko

Hi again,

Best regards,

---

From: Geoff Huston <[email-masked]>
Date: Fri, 29 Apr 2011 08:02:32 +1000

> Sure, this sounds like a strong reason for such OSes to be updated to implement RFC 3484, rather than a reason to deprecate 6to4.

Speaking personally, the major reason for me to deprecate 6to4 is its shocking connection failure rate. I have observed in the packet capture that I've been performing (http://www.potaroo.net/ispcol/2010-12/6to4fail.html) is that between 10% to 20% of 6to4 hosts that can successfully emit a SYN fail to emit the followup SYN/ACK in the TCP initial handshake. The predominate reason, as far as I can tell, is inbound protocol 41 filters close to the client, rather than use of non-routed addresses in the embedded IPv4 address of the 6to4 packet. For me this exposes a basic flaw in the auto-tunnelling concept - namely that of unintentional consequences, where a firewall filter set adopts a conservative position with respect to incoming packets, including, presumably, blocking all IP protocols except TCP. UDP and ICMP. Then, in the "inside" someone deploys an out of the box host that will use 6to4 under certain conditions. The result is messy, given that the unit typically waits for a protracted period of resend attempts before ultimately giving up.

Yes, using a local preference table that prefers IPv4 over auto-tunnelled 6to4 will avoid this behaviour for external dual stack services, but where the local application does not use such a preference table, or the external service point is IP6 only, the problem of the protracted wait for failure in up to 1 in 5 cases is, from an unwitting end user perspective, presumably best avoided.

Geoff

---

From: Tore Anderson <[email-masked]>
Date: Fri, 29 Apr 2011 00:15:45 +0200

* Dmitry Anipko

> I'm trying to understand - how does this change the problem statement
> you made in the proposed addition to the draft: "as the hosts behind
> the 6to4 router will not be aware that its 6to4 connectivity is
> restricted in scope to other 6to4 sites, and could therefore attempt
> to use this connectivity for destinations on the global IPv6
> Internet"?
> 
> If these data don't affect the problem statement, then you've agreed
> that the impact of that problem is scoped only to operating systems
> and applications not following RFC 3484, and I think it would be
> useful if the proposed text reflected that.
> 
> If it does change the problem statement, then does the text you
> proposed to include in the draft need to be updated to reflect the
> change, whatever that change is?

Hi Dmitry,

It does not change the problem statement. I did send you a reply a few
hours ago where I did agree with you in that the problem is scoped only
to hosts and applications that do not implement RFC 3484 (or something
similiar to it).

My comments in the previous message was just an observation that even
for HTTP, where the applications are for the most part well-behaved, the
operational problems with 6to4 today remain significant. For services
other than HTTP, the situation is less clear - but even in the best
case, it can't get much better than the already crappy situation we have
with HTTP today.

> Sure, this sounds like a strong reason for such OSes to be updated to
> implement RFC 3484, rather than a reason to deprecate 6to4.

I encourage every OS and application developer to implement RFC 3484.

However, the toothpaste is out of the tube already. Even if we by some
miracle were able to put it back in by making every OS and application
in the world RFC 3484-compliant, my gut feeling is that what we will
then have accomplished amounts to nothing more than chopping another
head off the Hydra that is 6to4-related operational problems. I'm sick
and tired of handling those, there's no end to them. I tried really hard
for a while to do so, but I'm now convinced that 6to4 cannot be salvaged
in any meaningful way. That is why I feel it's high time for the IETF to
abandon the technology altogether by deprecating it.

Best regards,

---

From: Martin Millnert <[email-masked]>
Date: Thu, 28 Apr 2011 18:20:17 -0400

Fred,

> Correct me if I'm wrong; the comment is specific to Teredo and not to 6to4, correct?

Yes, you are right. Overall the comment was mostly specific to Teredo.

> </chair>
> Speaking strictly for myself, I would seriously wonder why the
> alternative to any overlay architecture is not native deployment. 

I agree completely that native IPv6 is the end-goal.

My (before mis-placed) point is simply that recommending the removal of
an overlay protocol (Teredo in this case) without proof of actual
users/providers actually being adversely affected by it (clearly not the
case with 6to4), *will not* in itself result in giving these users
native IPv6.  And leaving the protocol in place, will, likewise, not
give these users access to IPv6 web servers via native IPv6
connectivity.

That was clearly not the topic of point 9, and in retrospect I should've
restricted my response to the lack of evidence of any causality between
the (non-http) traffic levels seen in Teredo with applications not
following the provided 3484 on their host and doing their own thing,
presented in Geoff's thorough research article.

I did continue by offering an explanation on why I believe that largely
to be a completely inaccurate explanation for the traffic measured in
Geoff's work. (Ie, largely, traffic exists with no rule-breaking going
on).

> The concern raised with 6to4 is the set of use cases in which it
> doesn't work as expected, for any of a variety of reasons, and as a
> result inhibits consumer interest in IPv6 or distracts service
> provider attention from native deployment. 

Yes, and I'm also in agreement that phasing out 6to4 is the right action
now.

> If your statement is that the IETF is irresponsible in pointing out a
> deployment solution that isn't working as well as hoped for without
> providing an alternative, I think the IETF has set forth (and service
> providers are in the process of deploying) a replacement.

No, that was not my statement (see above)!

> What I do not expect the IETF to do is recommend one overlay
> architecture instead of another. 

I was not suggesting the IETF to recommend operators to let their users
rely on overlay architectures as the users means of IPv6 connectivity.  
  I very much welcome clear evidence that Teredo is an obstacle to
native deployment.  I don't think it is, and I can't remember seeing any
such evidence so far.  Teredo is there, with a purpose, [and until
proven otherwise, ] it does not hurt native v6 deployment - and
recommending removing it solves nothing.

> In RFC 6180 (aka draft-arkko-ipv6-transition-guidelines), Jari and I
> tried to point out things that were known to work in deployment as
> general advice in "how to get over a bump in the deployment roadmap",
> but our point was explicitly not to say "deploy this overlay and
> stop". To our minds, and I understood the working group's mind, the
> finish-line is "the universal deployment of native IPv6".

No arguments here.  Personally, I believe we can approximate having
reached the finish line to when deploying a single-stack native IPv6
network is the norm.

Best,
Martin

---

From: Dmitry Anipko <[email-masked]>
Date: Thu, 28 Apr 2011 15:27:42 -0700

Hello Tore,

Thank you. It seems to me that you and I are in agreement that if the proposed text regarding "why 6to4 is preventing 6to4 roll out" was to be included, it shall include a statement that the problem is only scoped to implementations not following RFC 3484. This fork of the summary thread was created by the chair specifically on that item of the Ole's summary, and that's why I'm commenting on that.

>> I tried really hard for a while to do so, but I'm now convinced that 6to4 cannot be salvaged in any meaningful way. That is why I feel it's high time for the IETF to abandon the technology altogether by deprecating it.

I understand there can be different arguments that can be discussed as to whether or not to deprecate 6to4. I think if we follow the process suggested by the chair and discuss and evaluate each of the items individually, rather than applying to each of them the same self-justified statement that 6to4 should be deprecated because there is a bunch of problem with it, it will help evaluate validity and scope of each argument more objectively. 

My understanding is that this fork was specifically about "why 6to4 is preventing 6to4 roll out" and you proposed a text which described a specific problem, on which I commented. If you believe there are other problems which are worth describing, then I think the proposed text can be updated to reflect those.

Thank you,
Dmitry

-----Original Message-----
From: Tore Anderson [mailto:[email-masked]] 
Sent: Thursday, April 28, 2011 3:16 PM
To: Dmitry Anipko
Cc: Geoff Huston; Ole Troan; [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

* Dmitry Anipko

Hi Dmitry,

Best regards,

---

From: Tore Anderson <[email-masked]>
Date: Fri, 29 Apr 2011 01:47:33 +0200

Hi again,

* Dmitry Anipko

> Thank you. It seems to me that you and I are in agreement that if the
> proposed text regarding "why 6to4 is preventing 6to4 roll out" was to
> be included, it shall include a statement that the problem is only
> scoped to implementations not following RFC 3484.

Yep. Agreed.

>>> I tried really hard for a while to do so, but I'm now convinced
>>> that 6to4 cannot be salvaged in any meaningful way. That is why I
>>> feel it's high time for the IETF to abandon the technology
>>> altogether by deprecating it.
> 
> I understand there can be different arguments that can be discussed
> as to whether or not to deprecate 6to4. I think if we follow the
> process suggested by the chair and discuss and evaluate each of the
> items individually, rather than applying to each of them the same
> self-justified statement that 6to4 should be deprecated because there
> is a bunch of problem with it, it will help evaluate validity and
> scope of each argument more objectively.
> 
> My understanding is that this fork was specifically about "why 6to4
> is preventing 6to4 roll out" and you proposed a text which described
> a specific problem, on which I commented. If you believe there are
> other problems which are worth describing, then I think the proposed
> text can be updated to reflect those.

The operational problems associated with 6to4 in combination with its
preference to IPv4 (where there's a lack of RFC 3484), is *THE* reason
«why 6to4 is preventing 6to4[sic] roll out». (In turn, this is the
single largest reason why I support deprecating it altogether - my
apologies if this statement was out of place.)

As you've pointed out, omnipresent RFC 3484 support would in theory
solve this concern without any deprecating of 6to4 necessary. It would
of course not solve any of the operational problems with 6to4 itself,
but if it's never being used in preference to IPv4, then it causes no
harm for a HTTP content provider like myself. However, the way I see it,
this solution is unfortunately not realistically achievable.

Best regards,

---

From: Ole Troan <[email-masked]>
Date: Fri, 29 Apr 2011 09:58:59 +0200

Dmitry,

> Sure, this sounds like a strong reason for such OSes to be updated to implement RFC 3484, rather than a reason to deprecate 6to4.

there are many cases where 3484(bis) fails.
http://tools.ietf.org/html/draft-v6ops-multihoming-without-ipv6nat-00

that argument is as much a reason to implement happy eyeballs as well.

cheers,
Ole

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 29 Apr 2011 09:05:15 -0700

> that argument is as much a reason to implement happy eyeballs as well.

RFC 3484 by itself will not help here, because it prefers (unreliable) 6to4
to (much more reliable) NATed IPv4. RFC 3484bis will help, but it may take a
while. In the meantime, we have operational problems ("it doesn't work") to
fix, and what will IETF guidance be? "We know 6to4 is unreliable, but don't
worry, just wait for RFC 3484bis to be published and then you can depref
6to4"? Happy eyeballs is also a bit too far down the road.

Notice that both these solutions don't make 6to4 more reliable, they just
avoid it except as a last resort. The root of the issue is that 6to4 is
unreliable. So think the best way is to acknowledge that and move on.

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 29 Apr 2011 11:47:27 -0700

Hello Lorenzo,

>> RFC 3484 by itself will not help here, because it prefers (unreliable) 6to4 to (much more reliable) NATed IPv4. RFC 3484bis will help, but it may take a while.

If you refer to the draft-ietf-6man-rfc3484-revise-02 section 2.4, I agree that the original RFC 3484 doesn't address that, but as draft-ietf-6man-rfc3484-revise-02 section 2.4 notices, some OSes have already implemented this change already.

For example, all Windows hosts which have IPv6 enabled by default have this change implemented and choose NAT IPv4->IPv4 instead of using 6to4->Native. So at least 89.5% of hosts (per most recent Netmarketshare data) on the Internet already are not affected by the "why 6to4 is preventing 6to4 roll out", as described in the text proposed by Tore, and I think a fair text describing the problem shall reflect the scope of the problem correctly.

Thanks,
Dmitry

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, April 29, 2011 9:05 AM
To: Ole Troan
Cc: Dmitry Anipko; [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

RFC 3484 by itself will not help here, because it prefers (unreliable) 6to4 to (much more reliable) NATed IPv4. RFC 3484bis will help, but it may take a while. In the meantime, we have operational problems ("it doesn't work") to fix, and what will IETF guidance be? "We know 6to4 is unreliable, but don't worry, just wait for RFC 3484bis to be published and then you can depref 6to4"? Happy eyeballs is also a bit too far down the road.

Notice that both these solutions don't make 6to4 more reliable, they just avoid it except as a last resort. The root of the issue is that 6to4 is unreliable. So think the best way is to acknowledge that and move on.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 29 Apr 2011 12:09:06 -0700

On Fri, Apr 29, 2011 at 11:47 AM, Dmitry Anipko <[email-masked]
> wrote:

>  For example, all Windows hosts which have IPv6 enabled by default have
> this change implemented and choose NAT IPv4->IPv4 instead of using
> 6to4->Native. So at least 89.5% of hosts (per most recent Netmarketshare
> data) on the Internet already are not affected by the "why 6to4 is
> preventing 6to4 roll out", as described in the text proposed by Tore, and I
> think a fair text describing the problem shall reflect the scope of the
> problem correctly.
>

Sure. If you want, we can have the text say that if you only want 89.5%
connectivity, then 6to4 is fine.

---

From: Fred Baker <[email-masked]>
Date: Fri, 29 Apr 2011 12:31:14 -0700

> For example, all Windows hosts which have IPv6 enabled by default have this change implemented and choose NAT IPv4->IPv4 instead of using 6to4->Native. So at least 89.5% of hosts (per most recent N…

</chair>
As of 10.6.5, which is to say "rather a while back", that's also true of Apple. That has made a big difference for Apple users.

That said, it doesn't really address the issue - if anything, it confirms the observation in the draft. The observation is that the use of 6to4 results in unreliable connectivity, and that a service that appears to a user to be unreliable is not acceptable to a content provider. Your assertion is, in essence, that in the presence of IPv4 connectivity, hosts will choose that over 6to4.  So, great, said hosts are using 6to4 significantly less. WHEN THEY USE 6TO4, they still have a problem - 6to4 is not a wonderful service as found in the wild. The proposal is to tell vendors that, by default, they should not enable 6to4, and the observation in the draft (confirmed last night in private email that I was told was confidential as to the parties involved) is that the unreliability of the service is a reason given for closely managing IPv6 deployment - non-deployment, whitelisting, and so on.

<chair>
I'm not sure how throwing around Microsoft's market dominance helps this discussion. It's certainly not pertinent to the topic of the thread.

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 29 Apr 2011 12:56:31 -0700

Hello Fred,

There was no intent to "throw around" any particular operating system dominance - it is unfortunate if an attempt to clarify the scope of the problem and perform analysis based on facts is interpreted that way. 

This thread was started by the chair with a request whether Erik & Tore can help with the text describing " motivation for why 6to4 is actively preventing 6to4 roll out". 

Such text was proposed by Tore. In my opinion, given that > 90% (and I'm happy that more and more Internet users do not experience problem now that Apple OS starting from 10.6.5) of hosts are not affected by the problem, should be reflected by that text. Tore agreed with such clarification, so I don't have any other comments on that, unless the facts (that > 90% of the hosts - including Apple, Microsoft implementations, and possibly others, are not affected by the issue) are questioned.

Thank you,
Dmitry

-----Original Message-----
From: Fred Baker [mailto:[email-masked]] 
Sent: Friday, April 29, 2011 12:31 PM
To: Dmitry Anipko
Cc: Lorenzo Colitti; Ole Troan; [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

</chair>

<chair>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 29 Apr 2011 13:44:04 -0700

On Fri, Apr 29, 2011 at 12:31 PM, Fred Baker <[email-masked]> wrote:

> the observation in the draft (confirmed last night in private email that I
> was told was confidential as to the parties involved) is that the
> unreliability of the service is a reason given for closely managing IPv6
> deployment - non-deployment, whitelisting, and so on.
>

Absolutely. The reason we (Google) cannot publish AAAA records for our
services today is because we have data that shows that a non-trivial number
of users will experience connection problems if we did so. That is the
reason we employ DNS whitelisting: it's the only way to get any IPv6
deployment at all without causing unacceptable breakage.

We have evidence that broken 6to4 connections are a large part of the
problem. For example, the dual-stack connection failure rate for Mac OS
10.6.4 among Google users is *over one percent*, while the connection
failure rate for Mac OS 10.6.5 is over 20x lower. The difference, of course,
is that 10.6.5 deprefs 6to4 by default.

Geoff Huston and RIPE NCC have also done measurements that indicate that
connection failure rates of users that have 6to4 is between 10 and 20%. I
think we all agree that that is unreliable; from a content provider
perspective, it's unacceptable.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 29 Apr 2011 13:57:15 -0700

On Fri, Apr 29, 2011 at 12:56 PM, Dmitry Anipko <[email-masked]

> Such text was proposed by Tore. In my opinion, given that > 90% (and I'm
> happy that more and more Internet users do not experience problem now that
> Apple OS starting from 10.6.5) of hosts are not affected by the problem,
> should be reflected by that text. Tore agreed with such clarification, so I
> don't have any other comments on that, unless the facts (that > 90% of the
> hosts - including Apple, Microsoft implementations, and possibly others, are
> not affected by the issue) are questioned.
>

I think that saying "90% of Internet hosts are not affected by this problem"
provides the impression that this is not an important problem.
Unfortunately, the contribution of that 10% of hosts to overall IPv6
reliability is very high, simply because 6to4 *is so much less reliable*
than native IPv4 and native IPv6 that its contribution to availability is
disproportionate.

To pull numbers out of the air as an example: say IPv4 works 99.99% of the
time, and say 6to4 works only 90% of the time (though it's actually less
than that). If 1% of users use 6to4, by publishing an AAAA record
reliability will be approximately 99%, which is 100 times worse than
the 99.99% you'd have if you stuck with IPv4 only.

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 29 Apr 2011 14:32:15 -0700

Hello Lorenzo,

90% was a bottom estimate, easy to figure out from the available sources. The actual number of not affected hosts is probably much higher (and the numbers you quoted based on Google data in parallel fork seem to confirm that).

>> I think that saying "90% of Internet hosts are not affected by this problem" provides the impression that this is not an important problem.

I'd rather say that it allows to reflect more accurately the importance of the problem, whether that is small or large, without making incorrect impression that the whole Internet is broken because of 6to4. If instead we are solving the problem for 1% of users (or whatever the number is), why not state as such - if people think that is important, as well as that that problem could actually be solved in a least invasive way, by updating implementations not following standard address selection recommendations.

Thank you,
Dmitry

From: Lorenzo Colitti [mailto:[email-masked]]
Sent: Friday, April 29, 2011 1:57 PM
To: Dmitry Anipko
Cc: Fred Baker; Ole Troan; [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

On Fri, Apr 29, 2011 at 12:56 PM, Dmitry Anipko <[email-masked]<mailto:[email-masked]>> wrote:
Such text was proposed by Tore. In my opinion, given that > 90% (and I'm happy that more and more Internet users do not experience problem now that Apple OS starting from 10.6.5) of hosts are not affected by the problem, should be reflected by that text. Tore agreed with such clarification, so I don't have any other comments on that, unless the facts (that > 90% of the hosts - including Apple, Microsoft implementations, and possibly others, are not affected by the issue) are questioned.

I think that saying "90% of Internet hosts are not affected by this problem" provides the impression that this is not an important problem. Unfortunately, the contribution of that 10% of hosts to overall IPv6 reliability is very high, simply because 6to4 *is so much less reliable* than native IPv4 and native IPv6 that its contribution to availability is disproportionate.

To pull numbers out of the air as an example: say IPv4 works 99.99% of the time, and say 6to4 works only 90% of the time (though it's actually less than that). If 1% of users use 6to4, by publishing an AAAA record reliability will be approximately 99%, which is 100 times worse than the 99.99% you'd have if you stuck with IPv4 only.

---

From: Martin Millnert <[email-masked]>
Date: Fri, 29 Apr 2011 18:01:25 -0400

Lorenzo, Dmitry,

loosely summarizing your two points:

On Fri, 2011-04-29 at 13:57 -0700, Lorenzo Colitti wrote:
> On Fri, Apr 29, 2011 at 12:56 PM, Dmitry Anipko 
>> ~ ">90% 6to4 hosts are OK" 
> 
> "10% broken 6to4 hosts *is* a show stopper for AAAA publishing due 
> to the scale of the Internet".

I think this is perfectly fine to formulate and include in the document.
I have no doubt that we can stay factual and still achieve the goal of
coming through with good arguments for vendors to convince themselves to
disable 6to4 by default [on new products*].

Regards,
-- 
Martin Millnert <[email-masked]>

* If the goal is to make vendors push changes to old code/products, I'm
not sure this document will achieve its goal regardless of formulation
of point 9, simply according to what has already been quite clearly
stated on this list wrt. the document previously. Perhaps, a more
reasonable goal of the document should be good internet engineering?
(It's the I*E*TF after all?)

---

From: Dmitry Anipko <[email-masked]>
Date: Fri, 29 Apr 2011 15:13:17 -0700

I'd agree with such phrasing if the number quoted is based on data (and it surely can be e.g. based on Google measurements), and there is a discussion why other mitigations such as deprioritization 6to4 on hosts are not sufficient.

of point 9

I agree with that. And if the problem is there (for whatever number of users), it may actually be a faster and more efficient way to address that problem to update the OS/apps to depref 6to4 (my understanding is that OSes do have update channels, while for IGDs, at best, user involvement is required).

Thank you.

-----Original Message-----
From: Martin Millnert [mailto:[email-masked]] 
Sent: Friday, April 29, 2011 3:01 PM
To: Lorenzo Colitti
Cc: Dmitry Anipko; [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

Lorenzo, Dmitry,

Regards,

---

From: Mohacsi Janos <[email-masked]>
Date: Sat, 30 Apr 2011 15:59:18 +0200 (CEST)

On Fri, 29 Apr 2011, Lorenzo Colitti wrote:

> RFC 3484 by itself will not help here, because it prefers (unreliable) 6to4 to (much more reliable) NATed
> IPv4. RFC 3484bis will help, but it may take a while. In the meantime, we have operational problems ("it
> doesn't work") to fix, and what will IETF guidance be? "We know 6to4 is unreliable, but don't worry, just
> wait for RFC 3484bis to be published and then you can depref 6to4"? Happy eyeballs is also a bit too far
> down the road.

All the current RFC 3484 implementations I am aware of treats RFC 1918 
IPv4 addresses as a global scope address -> NATed IPv4 prefered to 6to4 
and Teredo. -> It was one reason to revise RFC 3484.

Regards,
 	Janos

> 
> Notice that both these solutions don't make 6to4 more reliable, they just avoid it except as a last
> resort. The root of the issue is that 6to4 is unreliable. So think the best way is to acknowledge that and
> move on.
> 
>

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 30 Apr 2011 11:38:54 -0700

Thanks Janos. Lorenzo, if Google has such data regarding client brokenness, is it possible to share the OS/browser type distribution of those broken clients coming specifically from 6to4 source addresses? 

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mohacsi Janos [[email-masked]]
Sent: Saturday, April 30, 2011 6:59 AM
To: Lorenzo Colitti
Cc: [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

Regards,
        Janos

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 30 Apr 2011 11:49:43 -0700

On Sat, Apr 30, 2011 at 11:38 AM, Dmitry Anipko <[email-masked]

> Thanks Janos. Lorenzo, if Google has such data regarding client brokenness,
> is it possible to share the OS/browser type distribution of those broken
> clients coming specifically from 6to4 source addresses?
>

Not sure we can share data. What's the question?

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 30 Apr 2011 11:51:59 -0700

On Sat, Apr 30, 2011 at 6:59 AM, Mohacsi Janos <[email-masked]> wrote:

> All the current RFC 3484 implementations I am aware of treats RFC 1918 IPv4
> addresses as a global scope address -> NATed IPv4 prefered to 6to4 and
> Teredo. -> It was one reason to revise RFC 3484.
>

What about Windows XP? It's true that it has IPv6 off by default, but
various popular P2P clients appear to enable IPv6 when they are installed.

---

From: Martin Millnert <[email-masked]>
Date: Sat, 30 Apr 2011 15:45:38 -0400

Dmitry,

> Thanks Janos. Lorenzo, if Google has such data regarding client brokenness, is it possible to share the OS/browser type distribution of those broken clients coming specifically from 6to4 source add…

Tore has public data at http://www.fud.no/ipv6/ with some presented
OS/browser drill-down. Do see his note about 2010-12-21.
Emile and Geoff have done similar studies:
https://labs.ripe.net/Members/emileaben/6to4-how-bad-is-it-really
http://www.potaroo.net/ispcol/2010-12/6to4fail.html

but Tore's the only one I know of that continuously publishes the (now
flawed?) data.

Regards,
Martin

---

From: Martin Millnert <[email-masked]>
Date: Sat, 30 Apr 2011 16:35:12 -0400

Oops, forgot one data point:
http://www.google.com/intl/en/ipv6/statistics/

With this public data we can make an educated guess to Goog's total
client loss due to 6to4:
  % successful connections to A/AAAA from 6to4/Teredo: 0.05% (today and
2010-12-21).
  From Tore we can infer that 99% of these 6to4/Teredo connections are
6to4, and 1% Teredo. I round to 100% 6to4.
  Emile at RIPE reports around 15% failure on 6to4 connections, with
failures on the inbound path from the client masked. (how big is the X
here?)

=> 0.15 * (0.0005/0.85) = 0.009% total client loss from 6to4 failure,
minimum (see X above).  
This number is in the ballpark of Tore's total client loss which as of
2010-12-21 was 0.016% (trending down quite sharply, but measurement data
became polluted from that day). There are likely differences between
regions and global overall data. (% clients using public IPv4 on their
host, for example)

This gives us an idea of what failure rate is considered too much, which
is what point 9 was about, right?

Personally I'd find it interesting to see a greater breakdown on what
OS/browsers are behind this, but I'm honestly not sure it is necessary
to answer point 9?
  That is unless the document is to state something like "Due to
(vendor,browser) {(X1,Y1),(X2,Y2),...,(Xn,Yn)}, 6to4 has to be made
historic.".

/M

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 30 Apr 2011 16:36:42 -0700

Hello Martin, 

thank you very much for the references.  To answer question about point 9, let me recap what point 9 is:

Quote from the chair's mail, starting point 9 thread: [quote] My opinion: There needs to be a clear motivation for why 6to4 is actively preventing 6to4 roll out...The current focus, the way I read it, is on why 6to4 isn't a great protocol, rather a clear description of why 6to4 is actively preventing native IPv6 roll out..But I would suggest that the authors amend the text so that it:   i) better motivates that use of 6to4 is actively preventing roll out of native IPv6... Action: I'll try to word smith some descriptive text. Appreciate some help Erik/Tore? [/quote]

Tore suggested text, essentially: [quote] >>Content providers have no way of performing a gradual IPv6 deployment...When an AAAA record is published for a web site, a significant number of end users on the Internet will attempt to use the 6to4 connectivity in preference to IPv4. [/quote]

So, the point 9 is about affect on IPv6 roll out, and not about how 6to4 is not great. Do you agree with definition of point 9? If you do, then on point 9, let me quote the data sources you pointed to.

Emile: [quote]
>>Content providers will not be affected much by the 6to4 breakage we see, as long as operating systems and applications prefer native IPv4 over auto-tunneled IPv6 (6to4,Teredo) by default, and as long as they prefer native IPv6 over everything else. Luckily, with the latest fix to Mac OS X (10.6.5), all major operating systems behave the way it is described above.
>>Moral of the story: Go dual-stack. Now. [/quote]

Tore: [quote]
>>The secondary purpose of the measurement is to determine why I observe client loss - what are the underlying causes? The answer to that appears to be old versions of the Opera web browser and Mac OS X. This is because they prefer transitional IPv6 connectivity (6to4, Teredo) above more reliable IPv4 in certain cases...
>>Any remaining problems is really hard to distinguish from statistical noise at this point. [/quote]

Geoff: [quote]
>>However, for as long as we can continue to operate in dual stack mode and use IPv4 as a backup, then the vast majority of these failed connection attempts in IPv6 are resolved in IPv4, and the underlying dual stack failure rate is far lower...
>>The best advice to offer here is that the most useful way to use auto-tunnelling techniques, including 6to4 and Teredo is to put it as a last resort and only use it when all other connection attempts, including IPv4, have failed[/quote]

So, I fail to see how these data would support the point 9 "why 6to4 is preventing IPv6 roll out". Further more, Emile expresses clearly opposite opinion. In Tore's opinion, quoted above, the only major OS significant affected is older versions of MAC OS, and the only major browser significantly affected is older versions of Opera (and market share of those older versions of Opera is rapidly declining, AFAIK). According to Tore, Apple has released patches for some OS versions, and not others - I guess one has to assume that there was some rationale behind that decision, including considerations of the broken users of those versions of the OS.

Google data indicate that usage of 6to4 has dropped 3 times since late 2009 till now. Interestingly, this is about the same time MAC OS 10.6 was released (August 2009), for which 6to4 patches are available. 

So to summarize my opinion, based on these data sources and quotes: 

if point 9 is indeed about whether or not 6to4 prevents IPv6 roll out, and if it does, how to address it efficiently, then based on the data sources you pointed to, that problem problem is scoped to older versions of a particular OS and older version of a particular browser. In my opinion, it is incorrect to say that in general 6to4 is preventing IPv6 roll out because of impact on content providers.

While I think Brian Carpenter's draft shows clearly why 6to4 should not be on by default in routers and I agree with that recommendation. I also agree with the RFC 3484bis to depref 6to4 below IPv4 in general.

However it is unclear to me why proponents of the "historic" draft think that declaring "historic" status would actually help to solve the point 9 problem impacting some versions of that particular OS in any short timeframe: I think consumers are quite unlikely to go and buy new IGDs over night, or upgrade software on the IGDs, nor typically IGDs can upgrade themselves. 

On the other hand, PC OS vendors may have OS update channels which can update functionality basically without / with little user intervention - and if that has not been done, then probably business justification and user pain wasn't perceived to be strong enough.

Thank you,
Dmitry
________________________________________
From: Martin Millnert [[email-masked]]
Sent: Saturday, April 30, 2011 1:35 PM
To: Dmitry Anipko
Cc: Mohacsi Janos; Lorenzo Colitti; [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

/M

---

From: Dmitry Anipko <[email-masked]>
Date: Sat, 30 Apr 2011 16:41:24 -0700

It doesn't seem to me that the data sources, quoted in the forked thread by Martin, indicate that there is a significant number of XP hosts which are affected by the problem. If Google has data indicating the opposite, I'd highly appreciate if you could share those data, either on the mailing list or offline.

Thank you.
________________________________
From: [email-masked] [[email-masked]] On Behalf Of Lorenzo Colitti [[email-masked]]
Sent: Saturday, April 30, 2011 11:51 AM
To: Mohacsi Janos
Cc: [email-masked] WG
Subject: Re: [v6ops] 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"

On Sat, Apr 30, 2011 at 6:59 AM, Mohacsi Janos <[email-masked]<mailto:[email-masked]>> wrote:
All the current RFC 3484 implementations I am aware of treats RFC 1918 IPv4 addresses as a global scope address -> NATed IPv4 prefered to 6to4 and Teredo. -> It was one reason to revise RFC 3484.

What about Windows XP? It's true that it has IPv6 off by default, but various popular P2P clients appear to enable IPv6 when they are installed.