IPv6 is easy, if you start now

| | Comments (2) | TrackBacks (0)

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:

  1. 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.
  2. Assess the current state of those services with regards to IPv6 support.
  3. 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.

0 TrackBacks

Listed below are links to blogs that reference this entry: IPv6 is easy, if you start now.

TrackBack URL for this entry: https://blogs.psu.edu/mt4/mt-tb.cgi/55765


Nicolas said:


In my country (Argentina), I don't know of any ISP providing native IPv6. My home PC has IPv6 connectivity through a Hurricane Electric tunnel.

Now, suppose I wanted to start using IPv6 at my company. Note our ISP has no IPv6 (yet!), so the idea would be to just IPv6ize the local network. How would we choose IPv6 addresses for the local network? If we ask for (buy?) a block from ARIN, could we keep that address block when and if our ISP starts giving native IPv6?

Derek Morr Author Profile Page said:

If you just want internal IPv6, you can use Unique Local Addresses (ULAs). These are the IPv6 equivalent of RFC 1918 addresses (e.g. That would give you a way of testing your equipment and software for IPv6 support.

Alternatively, you could setup a static tunnel, like you did with HE at home. I'm not sure I'd recomment running production services on it.

Leave a comment