IPv6 Progress in 2009 (or lack thereof)

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.

Cody Lerum - December 29, 2009

RIPE IPv6 Interviews & IPv6 Advocacy

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:

tags: IPv6 RIPE
Ken Mix - July 15, 2009

DD-WRT Configuration With Native IPv6 Connectivity

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.

  1. First of all, you’ll need a WAP that is capable of running DD-WRT. Although I’ve tried a couple of brands, my favorite in terms of cost, availability and ease of conversion is the Linksys (Cisco) WRT54GL.

    NOTE: The next step could potentially render an otherwise-working WAP inoperable. Perform at your own risk!

  2. Next, you’ll need a version of DD-WRT that supports IPv6. I’ve had good luck with v2.3 SP2, so that’s what I’m going to recommend. Before you can install the DD-WRT standard image, however, we must first upgrade the WAP to a DD-WRT standard mini image from the standard Linksys firmware upgrade page in the WAP’s web interface. I’d recommend the following for this upgrade:

    If you think it is hung, wait a couple more minutes. Patience now can save you a real headache later. Once the mini image has loaded (the new admin username is root), you can upgrade once more — this time to a release that supports IPv6. Again, my recommended version is v2.3 SP2. I’ve had several WRT54GLs with >2 years uptime on this release, which in and of itself justifies a DD-WRT conversion. The standard generic release can be found here:

    Again, patience is a virtue. If you do end up bricking your WAP, some useful recovery advice can be found on the DD-WRT Wiki.

  3. Once the WAP is up and running the standard DD-WRT release, we’re ready to go. Under the Administration->Management tab, select "Enable" for IPv6 Support. As soon as you click "Enable", the section expands to include configuration information for Radvd. Select the "Enable" button for Radvd enabled, and then enter the following in the Radvd config text box (customized according to your configuration, of course):

              interface br0 {
              AdvSendAdvert on;
              prefix 2607:F3D0:XXXX:YYYY::/64 {
              AdvOnLink on;
              AdvAutonomous on;
              AdvRouterAddr on;
              };
              };
              

    Click the "Save Settings" button when you are done to do just that.

  4. Now we’ll want to make sure that our static IPv6 addresses are persistent across reboots. To do this, click into Administration->Commands. Enter the following text (again customized for your config), and then click on the Save Startup button.

              sleep 5
              ip addr add 2607:F3D0:XXXX::ZZ02/124 dev vlan1
              ip addr add 2607:F3D0:XXXX:YYYY::1/64 dev br0
              ip -6 route add 0::/0 via 2607:F3D0:XXXX::ZZ01/124 dev vlan1
              kill -HUP $(cat /var/run/radvd.pid)
              
    (br0 is the LAN interface and vlan1 is the WAN)

    If you want to test your configuration before saving the startup script, you can click the Run Commands for realtime execution.

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

tags: IPv6 DD-WRT
Ken Mix - July 13, 2009

Kudos to Netflix

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.

tags: IPv6 Netflix
Cody Lerum - June 16, 2009

Cisco ASA & IPv6 Failover Update

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.

Ken Mix - June 02, 2009
About Knowledge Bombs
Random bits of knowledge that we don't want to forget and that might help you!
Cody Lerum
Ken Mix