IPV6 is here and its going to be a bumpy ride.

[dead:beaf::1]
Today much of the internet backbone began the switch over to IPv6 making [dead:beaf::1] a valid IP address. But its going to be a bumpy ride to get off the IPv4 systems that are relied upon every day. Theres a good deal of software that either hasn’t been ported or will never be ported because it just doesn’t work in the IPv6 world, and its not just restricted to userlevel applications, it goes all the way down to kernel services.

 

Porting Software

Its been quite a while since the RFCs that defined how and what IPv6 is.

Its been long enough time to introduce a number of idiosyncrasies in nearly every platform a sane person would want to target. For instance on Fedora based OS you will find a definition for localhost and localhost6 the former being IPv4 and the latter being new V6. But goto Solaris and you will find localhost defined as both a V6 and V4 address – more than a bit annoying for cross-platform apps.

Other bugs exist within Fedora where the network-settings manager for network doesn’t actually allow you to configure IPv6, you can make the changes but then are never written out. (Thankfully this is being fixed) Ubuntu on the other hand fairs much better, but also has some oddities.

The other problem is the majority of networks are expected to work in Dual-Stack for the forceable future as the old infrastructure is replaced or upgraded. That means at a basic level you have to maintain code that can interoperate between the different address types. This thankfully is relatively as there is a standard set of new APIs for Linux/UNIX and Windows.

Except that when you try and connect to a unreachable IPv6 address it can take a very long time (upto 3mins) before the OS tells you that it can’t connect, before you can fall over onto the legacy IP protocol. There is a solution known as Happy-Eyeballs which should alleviate the problem, but outside of the browser space there appears to be very few bits of software that use it, main because it necessitates the use of non-blocking IO which in legacy code can be a pain to integrate.

NAT

When it became plainly obvious that IPv4 was running out of space, some network boffins create the NAT protocol as a stop-gap measure to prolong the lifetime of the address space. However, the good intentions were spoiled when consumer level routers decided that NAT could be used as a firewall, something it was never designed for. But by masking internal addresses worked in a way similar to a firwall.

The problem is that NAT doesn’t exist in IPv6 adding further complications to porting software that used to rely on NAT.

ISP Support

There doesn’t need to be much said here, other than the conversion to IPv6 is a truly massive undertaking and many of the worlds biggest ISP neither know when it will be fully rolled out or are already behind schedule.

Security

Given theres been so little real world usage, security on a broad spectrum is abit of an unknown. However, there are a number of features in IPv6 that make it heaps better than IPv4, IPSEC is enabled by default meaning it should be much more difficult to spoof packets. Theres is also support for more robust DNSSEC stuff, but this isn’t enabled by default. But theres also some easily exploited holes in the way IPv6 enabled hosts get there addresses via Stateless Auto Configuration using Router Advertisement. Most OSes will respond to any and all router advertisement packets, meaning you can Man-In-The-Middle a host or just DDoS a host by blatting it with a barrage of RA-packets – there is a CVE against both attacks and fixes are either out in the wild or coming soon.

Tunnelling?

There was a standard introduced by Microsoft called Toredo which then became an RFC for a tunnelling protocol. The idea being you could tunnel IPv6 traffic over you current standard IPv4 internet connection. While in principal this seems like a good idea, in practice you get none of the benefits of IPv6 because your still using IPv4 the heavy lifting – and introduce an additional overhead in repacking and unpacking the IPv4 wrapped packets. In short avoid in a real world situation if at all possible, but if it scratches the itch go for it.

 

Leave a Reply