Deploying IPv6

It seems the Vatican has recently been 2a01:b8::/32. The scope for smart comments is just so great, I don’t know where to begin!

At the HEAnet conference in November we ran a tutorial on IPv6. The aim was to give people some experience configuring IPv6 on a typical desktop (in this case Windows XP) and to show off some of IPv6’s features.

The outline of the tutorial was:

1. Turn on IPv6 on Windows XP.
2. Use multicast pings and the neighbour cache to find the router.
3. Log into the router and configure it.
4. Check that router advertisements work.
5. Do some IPv6 web browsing.

In practice, the routers were in a test tab in Dublin and the laptops were in a conference center in Athlone, so we had to figure out how to get LAN connectivity between the two. What we ended up doing was putting each laptop/router pair in a different VLAN and then shipping the trunked ethernet over MPLS to join two switches together. This worked pretty well, apart from the MTU issues - the combination of MPLS and VLAN tagging chewed a significant chunk of our MTU.

Now, Windows XP expects expects ethertnet to have an MTU of 1500 bytes, so this risked messing up our tutorial. PMTU discovery doesn’t help either, because the MTU drop is at layer 2, not between two layer 3 devices.

However, IPv6 came to the rescue! When configuring router advertisements we asked people to tell the router to advertise an MTU of 1280 bytes (which could be successfully be transmitted by the MPLS VLAN trunking). Windows XP picked this up correctly and it allowed the web browsing part of the tutorial to work successfully.

The pre-tutorial talk and the tutorial handouts are available if you’d like to see the details of the tutorial.

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!

The book covers the patches to postfix for IPv6 support. However, postfix 2.2 is now here and supports IPv6 (and TLS) without the need for any patches. I upgraded a mail system using postfix over the weekend and found the process remarkably painless. Having read the IPV6_README file that came with postfix I discovered that I really only needed to make one change to main.cf, which was to tell postfix to listen on any inet protocol by using the directive inet_protocols = all.

The new IPv6 code even spotted a mistake in my original configuration file and logged a helpful error message: fatal: non-null host address bits in "2001:db8:ee0:cc01::/48", perhaps you should use "2001:db8:ee0::/48" instead! Seems to have been a nice integration of the work of Dean Strik and others into the Postfix mainline.

So, the RFC for “Unique Local IPv6 Unicast Addressing” has finally shown up as RFC 4193. These addresses are intended to cover some of the ground originally provided for by IPv6 site-local addressing. They also help out people who aren’t in a position to get IPv6 addresses from an ISP, maybe because they don’t have one.

The idea is to provide a large block of addresses that look global, are allocated randomly but that we all agree to not route globally. This means that they are cheap (generating random numbers is cheap), they are stable (because they don’t depend on your ISP), they work just like globals (so you don’t need to change your applications) and they can even be used site-to-site or when sites merge (because randomly allocating them is highly unlikely to produce collisions). However, because we do not know how to manage a routing table without aggregation, we can not route them globally.

Operationally, people won’t need to make many changes to support them. We’ll probably want to filter for these addresses at our site boundaries, and may want to make our recursive DNS servers authoritative for the reverse domain, in the same way people should answer for 10.in-addr.arpa if they use a subset of 10.0.0.0/8 for private addressing.

Ireland now has a National IPv6 Centre, which was launched on Friday. The centre has been set up to help support the IPv6 Task Force here and to provide a place that people can turn to if they need to know about IPv6. The Hamilton Institute, where I work, is involved as part of the consortium. The project is being lead by the good folk at TSSG. The industrial side of the action is covered by HEAnet and BT Ireland.

One of the advantages of dual stacking is that you no longer depend on one protocol. If part of your network dies and takes out IPv4, there’s a chance that IPv6 will still work, allowing you to log in and fix the problem.

This may seem like a rather slim chance, but I’ve seen a few instances of it. In one case the IPv4 egress router was so busy generating ICMP messages that it couldn’t forward packets any more. The IPv6 router was uneffected by the problem, as the ICMP messages were in response to a worm, and continued to allow access to those using IPv6.

More recently, I’ve seen a problem with a etherchannel between two Cisco boxes, which resulted in IPv4 packets between certain pairs of machines being dropped. Getting this sort of problem resolved takes time, and we were able to ask users to use IPv6 as a workaround until the problem was resolved.

Of course, the opposit has happened too - an ethernet card in an IPv6 router failed while IPv4 continued merrily on its way.

Just back from Global IPv6 Summit in Barcelona, Spain, where I was the last speaker in quite a good conference organised by the redoubtable Jordi Palet. I would class the crowd at the end as small but enthusiastic, and some people actually volunteered to do stuff, which is generally the sign of a good conference.

I was talking about “Impediments to the Growth of IPv6″ and was pleased to note that the mood of gatherings like this has changed over the past few years, from bombastic commercialism and hype, to very sober deployment discussions. Admittedly there are still too many research folk presenting and not enough real deployment folk - don’t get me wrong, I like research folk as much as the next guy - but more people need to be doing this in the real world and reporting back on what happened. Tim Chown and 6net in particular are doing useful foundation work to enable this to happen.

Anyway, Barcelona is a lovely city, and I had the opportunity to hook up with some old friends and make some new ones, so all in all a good experience.

The folks at the University of Southampton have worked with UK’s Virgin Radio to stream the station over IPv6. They have details of how to access the streams and a press release. I’ve tried it with iTunes and it works perfectly.

Well, now, this is interesting.

A long time ago, I opined that since 80% of everything was HTTP, and 80% of that was the top 20 web sites, an effective transition could be accomplished by encouraging those websites to offer IPv6 service. Perhaps this is the first step along that path.

Of course, these days, 50% of everything is P2P, so what we need are some really good IPv6 P2P clients. That should help improve it’s reputation!

The current Internet Draft for IPv6 Addressing Architecture has a couple of items worth noting. Section 2.5.1 requires that interface IDs be 64 bits long, effectively deprecating any prefix longer than a /64. (Don’t let the reference to “modified EUI-64″ scare you - hand crafted addresses are still fine.)

Later on, section 2.6.1 gives a special meaning to addresses where all the bits to the right hand side of the address are zero.

Some of this is already present in RFC3513. In any case, should this draft make it to RFC status with these sections intact, it will break the practice of using long prefixes such as /126 and /127 for point-to-point links between routers. So while we’ve been insisting that using /64s for all subnets is a good idea, it may well become required practice in the near future.

The nice people at CAIDA have produced one of their cool network maps of the IPv6 Internet. Like the CAIDA IPv4 maps, you can clearly see Asia, Europe and the US represented on the map. Interestingly, it looks like there’s lots of IPv6 ASes alive in Europe, even compared to Asia. Mind you, the “centre” of the IPv6 network is, as expected, NTT/Verio.

Computer Weekly has a nice short FAQ on IPv6 that may be of interest to manager-level folk. There are two interesting assertions in the article. The first is that “Those with existing IPv4 skills should learn to implement IPv6 in four to seven days”. This is about the right length of time for understanding the raw changes; understanding their impact can take longer. The other, made towards the end of the article, is that the requirement for IPv6 training is expected to increase dramatically soon. While there are plenty of books on the topic, we aren’t aware of many training courses specifically about v6; perhaps this is a gap in the market.

Cisco have released a security advisory about multiple crafted IPv6 packets causing a reload. It seems that on a number of IOS versions with IPv6 enabled, a remote attacker can cause the router to reboot by crafting a particular series of IPv6 packets. Those of us who have been updating our IOSes recently for other reasons are in luck, as relatively recent versions of IOS appear to be safe.

This appears at the same time as two other Cisco security announcements. Busy day.

This draft looks at the real (and not so real) benefits of NAT and explains how IPv6 provides for people who depend on these. The table in the introduction is a nice summary of the issues and solutions.

A couple of quick developments on the IETF front.

First is http://www.ietf.org/internet-drafts/draft-yan-ipv6-ra-dns-00.txt - a recent draft specifying how autoconfigured nodes should do dynamic DNS updates. The most interesting thing here is that hosts can explicitly ask the router to do it for them, which should be interesting to get right; the router’ll have to keep a lot of state on large networks. But it’s another piece of the puzzle getting slotted into place.

Second is ftp://ftp.rfc-editor.org/in-notes/rfc3974.txt, an informational RFC on operating dual-stack SMTP servers. The core of the document is a description of the algorithm that should be used when dual-stack SMTP servers send mail. Since adding quad A records to MX records essentially adds an extra “dimension” to the MTA resolution process, I would recommend reading it so you get a better idea of how things work in the new world. In particular, quad A destinations are preferred over A destinations, but only within a set of MX records that have the same preferences. This means that it’s not possible to set up an experimental high-preference quad A MTA which then acts as a hoover for all of your mail, which is good, but also means it’s difficult for non-dual-stack mail servers with a low MX preference to be worked around. (One option is to put an IPv6-only server at an even-lower preference.)

Anyway, is it just me, or should we rework and reword the algorithm and the terms high- and low- preference MX, so we don’t have this running ambiguity in our heads about what we mean every time we talk about MX values?

Niall

After getting some feedback, I’ve improved my script that checks for names whose nameservers have problems responding to IPv6 queries. The script can how spot nameservers that return data, but the data is garbled. You can try out the script if you want to check your own name server. (There’s also a script that can check if your forward and reverse records match.)

I tracked down a problem last night where X forwarding doesn’t always work if ssh has to forward from an IPv6 X client to an IPv4 X server. This is with a slightly old sshd, so maybe the problem is fixed with a more recent version. I’ll post more details when I’ve checked out a newer server.