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:
- Turn on IPv6 on Windows XP.
- Use multicast pings and the neighbour cache to find the router.
- Log into the router and configure it.
- Check that router advertisements work.
- 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.
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.
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?