Some thoughts about 6to4

February 10, 2010

I've previously written about the problems with the IPv4 to IPv6 transition, and how the IPv6 people could have made it easier. Well, it turns out that I have to take back some of the grumpy things that I said back then because I just found out about 6to4, which makes IPv6 connectivity fairly trivial for machines with public IPv4 addresses (and generally it works), partly by embedding the IPv4 address space into IPv6.

(I'll let you read about the details in the Wikipedia entry, which describes it better than I could. See here for one description of how to set it up on Linux.)

6to4 is one of those things that strike me as a neat hack, in the classic sense; it is an elegant, clever trick to get something done. The simplicity of how things work is very nice and it avoids all sorts of annoyances with more complex VPN/tunnel systems. Unfortunately, I think that in the long term 6to4 is probably doomed; it's useful for easy experimentation, but not really as a way to get large numbers of people onto the IPv6 Internet. The problem is the issue of gateways.

(The remainder of this assumes that you understand how 6to4 works.)

Two 6to4 machines will talk directly to each other over the IPv4 Internet, but to talk to general IPv6 addresses they have to route through a 6to4-to-IPv6 gateway. Because the IPv6 people had no desire to import the IPv4 routing table into IPv6 routing tables, 6to4 gateways can only advertise the entire (IPv6 embedded) IPv4 address space, not subset routes for parts of it.

An ISP with top-level IPv6 connectivity can easily arrange for outgoing 6to4 traffic from its customers to go through its own 6to4 to IPv6 gateway; it just routes traffic for the magic 192.88.99.1 gateway IP address to its gateway. However, it has no way of causing the return traffic from pure IPv6 nodes to flow through its gateway; instead, the return packets will be routed through whichever 6to4 gateway is closest (in a network sense) to the IPv6 machine at the other end.

Any significant use of 6to4 thus necessarily starts shunting more and more traffic through public gateways, even under the best of circumstances. Many of these gateways will not be located on what are the natural network paths between the end nodes, where the traffic would have flowed regardless of where the gatewaying happened; instead, the traffic will be diverted out of line, resulting in extra volume transiting into and out of unrelated networks. This effect is magnified by ISPs who do not operate 6to4 gateways (whether public or private), because then even the outgoing 6to4 traffic is running off through another network.

For end users, this results in packet delays. For the ISPs involved, this causes issues with both link volumes and peering politics; you're spending money to carry other people's traffic out of the goodness of your heart, and your peers may not like that anyways. Something is likely to give sooner or later, and so the more popular 6to4 gets, the fewer truly public gateways I suspect we'll see and the higher the chance that you won't get full and reliable IPv6 connectivity with 6to4.

This doesn't make 6to4 useless; it's still a great way to start playing around with IPv6 without having to find a 6bone tunnel broker, registering, setting things up, and all of that. I just can't see it as a long-term compatibility solution for general interaction between IPv4 and IPv6 machines, unless there's something I'm missing.

(I looked into IPv6 tunnel brokers once upon a time and concluded that it was too much work. The great appeal of 6to4 is that all I have to do is run a few commands locally and bang, I have IPv6 connectivity and can start finding out all of the programs that now break.)

Note that even today this means that your 6to4-enabled machine may not have full IPv6 connectivity; what connectivity you get depends on the administrative policies and routing of the gateways involved. Possibly this means I should grit my teeth and get a connection through an IPv6 tunnel broker.

(I expect that these issues are already well known in the 6to4 and IPv6 community; I'm just new to all of this IPv6 stuff.)

Sidebar: why the 'no subset routes' thing hurts

If 6to4 gateways could advertise IPv6 routes for a subset of the IPv4 address space, your local ISP's 6to4 gateway could announce itself as the IPv6 gateway for only its IPv4 address space. This would cause traffic to flow the way it should; the returning IPv6 packets would transit over the 6bone until they reached your ISP, instead of flying off to some other 6to4 gateway to be turned into IPv4 packets.

This would have the additional effect of making the packet routes symmetrical. Right now, 6to4 connections are assymmetrically routed, where the outgoing packets take one path and incoming packets take another. In fact, incoming ones may take any number of paths depending on where they're coming from.

Written on 10 February 2010.
« Why your program should have an actual configuration file
Beware of using Linux's hostname -s switch »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Wed Feb 10 03:24:42 2010
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.