is something that I've been interested in for a while; I was even employed
to do some v6 porting work a few years ago. Unfortunately, even though it's been several years and address exhaustion is rapidly approaching
, uptake remains slow.
As I see it there are several problems with IPv6 adoption:
- Software doesn't support it
- Hardware doesn't support it
- ISPs don't provide it
As these go, (1) isn't actually that big a problem now. A lot of the most important software already supports v6. Ubuntu/Debian seems to just work with IPv6 (and presumably other Linux distributions as well), and even Windows supports it as of Vista
. Software packages like Firefox work out of the box.
(2) is still a big issue for a lot of hardware but I suspect that there's a lot of hardware now that supports it, but has it turned off (routers, etc). (3) is simply a fact; I haven't heard of any ISPs supporting v6, and I suspect a lot of that is dependent on (2).
(not to be confused with6in4
, thanks for the clear naming, guys), is in my opinion an excellent piece of engineering and exactly what is needed to fuel IPv6 adoption. It solves the hardware/ISP problems by tunneling v6 traffic over v4; however, the clever part about it is that it does this without the need to register an account with a tunnel provider or explicitly configure it. I first became aware of 6to4 when I heard that the Apple Extreme base station has it enabled by default, which I think demonstrates its potential; it's possible to circumvent the remaining hardware/ISP problems with IPv6 just by getting manufacturers of broadband routers to adopt 6to4.
With 6to4, tunnels are made opportunistically
between v4 addresses, which means that if you have two machines using 6to4, they can communicate directly, without the overhead that routing through a third party would cause (If this sounds a bit pointless, consider that it means two machines both behind NAT gateways in the v4 world can have end-to-end connectivity
in the v6 world). Any other v6 data is sent to a magic anycast
address that automatically routes v6 data to the closest v6 gateway.
With 6to4, a machine has an IPv6 address range that is derived from its public IPv4 address. For example, if your IPv4 address is 188.8.131.52, your IPv6 subnet range is 2002:0102:0304::/48. IPv6 traffic for that range automatically gets sent to that IPv4 address. What really happens
is that your 6to4-enabled broadband router assigns addresses from this range to machines on your home LAN.
Setting up 6to4
My DSL router doesn't support 6to4; however, I managed to work around this. My router does
support port forwarding (actually, protocol forwarding in this case), and I have a Linux machine in my lounge that I use as a media centre/server.
The first step was to set up a rule on the router to forward 6to4 data to the server machine. I have a BT
router which is helpfully quite flexible in this respect. 6to4 data is IP traffic with a protocol number of 41. From the router's command line interface, this did the job:
create nat rule entry ruleid 41416 rdr prot num 41 lcladdrfrom 192.168.1.6 lcladdrto 192.168.1.6
It was then a case of configuring the server to do 6to4. As it is running Ubuntu, I added this to /etc/network/interfaces
iface tun6to4 inet6 v4tunnel
post-up ip -6 route add 2000::/3 via ::184.108.40.206 dev tun6to4
post-down ip -6 route flush dev tun6to4
A simple "sudo ifup tun6to4
" and the tunnel device should come up. It should then be possible to ping IPv6 addresses:
$ ping6 ipv6.google.com
PING ipv6.google.com(2001:4860:a003::68) 56 data bytes
64 bytes from 2001:4860:a003::68: icmp_seq=1 ttl=61 time=53.8 ms
64 bytes from 2001:4860:a003::68: icmp_seq=2 ttl=61 time=52.5 ms
64 bytes from 2001:4860:a003::68: icmp_seq=3 ttl=61 time=45.5 ms
64 bytes from 2001:4860:a003::68: icmp_seq=4 ttl=61 time=51.5 ms
At this point, the server has IPv6 connectivity, but what I really want is every machine on the network to have it. So the next step is to set up the server as an IPv6 router.
To do this, other machines need to know that the server is a router and acquire IPv6 addresses. In IPv4, this is usually done with a DHCP server
handing out addresses from a pool. Instead, with IPv6, routers advertise
their address ranges, and the clients automatically construct an address. This is possible because of the vast address range in IPv6.
A package called radvd
(router advertisement daemon) sends router advertisements. It's in the Debian package repository and very easy to configure. This is my /etc/radvd.conf
Notice that I've defined a subnet range for clients. The address range given by 6to4 is 2002:0102:0304::/48, while radvd assigns addresses in the 2002:0102:0304:face::/64 range. Next, I statically assign an address in this range in /etc/network/interfaces
by adding this:
iface eth0 inet6 static
Now the router advertisements are handing out v6 addresses to other machines on the network, and the server has an address within the subnet range to communicate with them. It's then just a matter of turning on routing. Add this to /etc/sysctl.conf
Or to make it take effect immediately:
sudo sysctl net.ipv6.conf.all.forwarding=1
sudo sysctl net.ipv6.conf.default.forwarding=1
That's it! Here's the output from ifconfig
on another machine on my network:
wlan0 Link encap:Ethernet HWaddr 00:1c:10:63:63:d0
inet addr:192.168.1.25 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: 2002:0102:0304:face:21c:10ff:fe63:63d0/64 Scope:Global
inet6 addr: fe80::21c:10ff:fe63:63d0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:7658 errors:0 dropped:0 overruns:0 frame:0
TX packets:7228 errors:0 dropped:0 overruns:0 carrier:0
RX bytes:4073660 (4.0 MB) TX bytes:903010 (903.0 KB)
And here's Google IPv6:
Note that in the examples above, I've obscured my 6to4 address range to 2002:0102:0304::, to hide my IPv4 address, for privacy. If you want to follow my instructions, this needs to be replaced with your own public IPv4 address.
Syndicated 2009-03-20 22:03:27 from fragglet