Moving to IPv6

2010 Rocky Mountain IPv6 Summit Scheduled

ken.mix@gmail.com (Ken Mix) — Mon, 01 Feb 2010 07:08:00 +0000

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:

http://www.rmv6tf.org/IPv6Summit.htm

I look forward to seeing you there!

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

ken.mix@gmail.com (Ken Mix) — Sat, 30 Jan 2010 03:36:00 +0000

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.

IPv6 Progress in 2009 (or lack thereof)

noreply@blogger.com (Cody) — Tue, 29 Dec 2009 19:36:00 +0000

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.

RIPE IPv6 Interviews & IPv6 Advocacy

ken.mix@gmail.com (Ken Mix) — Wed, 15 Jul 2009 19:05:00 +0000

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:

DD-WRT Configuration With Native IPv6 Connectivity.

ken.mix@gmail.com (Ken Mix) — Mon, 13 Jul 2009 07:54:00 +0000

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:

http://www.dd-wrt.com/dd-wrtv2/downloads/stable/dd-wrt.v23%20SP2/mini/dd-wrt.v23_mini_generic.bin

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:

http://www.dd-wrt.com/dd-wrtv2/downloads/stable/dd-wrt.v23%20SP2/standard/dd-wrt.v23_generic.bin

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.

Kudos to Netflix

noreply@blogger.com (Cody) — Tue, 16 Jun 2009 19:44:00 +0000

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.

Cisco ASA & IPv6 Failover Update

ken.mix@gmail.com (Ken Mix) — Tue, 02 Jun 2009 15:45:00 +0000

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.

The protocol that cried wolf

noreply@blogger.com (Cody) — Mon, 11 May 2009 00:24:00 +0000

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:

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

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.

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.

1999 - The great IP crunch of 2010 - CNN.com

2003 - Exploding Universe of Web Addresses - New York Times

2003 - U.S. shrugs off world's address shortage - CNet News

2005 - A Pragmatic Report on IPv4 Address Space Consumption - Cisco.com

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

IPv6 Subnet Allocation Size – The Debate (Finally) Rages

ken.mix@gmail.com (Ken Mix) — Sat, 09 May 2009 21:20:00 +0000

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 6.5.4.1 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:

https://www.arin.net/policy/nrpm.html

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 get shivers at the idea 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

http://lists.cluenet.de/mailman/listinfo/ipv6-ops

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.

IPv6 living in a IPv4 world

noreply@blogger.com (Cody) — Sat, 27 Dec 2008 20:23:00 +0000

Good article on how improperly implemented 6in4 tunnels are holding back the v6 content providers and giving IPv6 a bad rap.

http://www.potaroo.net/ispcol/2009-01/mtu6.html

IPv6 Nameserver Glue

noreply@blogger.com (Cody) — Mon, 01 Dec 2008 01:41:00 +0000

Looks like we will be moving our domain registrations to another provider shortly. We are currently with Dotster for cost and ease of administration (mostly cost), but when I inquired about adding IPv6 glue for our nameserver records they were without clue. After repeated requests I finally got through to a tech who proclaimed that nobody is using IPv6 and they have no demand.

SIXXS.net confirms this. Looks like Network Solutions might be getting a little more business.

Now if only a few thousand other people moved their registrations for this reason we might pop up on the radar.

Linux IPv6 MTU issues

noreply@blogger.com (Cody) — Mon, 01 Dec 2008 01:33:00 +0000

I'm seeing an annoying issue with Ubuntu 8.10 and IPv6. It appears that the Linux OS is sending packets larger than 1500 bytes out of a gigibit Ethernet interfaces which is configured for a 1500 byte MTU.

This is easy to reproduce with a dual stack machine. Just SCP/FTP a file down via IPv4 and one via IPv6. You will only see about 10% of the IPv4 throughput on the v6 transfer. A tcpdump or wireshark will confirm that packets sourced from the Linux machine are larger than 1500 bytes....sometimes 10x the size. When the network connecting these two machines only supports 1500 bytes, all these oversized packets get dropped.

I've opened a case with the ubuntu guys -- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/254622

However, I'm seeing similar results on CENTOS 5.2 so I'm thinking it's less distro specific.

I haven't really heard of anyone else noticing this which makes we wonder if I'm missing something painfully simple in the configuration, or nobody is really serving any IPv6 content off a server with 2.6 kernel.

Anyone else seeing this?

Cisco ASA & IPv6 Failover

ken.mix@gmail.com (Ken Mix) — Mon, 03 Nov 2008 16:59:00 +0000

When we began planning the upgrade of our corporate infrastructure to fully support IPv6 in a dual-stack configuration, one of the earliest stumbling blocks came from an unexpected source – our Cisco ASA security appliances. By the time we’d begun our changes Cisco ASAs and PIXes had already been supporting IPv6 for a full three years (since release 7.0 in mid-2005), so I was expecting a feature-complete IPv6 product.

Initial configuration went smoothly (via the CLI, as the ASDM does not currently support IPv6 commands), but IPv6 connectivity through the ASA was spotty at best. Digging into the problem, we discovered that the Primary and Standby ASA were both transmitting router advertisements with the same priority, and that most of the hosts were sending their non-local packets to the link-local address of the Standby ASA, which was duly discarding them. A Cisco TAC request confirmed that IPv6 failover configuration will not be supported until 8.2. Timeframe for release of 8.2? Unknown.

How could IPv6 and critical enterprise functionality such as Failover be mutually exclusive, especially after three years and one full major release (IPv6 functionality was introduced in 7.0 – as of this writing the current version is 8.04)? This tells me that NO enterprises (0.000%) running Cisco ASAs have deployed IPv6 in their existing production environments. Since Cisco is the market share leader in the firewall segment, one has to wonder what percentage of North American companies have even begun planning for the approaching IPv4 exhaustion.

Ubuntu IPv6 Only Torrents

noreply@blogger.com (Cody) — Fri, 31 Oct 2008 05:25:00 +0000

If you didn't notice, Ubuntu 8.10 was released today. As usual the mirrors and torrents were flooded with eager downloaders.

Canonical was nice enough to setup an IPv6 only tracker (http://ipv6.torrent.ubuntu.com:6969/)

Unfortunatly it looks like only 27 downloads have completed in the 12+ hours it's been released.

It's a start, but when the first response to any networking problem on the support forum is to "DISABLE IPv6" I tend to think we have a long road left to travel.

Pulling the IPv4 Plug

noreply@blogger.com (Cody) — Fri, 31 Oct 2008 05:11:00 +0000

Just as a little experiment tonight I disabled my IPv4 stack on Vista and went entirely IPv6 native (no tunneling). Of course I got what I expected, a completly unusable system.

What worked:

Windows domain and Exchange - Thanks to recent upgrade of our company to Server 2008 and Exchange 2007 everything worked internally. File sharing, DNS, authentication...all worked like a charm.

ipv6.google.com - Loaded right up and I was able to search. Also if you edit your host file and add a record for mail.google.com pointing to 2001:4860:0:2001::68 (at least for right now) you can access Gmail. I'm pretty sure that this works for MAPS and DOCS. Doesn't work for TALK however.

www.arin.net - For all your IPv4/IPv6 needs...at least until they run out.

www.kame.net - Love to see that turtle dance.

What didn't work:

Basically everything else.

If IPv4 is going to run out in 2-3 years, the content providers have a long way to go.

Windows Vista DHCPv6 Issues

noreply@blogger.com (Cody) — Fri, 10 Oct 2008 18:44:00 +0000

While working through an internal deployment at the company where I work something pecurlier started to happen when we lit up an IPv6 DHCP service.

What happened was the DHCP client on Vista had trouble parsing the DNS Suffix Search List which was sent by the DHCP server. The DNS suffex of corp.company.com was sent but the OS showed

DNS Suffix Search List: corp

company

com

So instead of searching on corp.company.com it tried each of them in succession first com, then company, then corp.

I sent an email to Sean Siler who is the Microsoft IPv6 program manager (IPv6 Blog) and he has confirmed that this is a known bug which will be fixed in SP2...possibly sooner. ***I have confirmed this is fixed in the latest SP2 Beta (10/29/08)

T Minus 774 Days Untl IPv4 Exhaustion

noreply@blogger.com (Cody) — Wed, 08 Oct 2008 04:10:00 +0000

According to Geoff Huston's IPv4 Address Report there are approximately 774 days until there are no more IPv4 addresses for the IANA (Internet Assigned Numbers Authority) to assign. This means that the last 5 remaining /8's will have been assigned to the RIRs (such as ARIN). Of course this is just a projection and the actual date could come sooner if there is a rush on the last remaining addresses out there.

So if your company was unable to get any more IPv4 address after December 08...where would you be?

It's time to start asking your vendors if they support IPv6, and if they don't then ask when it will be supported. Most vendors are currently citing no demand and thus they aren't pushing development. It's time to start demanding IPv6 support in all your hardware and software...vote with your checkbook. It's time.