IPv6 - It *Doesn't* Just Work.
imported Tech · ISP · IPv6
I was reading an entry posted by Brett Carr on Nominet’s techblog today entitled “ipv6 It just works”. Unfortunately, for IPv6, and for the sentiment behind this message (IPv6 can be run pretty easily!), in my experience, IPv6 - it doesn’t just work!
It’s easy to dismiss the previous sentence, given that many networks aren’t designed to run IPv6, and there’s kit out there that’s just not IPv6-capable yet. When building the AS29636 network, we specified that IPv6-capability was one of the things that would be a requirement of the kit that was going into the new network, not just something that we’d like to have. We work to a similar specification at my current employer, - which ensures that we can deploy IPv6 within a pre-agreed timeframe once we have some commercial drive for it (either from customers, or for business continuity reasons). I think that this is the best way for a SP network to be a the moment - there’s no revenue in having IPv6 deployed (generally), but there might be lost revenue when a customer comes to your network with IPv6 as a requirement in their RFQ…
Returning to the reason that I started writing this post - the problems for IPv6 deployment don’t just come from the fact that your hardware doesn’t necessarily support it, and it isn’t just that running IPv6 on your kit might have financial implications for the software licensing that you’re going to be deploying (the arbitrary Cisco requirement for advipservices for IPv6 is a completely separate post). There are going to be issues where you don’t necessarily expect them - which can be hard to debug, where IPv6 “should just work”, it doesn’t.
Without mentioning any specifics of a case that was brought to my attention in the last couple of weeks - a customer was having problems getting IPv6 traffic flowing across a layer 2 ethernet circuit. The expectation of this circuit that you can put ethernet frames onto it (and it doesn’t really matter what the ethertype is, just that they’re valid ethernet frames) - and they are going to be punted down the link, to whatever you terminate the L2 circuit on. With IPv4, this not working would be a disastrous failure - the product just wouldn’t be working. However, this particular circuit was not passing frames that contained IPv6 packets. As it turns out, the carrier’s equipment in the path contained a firmware bug that was causing the frames containing IPv6-packets to be dropped - and hence, no neighbour-discovery, and no traffic flow between the two ends of the circuit.
This is just one isolated case - but the question is, where else in your network do you have a problem like this one? How much kit that may, right now, be considered something that shouldn’t be interfering anywhere above L2, is going to exhibit this type of problem? How much load is this going to cause your NOC? How much time liasing with circuit suppliers, and telcos is going to be spent actually deploying IPv6 on your network? I think these questions are starting to form a basis of why SPs should be startng to roll out IPv6 onto your network now. The lack of transition plan from IPv4 to IPv6, and the fact that IPv6 hasn’t had widespread deployment testing across many platforms and transmission media mean that deploying IPv6 in a rush across your network isn’t necessarily going to be as easy as you’ve thought.
Whilst I applaud the fact that Nominet are ensuring that they’re going to be ready to run the UK ccTLD with IPv6 nameservers, and that their infrastructure is ready - I don’t think that IPv6 is going to be quite as easy to deploy as Brett found in his blog post.