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.)
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:
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.
Powered by WordPress