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:
- 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.
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!
I recently started playing with Google Print, which is quite wonderful. I noticed that they have indexed IPv6 Network Administration. This means that if you want to know do we “discuss quagga” Google can tell you that we do, on page 165.
One of the other features lets you search for reviews of a book. So, I used that and some additional digging to find some reviews of our book.
- Mel Beckman wrote a review in March. He seemed to like it, and took IPv6 out for a spin in April.
- We have a couple of reviews on Amazon.com. W Boudville thinks we struck a slightly defensive note, I don’t see this myself, but I’m biased. For Richard Bejtlich (of TaoSecurity) we really seem to have hit the spot.
- For the German speaking among us (that’s not me!) there is also a review at Amazon.de - the reviewer seems to like what we’ve done.
- There is also a longer review in German.
- The review at Security Forums found that we were technically good, but a little dry. I thought we’d actually gone overboard on the wry comments - I guess we’ll have to try harder next time!
- Peter Salus reckons we made a nice job of it.
- There is also a review in Processor and Mac Companion
- This isn’t really a review, but at least we reminded someone of why books are important.
Overall, I think we’ve made a good impression.
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.
ISOC recently announced that Brian Carpenter has been appointed the next chair of the IETF. He’s currently a distinguished engineer with IBM, and was and is heavily involved in the IPv6 working groups. His appointment should come as a boost for the protocol, as he tends to say things like: “IPv6 is a real necessity. The challenge there is no longer one of getting the standards done, it’s the progressive deployment of IPv6″. Good news all around.
(Check out ZDnet UK for more.)
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