Deploying IPv6

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.

The 6bone phaseout day (06/06/06) came and went last week. It does seem to have had some impact. From one site, my route to KAME went through Sprint’s 6bone space at two points. Later in the week, one of the routers had been renumbered, and by today I don’t see any 6bone addresses in the list.

This did bring a vaguely interesting point to mind. If someone that you get transit from uses 6bone addresses and you drop packets to/from 6bone addresses, then you can break things like traceroute and PMTU discovery, because they depend on getting packets from intermediate hosts. Though, people offering you transit probably shouldn’t really be using 6bone space any more. (The Ghost Route Hunter guys are monitoring who is still using 6bone space.)

The use of ip6.int also faded further - the RIRs have deleted their deligations in the ip6.int tree. Unfortunately, for people with hosts that use ip6.int, one of the servers for ip6.int has a 6bone address, which is now unreachable from chunks of the IPv6 Internet.

I missed what looks like quite an interesting talk by Mike Warfield at the TERENA on the security implications of IPv6. For me, one of the most interesting points is that if you don’t block IPv6 in your network then it will creep in because of users or attackers making use of it.

This is very similar to a point we included in a report on WiFi in Dublin 2002: IT departments will have to provide WiFi ‘cos if they don’t users will just plug in access points. I’ve seen this proven true in several situations since and so I still think it is good advice.

Mike Warfield goes one step further though. He points out that providing IPv6 is a lot easier than blocking it because there are so many ways to get IPv6 connectivity, thus the best path for IT providers is to start providing IPv6 connectivity that they can at least monitor and control.

(You can get the slides on the TERENA site. They may make the webcast available later.)

Yesterday was Irish Budget day. Recently HEAnet started streaming sessions of the Oireachtas (the Irish parliament and sennate) over IPv4 and IPv6, so I got to listen to my first budget over IPv6!

Hi there, and welcome to the “IPv6 Network Administration” blog.

Niall