As this year comes to an end, our march towards IPv6 seems to be a little bit of a mixed bag. On one hand it appears that great strides have been made in raising the awareness that IPv6 is coming and there likely isn’t much that can be done to slow it down. On the other hand it feels like vendor support for IPv6 has either slowed or, in some cases, taken a step backwards.

Cisco, for example, started pulling existing IPv6 features from the 870 series of routers (possibly others, but I’ve only run across it on 870s — so far). Their rationale, however depressing, does make sense. The features were added to the code years ago and just kind of sat there, used by very few customers. Then, in the last year as IPv6 interest started to pick-up, people started opening bug reports on Cisco’s implementation. Rather than allocate the engineering resources to fix the problems, Cisco decided to remove the features. From a business perspective, I can’t really fault them on that; as far as I can tell IPv6 is still only used by forward-looking people inside the industry for testing and non-critical applications.

We did start to see some IPv6 content from mainstream providers did with Netflix’s streaming via IPv6 and Google’s IPv6 DNS Whitelist, but unfortunately progress is still hindered by a lack of widespread consumer adoption; enabling IPv6 on your money-making website is more likely to cost you money in lost traffic than increase it.

Will 2010 be the year we start seeing widespread support? It should be an interesting 12 months.

For those interested in the experiences of people that have been deploying and operating in an IPv6 world for quite some time, RIPE has posted a few interviews with 'net savvy folks on their YouTube channel, with promises of more to come.

For those of you having a difficult time convincing your boss that IPv4 exhaustion is real and is something to be prepared for, RIPE has cross-posted the videos on an IPv6 advocacy and information site, http://www.ipv6actnow.org. To emphasize the urgency, Hurricane Electric’s IPv6 countdown could serve as an excellent visual aid:

As I was helping a friend enable IPv6 on a DD-WRT WAP recently, it reminded me that there are few resources in the wild that will walk a newbie through the configuration steps if they are lucky enough to have native IPv6 connectivity (or some other reason to avoid tunnel configuration directly on the WAP). The wireless routers that support DD-WRT provide an inexpensive path to IPv6 connectivity for residential users and, fortunately, the process is fairly straightforward.

That’s it! You now have the enviable privilege of telling people that you are running a native IPv6 hotspot.

Netflix appears to be the first content provider to publish anything worthwhile to the IPv6 side of the Internet.

Netflix members can now manage their rental queues and stream content over IPv6.

If you’re one of the few IPv6 enabled users out there, point your browser to ipv6.netflix.com and give it a spin.

We were pretty excited here when version 8.2 of the ASA OS was released to the public a few weeks ago. Not only was IPv6 failover to be supported in the release (per Cisco TAC — see previous entry), but as I perused through the release notes I saw several other important IPv6 enhancements: IPv6 support in ASDM version 6.2, IPv6 support in transparent mode and IPv6 support for IPS. Interestingly, the release notes did not mention something as important for enterprise IPv6 adoption as IPv6 failover support, so I decided to dig a bit deeper before diving into an upgrade. Sure enough, in the “Failover System Requirements” section of the 8.2 CLI Configuration Guide: IPv6 failover is not supported in Release 8.2(1). This was a disappointing find, but I decided to remain optimistic and maintain the possibility that maybe I’d just run across a documentation error. Going back to the source, I opened another TAC case (SR 611470841). The tech was extremely helpful, informing me that while IPv6 failover support was on Cisco’s roadmap, there was no specific release targeted for inclusion of this "feature".

Basically, since we are running a failover pair in our datacenter, IPv6 is still not an option for us on the ASA. I find it strange that Cisco would devote development time and resources to the IPv6 enhancements listed in the release notes while neglecting critical functionality like IPv6 failover support, the absence of which precludes the possibility of ANY ASA IPv6 deployment in a failover environment. Even if I deem IPv6 as non-critical traffic (at this point) and do not require IPv6 failover capabilities, the lack of support for IPv6 in the failover configuration (or at least the ability to ignore IPv6 commands in the config that is synced to the standby unit), ensures that configuration of IPv6 on my failover pair will result in unpredictable behavior from the devices on my network.

As the IPv4 deadline draws near, enterprises interested in testing and deploying IPv6 services may begin to look to other vendors for the functionality they require. In our case, a demo Juniper SSG (that we’d had no real intention of deploying) is now running parallel to our ASA failover stack, and has been running flawlessly since we deployed it.