Expanding the Scope of the Blog

For the folks following this blog (both of you) it’s probably become readily apparent that:

  1. IPv6 is a pipe dream, or

  2. After all of the initial testing and configuration, it turns out the demand just isn’t there yet, or

  3. We’re pretty lazy (or busy — take your pick)

In reality, it’s a bit of each. While we know IPv6 isn’t really a pipe dream, and that IPv6 traffic increases every day, the portion of our workdays involving IPv6 equals exactly 0.00%. If we want slightly more involvement, we could always work at Google; according to their IPv6 statistics, IPv6-enabled Google users account for 0.68% of their workload at the time of this writing…​

While we’re certain there will eventually be more IPv6 content, we felt it would be handy to have a repository for the rest of the sweet nuggets of info we dig up or develop in the course of our jobs. Hence, knowledgebombs.net. Enjoy!

tags: IPv6 Blog
Ken Mix - July 31, 2012

2010 Rocky Mountain IPv6 Summit Scheduled

The Rocky Mountain IPv6 Task Force (RMv6TF) has announced details of their 3rd annual Rocky Mountain IPv6 Summit. The summit, scheduled for May 26-27 in Denver, promises to be an excellent opportunity to learn about IPv6 technologies and trends, and also to meet other people in various stages of IPv6 deployment and/or planning.

Details and registration info can be found here:

I look forward to seeing you there!

tags: IPv6
Ken Mix - February 01, 2010

Cisco ASA IPv6 Failover in 8.2(2): So Far, So Good...

After several months of empty promises, missed dates and missing features, we’d pretty much resigned ourselves to waiting until ASA version 8.3(x) (ETA TBD) for IPv6 failover support. So imagine our surprise when the 8.2(2) release notes showed the following new feature:

IPv6 Support in Failover Configurations — IPv6 is now supported in Failover configurations. You can assign active and standby IPv6 addresses to interfaces and use IPv6 addresses for the failover and Stateful failover interfaces.

The following commands were modified: failover interface ip, ipv6 address.

Keeping in mind past disappointments, we were cautiously optimistic that we might finally be able to swing our IPv6 traffic from a spare Juniper SSG (100Mbps interfaces) to our ASA 5520 failover pair (Gigabit Ethernet interfaces). The upgrade was flawless and, sure enough, there is now a spot to specify a standby IPv6 address. After a week of light testing, I can report that so far things are running as one would expect. Time will tell, but it seems that another major step has been taken towards production deployment of IPv6 in the enterprise.

Ken Mix - January 29, 2010

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

The protocol that cried wolf

As we inch ever closer to IPv4 depletion and possible network chaos, the networking community as a whole seems to sitting back and watching with a simple smirk. Sure, there are pockets of activity; announcements from ARIN, presentations at policy conventions and the ramblings of blogs such as this. But one would be hard-pressed to say that any more than about one or two percent of the community is taking note…​which is probably about the current percentage of IPv6 deployment.

To confirm my belief I asked some random CLECs, ILECs and ISPs at a recent trade show where they were with IPv6 and how soon they thought general deployment would occur. Every one reacted basically the same way:

  1. Somebody within their organization is looking into it at a high level, but nobody’s expecting deployment anytime soon.

  2. They don’t believe demand will be coming anytime soon. Many of the people I talked to mentioned that everybody has been saying for the last decade that IPv6 was coming in 2-3 years. Since it still hasn’t happened they aren’t too concerned that they will get behind the eight ball.

  3. No customers are asking for it yet and, other than a few test sites, no real content is accessible via IPv6.

The vendors and distributors at this trade show echoed similar sentiments: fringe elements of the community have been pushing IPv6 and asking for us to support it, but our manpower is better spent producing products and features that customers need today.

While that is a valid business outlook, it doesn’t bode well for the Internet as a whole if the address squeeze really happens. While these vendors may be able to push out an IPv6 version of their products before addresses dry up in a couple years, I would feel a lot better if the software/hardware had a few years and release cycles under its belt before we become dependent on it in production.

I’m not sure I can really blame any of these vendors and carriers either. Industry leaders and speculators have been predicting IPv4 depletion for years and it hasn’t happened at the rates they predicted. This isn’t the fault of the predictors however, I believe the ebb and flow of the world economy has allowed the current pool to stretch much further most insiders thought possible.

Unfortunately, all these years of crying wolf may have really hurt our chances of a smooth, albeit delayed, transition to IPv6.

tags: IPv6
Cody Lerum - May 10, 2009

IPv6 Subnet Allocation Size - The Debate (Finally) Rages

It’s been over a decade now since IPv6 was approved as a standard, and people are still arguing about fundamental issues such as subnet allocation sizes and other customer-facing best practices. In my mind, the increased tempo of the argument is a very positive sign, albeit later in the game than most people would have preferred. The fact that so many people are arguing about such a basic operational issue as customer allocations, and that they are soliciting opinions and addressing plans from folks who’ve already rolled out IPv6 in their networks is a good indicator that more people are finally getting closer to actual IPv6 deployment. Even though with there is still not 100% consensus on some IPv4 "best practices", it will be interesting to see how things shake out — especially on some of the larger networks.

For those that are curious and/or looking for an addressing plan, section of the ARIN Number Resource Policy Manual (NRPM) provides useful guidelines for IPv6 end-user assignment that I feel make sense from a common-sense, operational point of view. The manual can be found at:

One of the subjects not covered in the guide are point-to-point (PTP) subnets. There are two schools of thought on this:

  1. Always allocate a /64 subnet on PTP links. This way, you are not breaking the built-in autoconfiguration capabilities of IPv6. Or,

  2. Use something smaller. Personally, I shiver at the thought of allowing auto-configuration on a core (or even important customer access) PTP link. Also, the idea of blowing 2^64 addresses (18,446,744,073,709,551,616) addresses on a PTP link seems awfully wasteful — harking back to the days of default /8 allocations to folks like the Ford Motor Company and MIT. I like to use /124 subnets as a standard. The nibble boundary makes for easy subnetting, and with 16 available hosts (2^4), it covers 99.9999% of PTP scenarios on my network.

The debate about PTP links is just one small part of a larger argument about IPv6 addressing — namely, how much waste is too much? Many people argue that there are so many IPv6 addresses that we will never use them all. While I agree that 2^128 (3.402e+38) is a huge number, I don’t see a problem with conservation where it makes sense. Nobody knows what the future will hold, and the explosion of the Internet came as a real shock to people who originally thought that we could never utilize all of the addresses in the IPv4 space. After all, 2^32 (4,294,967,296) is still a pretty big number.

If you’d like to join the debate (or just enjoy the show), the ipv6-ops mailing list is an excellent place to start. You can join at

There you also find link to the list archives, which make for some interesting late-night reading.

The one constant in IT is change, and I’d be interested in seeing what kind of subnetting/addressing/aggregation plans others have rolled out.

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