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

From: Philip Homburg <[email-masked]>
Date: Sun, 01 May 2011 10:18:41 +0200

In your letter dated Sat, 30 Apr 2011 16:36:42 -0700 you wrote:
>So, the point 9 is about affect on IPv6 roll out, and not about how 6to4 is no
>t 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.

Dmitry,

May I ask you what you are trying to achieve here? Not specificly with point 9
but with 6to4 in general? After all your messages I sort of lost track of that.

My personal opinion is that I like the simplicity of 6to4 very much. As well as
how it allows users to enable 6to4 independent of their ISPs. But numerous
studies have shown that it simply doesn't work in practice. And more NAT is
simply going to make it worse.

So, I would say that if you have a protocol targeted at end-users and it
is very hard for them to get it to work, then we (as IETF) have to get rid
of it. And make a clear statement that unfortunately the protocol doesn't work.

Whether that is really described accurately to the last detail in an RFC I 
don't really care. As long as the message is clear: don't do it.

Now you seem to argue against declaring 6to4 as historic even though you also
seem to admit that it is broken. So I'm wondering what you really want.

---

From: Tore Anderson <[email-masked]>
Date: Sun, 01 May 2011 17:08:42 +0200

Dmitry,

> Tore: [quote]
>>> Any remaining problems is really hard to distinguish from
>>> statistical noise at this point. [/quote]

I was unable to spot anything in the aggregate data, no. 6to4 was the
big one. However after we deployed, I got in touch with several «broken»
end users and when helping them solve their problem I discovered some
other problems. I've documented them all here:

http://getipv6.info/index.php/Customer_problems_that_could_occur

(This is not relevant to the 6to4-to-historic discussion, but I thought
you might find it interesting anyway.)

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

There's two things we can do to solve the point 9 problem:

1) Make 6to4 not be used at all. See: RFC 3484,
I-D.ietf-6man-rfc3484-revise (section 2.4), and
I-D.ietf-v6ops-6to4-to-historic (section 4).

However, let's be realistic here: There's currently no patch for Mac OS
X Tiger and Leopard, nor for Windows ICS. That's certainly tens of
millions of affected end users. Even if those patches were to
materialise tomorrow, how long before every end user have upgraded?
Years, surely. And how many applications and devices are out there that
do not do resolving in a RFC3484-compliant manner? Nobody knows...

2) Make 6to4 work as reliably as native (IPv4/IPv6) connectivity. See:
I-D.ietf-v6ops-6to4-advisory.

Let's be realistic here too: There's tens of millions of users using
bogon/unrouted public address space behind CGNAT systems, and these are
likely to increase in number now that IPv4 is depleted. There must be
thousands of enterprises and similar that filter away all protocol 41.
How are we going to reach out to them all and convince them to change
their configs? How many firewall products must be updated to allow
protocol 41 by default? How many poorly maintained anycast relays must
be fixed or withdrawn from the DFZ, how are we going to identify them?
How many new relays must be deployed in how many locations in order to
prevent 6to4 users world-wide from experiencing routing trampolines?

I am not saying that both of the approaches above aren't worth while
pursuing. Quite the contrary: They will certainly provide some pain
relief, and that's a good thing for everyone involved.

However, don't let us fool ourselves: Pain relief is not a cure! There
is simply *no cure* for 6to4's operational problems that can be
universally deployed across the entire internet in a reasonably short
time frame; 6to4 is broken beyond repair. Moving it to «Historic» is
simply an admission of that fact, as well as sending a clear message to
everyone that the protocol has no future and that it is time to move on.
Hopefully, that message will also help persuading vendors to implement
pain relief approach #1.

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Sun, 1 May 2011 09:43:18 -0700

On Sun, May 1, 2011 at 8:08 AM, Tore Anderson <
[email-masked]> wrote:

> 6to4 is broken beyond repair. Moving it to «Historic» is

You hit the nail on the head. 6to4 can't be fixed, and it will only get
worse over time as CGN is deployed (ISPs assigning bogon addresses; broken
home gateways that turn on 6to4 even with private addresses). We need to
acknowledge that fact, and send a clear message to the industry that 6to4 is
not worth pursuing.

---

From: Tim Chown <[email-masked]>
Date: Sun, 1 May 2011 22:43:47 +0100

On 1 May 2011, at 17:43, Lorenzo Colitti wrote:

> On Sun, May 1, 2011 at 8:08 AM, Tore Anderson <[email-masked]> wrote:
> You hit the nail on the head. 6to4 can't be fixed, and it will only get worse over time as CGN is deployed (ISPs assigning bogon addresses; broken home gateways that turn on 6to4 even with private addresses). We need to acknowledge that fact, and send a clear message to the industry that 6to4 is not worth pursuing.

We have various public services made available dual stack.   In terms of external IPv6 traffic hitting our main web site, our peak IPv6 transport volume was just under 2% of all traffic a couple of months ago.  Of that 2%, less than 1% was via 6to4, and that's with our ISP (JANET) running a 6to4 relay.  I suspect we see rather less 6to4 than other sites because a lot of our IPv6 traffic comes from other academic sites that have native IPv6 connectivity.  So the removal of 6to4 wouldn't be an issue for us.

We would very much like to see various Internet connection services (not just Windows) cease to use 6to4 when connection sharing is enabled.  Every one of the rogue RAs we've seen at our site in the past 12 months has been due to connection sharing software, and (unchecked) we would have a rogue 6to4 RA about 60% of the time somewhere on our wireless network.

Accelerating publication of RFC3484-bis (and the DHCPv6 policy distribution method) would be very welcome.  I am more than happy to offer editing cycles on that if required.

As long as the message to avoid 6to4 is clear enough, I don't have strong views on the specifics.  I understand why some may want to see a 6to4 version of RFC 3701, but avoiding 6to4 on by default, or being turned on unintentionally, is certainly a minimum step.
 
Tim

---

From: Pekka Savola <[email-masked]>
Date: Mon, 2 May 2011 10:24:50 +0300 (EEST)

On Fri, 29 Apr 2011, Geoff Huston wrote:
> 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.

Geoff, do the return relays in your measurements emit packets from 
src=192.88.99.1 or some other IP?  I assume that has significant 
implications on failure rate, with src=192.88.99.1 having fewer 
failures.  I don't think I've seen this part of the methology stated 
anywhere.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Geoff Huston <[email-masked]>
Date: Mon, 2 May 2011 17:57:15 +1000

On 02/05/2011, at 5:24 PM, Pekka Savola wrote:

>> 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
> Geoff, do the return relays in your measurements emit packets from src=192.88.99.1 or some other IP?

both

I have two systems - one emits return packets from 192.88.99.1 and the other uses its local Ipv4 unicast address.

>  I assume that has significant implications on failure rate, with src=192.88.99.1 having fewer failures.  I don't think I've seen this part of the methology stated anywhere.

In a set of experiments I tested a set of clients using BOTH systems. On weekends the local unicast address using 6to4 generated a failure rate of 13 - 15% while the anycast-using 6to4 relay generated a failure rate of 10% to 11%. On weekdays the difference is higher - 15% failure using the anycast address and 20% failure using a local unicast address

regards,

   Geoff