March 2009 Archives
A few months ago, I blogged about Cisco's new IPv6 licensing plan for IPv6: They're no longer requiring more expensive IOS feature packs to get IPv6 support. They plan to slowly roll this out across late 2008 and into 2009.
Now they've announced details on specific models:
The thought of deploying IPv6 often induces fear, anger, angst and excessive alcohol consumption. But it doesn't have to.
Right now, IPv4 works fine for most organizations. They see no reason to deploy IPv6, since they don't have a need for it today. My concern is that in a few years they will, and they'll have an "oh, shit" moment. At that point, they'll have to scurry to deploy IPv6, and like any last-minute effort, it'll be slipshod and expensive. Easy, cheap, or quick - pick any two.
If you start now and make slow, steady progress on IPv6, it can be done easily and cheaply. This sentiment was echoed by Google this week at an ISOC panel on IPv6. This is the approach we are taking at Penn State: start now, don't expect it to be perfect on day one, deploy it piece-by-piece where we can, and audit our systems extensively.
And perhaps most importantly: If you're buying IT equipment today that you still expect to be running in 5 years, it needs to support IPv6, or the vendor has to have IPv6 on their roadmap.
I recently blogged about our IPv6 planning efforts at Penn State. This is the specific charge from ITS senior leadership:
- Identify critical services which are enablers for further IPv6 deployment (both within ITS and IT at Penn State) and identify those services' dependencies. Identify what level of IPv6 support is required in these services.
- Assess the current state of those services with regards to IPv6 support.
- Prepare a plan to satisfy the requirements in step 1 and deliver the plan to ITS Senior Leadership. The execution of the plan will be left to the service providers and/or a follow-on team. However, the current team may execute selected portions of the plan immediately at the team's discretion.
In other words: ITS (central IT at Penn State) provides a lot of services. We can't IPv6-enable them all initially, but we can pick a subset which we deem "critical." For that subset, audit them for IPv4-dependencies, and develop a plan to remove those. We're about half-way through with the effort now. A final report is due in the next few months. That will contain a roadmap and recommended projects, which our various operational groups can implement as time and budget permits. But without a roadmap, we'll miss the interdependencies between services and units, which will lead to delays and increased costs.
It's been pretty painless so far. For several systems, we just need to upgrade to newer versions, which we were planning on doing anyway. We've also identified quite a bit of low-hanging fruit that can be IPv6-enabled right now. It's actually quite surprising how much can be done today.
Neither of these organizations yet offers services over IPv6, but just getting them in the routing table is a big step forward for them. I'm especially glad that Akamai is taking this baby step, since their lack of IPv6 support has been cited by many, many, many organizations as a show-stopper for their IPv6 deployments.
Netflix has IPv6
Late last month, Netflix got an IPv6 allocation from ARIN, and they're advertising it in BGP. It doesn't appear that they're offering any services over IPv6 yet, but this is a good first step. I look forward to the day I can stream movies to my Netflix set-top box over IPv6.
DynDNS has an IPv6 plan
DynDNS has announced an IPv6 plan. They still have a lot left to do, but they've already got a few boxes reachable over IPv6.
Cisco releases more "free" IPv6 support
Late last year, Cisco announced a change in their IPv6 pricing policy: They no longer plan to charge extra for IPv6 features in IOS. They've been rolling this policy out across their product lines. Last month, they released an update for the 3560/3750 series: IOS 12.2(50)SE. This release moves IPv6 support into the "free" IP-BASE version, and adds support for Layer 2 IPv6 security features as well.
No update would be complete without my favorite pet topic: IPv6-reachable DNS servers. So far this year, seven more domains have added IPv6-enabled their DNS servers:
- .bs (Bahamas)
- .gw (Guinea-Bissau)
- .mv (Maldives)
- .mx (Mexico)
- .no (Norway)
- .pr (Puerto Rico) (note, Puerto Rico has IPv6 DNS last year, but lost it in November)
- .tt (Trinidad & Tobago)
Also, two more Internet2 members have added IPv6 DNS: University of Louisville and Louisiana State University.
Improved Internet2 IPv6 Peering
Internet2 provides IPv6 transit for both commodity and research traffic. Last year, most of the IPv6 commodity traffic flowed through Palo Alto, California, where Internet2 peered with Hurricane Electric. As you can imagine, that made for sub-optimal performance. Over the past few months, Internet2 and Hurricane Electric have added additional peering sites, first in Chicago, and most recently in New York City. This significantly improves performance.
I have a free Hurricane Electric IPv6 tunnel at my house. It's now faster to use their IPv6 tunnel than native IPv4 to connect to Penn State. I'm sure much of this is due to Comcast's... sub-optimal routing, but I'm nonetheless enjoying the irony.
So, more deployment and better performance. I'll take what little I can get.
Oy, it's been a while since my last update. Lots of news to report. I'll spread that out over several posts.
Last month, I gave a talk on Campus IPv6 Deployment at the Winter 2009 Internet2 Joint Techs workshop in College Station, TX. The gist of the talk was that the main barrier to IPv6 deployment is attitude and perception. Although there are plenty of technical issues to overcome, the technology is good enough for initial deployment, and we have to start doing that now. The hurdle to overcome is attitudes like "no one is using IPv6" and "IPv6 is a network issue."
People are using IPv6. And there's a lot more to a successful IPv6 deployment than upgrading some routers and firewalls.
I've never seen IPv6 as a network issue. Maybe it's because I'm not a network engineer. Maybe it's because I've always thought the OSI model was a fiction. But I approach IPv6 deployment from the perspective of services not devices. E.g., what services do we need to IPv6-enable to make IPv6-only machines viable from a policy compliance perspective?
We have some good news to report on this front. At Penn State, we've got a fair bit of buy-in about the importance of IPv6 from the senior leadership in central IT. Our deputy CIO has tasked me with leading a team to develop an IPv6 deployment plan for central IT. We're only about two months in, so we don't have much to report yet. I should say that we are only charged with developing a plan; we're not yet implementing it, although I am pushing for little bits of deployment whenever I can. We should have the final report done in a few months, and I should be able to post more then.