Navigating IPv6


SAGE-AU is a guest blogger.

SAGE-AU is a not-for-profit professional organisation that promotes the development of the system administration profession.

On the 12th of January the Internet Society announced that several major internet content providers would be switching IPv6 on for the world on June 8th as “World IPv6 Day”.

Google have notably been rolling out IPv6 access, but only to users on prescribed networks. Joining them will be Facebook and Yahoo, along with two of the largest CDN's, Akamai and Limelight. For many networks these combine to over a third of all Internet traffic.

Although none of these providers are looking at turning IPv4 off any time soon this short window makes a great goal for IPv6 laggards to have a test deployment. While it’s true that IPv6 may not be the best possible solution, at this late point in the game it’s simply the only option available to keep this critical global network alive.

By the time this reaches print IANA will almost certainly have handed out the final IPv4 blocks to the regional registries, and sometime this year APNIC, the RIR for the Asia Pacific region, is likely to run out their own reserves, leaving two options for those organisations that run out, extending existing NAT’s overloading more clients on a single public IPv4 address, or deployment of IPv6.

Not long after that we should expect to see new content providers and “eyeball networks” that perform better over IPv6, by the middle of the decade we’ll start seeing services pop up that can only be used over IPv6.

Unfortunately many components of today’s enterprise networks only received IPv6 support last year, with many security features partially implemented, if at all. Even worse is the carrier situation; of all the “Tier1” carriers in Australia only Telstra has significant IPv6 deployment with service available to customers.

Of course thanks to a collection of “transition methods”, the two most common being 6to4 and Teredo, your desktop machines may already have unintended IPv6 connectivity if you’re not careful about outbound filters, and being a tunnelling technology this bypasses any firewalling in place preventing outside connections to desktops. This is the default configuration of Windows Vista and newer, and can be configured on XP and all the various UNIX variants including Mac OS X.

Oddly the issue that I have seen come up most often following carrier support is actually deciding what order to do the rollout; desktops first or servers first. Either way the first target is to ensure the core network, that is routers, load balancers, switches – not just Layer 3 switches, but any switches that perform any Layer 3 inspection – and firewalls all support IPv6 for all needed functionality, and with similar performance to IPv4.

With firewalls a lesson that needs to be re-learnt is that NAT is not a security feature, and a proper stateful firewall can result in more effective security without NAT in place, especially when tracing problems that may originate from your network.

If taking the servers first route, the first deployments should be services that are made highly available above the IP layer, most commonly DNS and mail systems. By converting some, but not all, of these systems to speak both protocols you can ensure native service for those with IPv6, whilst preventing any issues for those with even badly broken systems, a number that’s now estimated somewhere between 0.02% and 0.3% of all web users, a now-fixed bug in Mac OS X is causing that number to rapidly drop.

Web servers are a common next choice, with nearly all web applications “just working” when accessed over IPv6. If deploying to desktops then, as with all desktop rollouts, a good way to work is to choose some technically savvy users and deploy to them and monitor, then slowly increase the scope until IPv6 is just a standard desktop feature.

Once these are done you can expand the scope by slowly taking other services and bringing them up on IPv6, once major services are migrated by using NetFlow or similar you can see just how much traffic has migrated. Once IPv6 has become standard for office systems, ensure all VPN or other remote users are catered for, then start considering removing IPv4 from some non-critical services, or deploying new services as IPv6 only.

Some reports have been published about this, showing that with careful selection of services a majority of internal traffic can be migrated to IPv6 in only a few months, requiring only small, monitored changes that take little time away from day-to-day operations management.

As with many things this is a significant amount of work, and a huge change to a system we all know and have a deep understanding of, however it’s necessary, and groups that ignore the coming changes will, unlike most changes in this world of technology, not just make themselves less efficient, but soon hurt their ability to communicate with other people and organisations.

By Julien Goodwin

Julien manages large-scale learning management systems at Editure Education Services in Melbourne and is a member of SAGE-AU a not-for-profit IT Operations and System Administrator profession organisation, SAGE-AU. For more information go to

Show Comments