Deploying IPv6

IPv6 Day seems to have been a success - nothing broke and a number of people seem to have managed to achieve interesting IPv6 things as a consequence. The BBC are offering services over IPv6 now, the Arbor Networks guys measured quite a leap in IPv6 activity and John Ronan ran an epic IPv6 experiment, suggested by Frank Dunnigan and myself. An important outcome is that Google and Facebook are to continuing offering services over IPv6 even after IPv6 day.

We’ll hopefully be posting a bit more too, having resolved an IPv6 problem that was hampering out DNS server!

I spent the morning looking at two IPv6 problems in work. In one case, Linux seemed to be looping IPv6 packets back out its 6to4 interface that it should be forwarding to its ethernet interface. After a lot of confusion, I realised it was just a typo on my part - an “fc” should have been an “fd”, so the route was pointing in the wrong direction.

The other problem was that performance over the 6to4 interface seemed to be a bad, even though we had a close 6to4 relay router. It seems that the MTU was set too high - I had tried to set the MTU using Debian’s /etc/network/interfaces “mtu” directive, but that doesn’t seem to work on tunnel interfaces in the version of Debian I’m using. Setting it manually has helped considerably with bulk TCP transfers: I’m now getting about 13Mbps, which is quite reasonable. I guess the bad performance was caused by larger IPv6 packets producing an IPv4 packet that had to be fragmented, and something along the path doesn’t handle IP fragments so well.

Eric Vyncke has implemented IP over Facebook with IPv6 addressing. The routers are click powered and use IPv6.

I stumbled over this paper were people had measured some aspects of IPv6 performance. It’s along the lines of earlier work, such as this, where you compare the performance of dual-stack hosts that you can reach by both IPv4 and IPv6. I don’t buy into all the conclusions, but some of the numbers are interesting. They actually found downloads faster over IPv6!

We held the Irish IPv6 Summit a few weeks ago. Niall and I spoke, and there was a good mix of local and international speakers, including Fred Baker from Cisco and Detlef Eckert from the EU. The slides and video from the talks are now available online from the agenda. Overall, we were pleased with the turn out and we’ve had some interesting followups as a consequence.

I was at Skycon, a conference organised by the University of Limerick student computer society. Randall Munroe of xkcd fame was one of the keynote speakers. Following his maps of IPv4 address space usage, he also provided a picture of IPv6 address space.

Usenix’s April 2008 edition of ;login: magazine has focus on IPv6. Some of the articles (including the one on why it is time to make a move) are freely available already.

At the most recent IETF meeting, there was an IPv6 only hour. The idea was to turn off IPv4 and see what was missing. I think no one was particularly surprised to discover that more work is needed.

One thing that did work was ipv6.google.com - an IPv6-only version of Google’s search page that Google established for the test (though it is intended as a long-term offering). Niall was part of the team within Google that established the service, and there are a number of well-known names from the IPv6 world working within Google on this project.

As a little treat, the Google logo dances when you visit this page. You can also set Firefox to use it as part of it’s search box by finding your google.xml searchplugin file and replacing the occurances of www.google.com with ipv6.google.com.

The upcoming advent of IPv4 address exhaustion will mean a number of very interesting and mostly likely painful things about how networks are run in the future. I spoke at RIPE 55 about this; at this point in time it looks like whatever else goes on, IPv4 exhaustion will do more to sell IPv6 than a feature list ever did. Or, more pessimistically, we’ll end up in a very difficult position in almost every way you can think of.

Check out either my slides or the webcast of the talk for the details.

Oh, and I’m working on cleaning up the code, but life is getting extremely busy…

ICANN have released a short IPv6 Factsheet to explain what IPv6 is and why people should be thinking about it.

There’s been rather a lot of talk about RH0, that’s IPv6’s type 0 routing header. Broadly speaking, the header allowed you to list a set of places that the packet should go to before its final destination. In the book we commented that source routing

used to be a security hot button in IPv4, when authentication based on source IPv4 address was common and packet filtering was not.

The problems that we were thinking of were discussed at least going back to the in the mid 90s, and related to source routing allowing any host on the Internet to impersonate any other host and get the returned packets. Usually someone who is doing IP spoofing is making a blind attack, because the replies to the packets that they sent would not be routed back to them. With source routing, some IP stacks would reverse the route for the returned packets, allowing the attacker to get their hands on the replies. With network services like rlogin being common, this was a big threat.

Some other firewall evasion attacks were also possible with source routed packets, but I think the IP spoofing attacks were most prominent in people’s minds.

It seems that IPv6 source routing has become a security hot button, but for a slightly different reason. As far as I know, no IPv6 stacks ever reversed the route, so the IP spoofing attacks have never been possible. The firewall evasion attacks are still there, which I don’t think surprised anyone. However, the attacks that caused RH0 to make the press are amplification attacks. The attacks were demonstrated by Philippe Biondi and Arnaud Ebalard and a nice summary was written by Geoff Huston.

Interest in amplification attacks has grown since attacks like the smurf attack appeared sometime around 1997 and particularly since denial of service attacks became big news. I’m not sure that when the original problems with IPv4 source routing were being discussed that amplification attacks were really considered seriously. I think the full impact of amplification attacks in the modern Internet, particularly with the proliferation of botnets, is yet to fully understood.

The outcome for IPv6 is that RH0 is now treated as a unknown header by many IPv6 implementations, and will probably be formally retired by the IETF shortly. Other types of routing header (particularly RH2, which is used by Mobile IPv6) should continue to be operate normally, as they do not pose the same risks. I think the remaining interesting question is how do we design a version of RH0 which is both safe and useful.

It seems there is an IPv6 deployment metric on which Ireland leads the world! At the most recent RIPE meeting, there was a study of the number of the top 100 most visited web sites (according to Alexa) in each country had support for IPv6 HTTP, SMTP or DNS. The results for Ireland are on page 88 of the PDF, where 9 of our top 100 web sites have IPv6 DNS support - which is the the largest number with DNS support of any country. We do not shine so brightly when it comes to web support or mail support (0 and 1 respectively).

It seems that Tom Limoncelli and Peter Salus have published a collection of April first RFCs. There’s a whole chapter on IPv6, and I’m glad to see that the first chapter is on the evil bit, which was briefly implemented in FreeBSD.

People sometimes ask me if I think IPv6 will take off in a big way. My answer is that there is no other contender to replace IPv4, and sooner or later we will have to move away from IPv4 as pressure on IPv4 addressing makes things more uncomfortable. One of the big areas of uncertainty has been when will IPv4 addresses actually be no longer available, for practical purposes.

Some smart people in the APNIC region have figured out that this uncertainty is bad for everyone, because it makes it hard to plan. They have written a proposal suggesting that once the pool of remaining IPv4 addresses hits some level (they suggest 30*/8), then we say “two years from now we will stop allocating IPv4 addresses, except in emergencies”.

(It is unlikely that 30*/8 can be consumed in two years, but clearly some thought is necessary to correctly set the level and the time scale.)

This seems like a very clever plan. It means we all get two years notice that there won’t addresses be available, and so we should start planning now, thus removing uncertainty. Everyone gets the same notice, so it is fair. Finally, we keep a little in reserve, so that we can patch things up if some globally important obstacle presents itself.

It’s not clear to me if this proposal makes the rush for the last few available IPv4 addresses better or worse, but it certainly seems to make people’s job easier when it comes to planning what is needed.

The Manweek conferences were held in Dublin last October. As part of the IPOM conference there was a pannel session, on IPv6, asking if managing an IPv6 network can be more cost effective than managing an IPv4 network. The pannelists were Jeroen Massar (of SixXS), David Wilson (of HEAnet), and Niall Murphy. An MP3 of this session, and other pannel sessions from the conference is available from this page.

At one location I have a subnet that has both a SixXS tunnel (with 2001:/16 addresses) and 6to4 connectivity (with 2002::/16 addresses).

Today I was browsing www1.ietf.org, which has a 2610:… IPv6 address. This is closer to my 6to4 address than my SixXS tunnel address, so my machine selected the 6to4 address as the source address. However, the 6to4 interface is only used to route packets with a 6to4 destination, so the packet was actually sent over the SixXS tunnel. SixXS do ingress filtering, so they dropped the packet.

It turns out that /etc/rc.d/ip6addrctl on FreeBSD has a policy that is exactly suitable for this situation:

ip6addrctl_prefer_ipv6()
{
        ip6addrctl flush >/dev/null 2>&1
        ip6addrctl add ::1/128          50      0
        ip6addrctl add ::/0             40      1
        ip6addrctl add 2002::/16        30      2
        ip6addrctl add ::/96            20      3
        ip6addrctl add ::ffff:0:0/96    10      4
        checkyesno ip6addrctl_verbose && ip6addrctl
}

With this policy, my machine now prefers my 2001:/16 address, unless I’m speaking to a 6to4 host.

Some of the guys from the KAME project have written a book on the KAME IPv6 implementation. This should be quite an interesting read for anyone who wants to understand how you’d write an IPv6 stack, as the KAME stack has been one of the important reference IPv6 stacks that have been available during the development of IPv6. Each chapter contains a code walk-through, written in a similar style to Steven’s TCP/IP Illustrated Volume II.

While reconfiguring a Linux gateway recently I managed to get it into a rather confused state, where it thought that its own addresses were unreachable. Attepmting to ping it produced this ICMP message.

20:18:04.441662 2001:770:11d::3 > 2001:770:11d:0:20d:56ff:fe22:320c:
icmp6: 2001:770:11d::3 unreachable address

ICMP is usually a pretty dry protocol - I think this is about as funny as ICMP messages come!

At one site, where anonymous ftp isn’t really a core service, I have wu-ftpd set up in DNS fascist mode, which means that it won’t let you log in unless your forward and reverse DNS match. Now, when we started offering anonymous ftp over IPv6, it was quite tricky to get a working delegation for your reverse DNS, so I added an option to allow people with b0rked IPv6 DNS through (with only a minor nag).

Recently, our anonymous ftp server started nagging local users connecting via IPv6, even though their DNS was fine (even as reported by my DNS fascist script. It turns out that our wu-ftpd does its own reverse lookups and was patched at a time when only ip6.int was in practical use. Of course, in the last few months ip6.int has gone away entirely. My first inclination was to edit the binary, but, unfortunately, ip6.arpa is one character longer. However, the source code was just as easy to fix.

I did wonder if I should now remove the exemption for anonymous ftp over IPv6, as the DNS tree for production IPv6 address is now moderately well maintained. However, there are still lots of people using transition mechanisms that don’t easily provide access to the DNS reverse tree corresponding to the IPv6 address space you use.

The node information queries draft has finally become RFC 4620. I’m quite pleased because I think that node information queries are quite an interesting feature of IPv6. They let you ask nodes what they think their name is. For example, you can ask for the names of all the nodes on a link by doing something like:

> ping6 -w ff02::1%rl0
PING6(72=40+8+24 bytes) fe80::210:a7ff:fe0b:d2b%rl0 --> ff02::1%rl0
46 bytes from fe80::210:a7ff:fe0b:d2b%rl0: yipyip.home.dwmalone.net.
45 bytes from fe80::204:e2ff:fe33:e3ac%rl0: gonzo.home.dwmalone.net.
46 bytes from fe80::210:a7ff:fe0b:d2b%rl0: yipyip.home.dwmalone.net.
45 bytes from fe80::204:e2ff:fe33:e3ac%rl0: gonzo.home.dwmalone.net.
^C
--- ff02::1%rl0 ping6 statistics ---
2 packets transmitted, 2 packets received, +2 duplicates, 0.0% packet loss

Here I’ve sent a Node Information Query with the KAME ping6 command to the all-nodes address on an interface called rl0. Each node responds with its name - you can then connect to the node using ssh or another tool of your choice.

Out of interest, I decided to diff the last version of the draft and the RFC to see what changes in the final revision. Among a number of minor editoral changes I found that “which” had been changed to “that” in a number of places. This is a topic on which people have plenty to say.