For all the network architects out there dealing with the problem of trying to add IPv6 to their core applications and services, I can only say it’s getting better. Don’t give up hope. 2009-2012 seem to be the big ISP migration years. The network architect’s job is usually very different — dual-stack the pipe. Other than provisioning, billing, managing and monitoring two layer 3 stacks and migrating customers; enterprise services are not an architect’s concern. To that end, I would like to lay out a few lessons we (Command Information) have learned along the way architecting an IPv6 migration for the average enterprise network.

Issue #1: It’s all about the architecture
You can’t install new plumbing in a house if you don’t know where the current plumbing is, right? Same goes with IPv6. If you want to shake your finger at a vendor to make sure they provide native IPv6 support in their products, then yelling at them to comply with a mandate has little meaning to them. They will deal with your organization as the “check-mark IPv6 user.” These are the U.S. Federal Government (and DoD) enterprises that know IPv6 is an acquisition hurdle, but they don’t ever want to use it (or have a plan to do anything with it). If you are one of these organizations, I suggest you keep reading, because ignoring the problem does not make it go away. In fact, it makes planning and implementation that much harder.
Another reason having an IPv6 architecture in place is that it provides added benefits to the system. It harmonizes and centralizes the entire IT infrastructure because in order to develop said architecture, one must research the past, present, and future of the network. You might come to find that the IPv6 architecture inevitably turns into the only network architecture for your enterprise.

Issue #2: Native IPv6 support may not exist in all of your current and legacy applications (don’t freak out)
Given that this is the case in every enterprise, you need to make a choice: (1) Will you keep these applications on legacy hardware/software on a legacy IPv4-only network enclave? (2) Will you try to upgrade them by updating the code to make more contemporary socket/API calls, or (3) will you risk keeping them on the current dual-stack infrastructure using only the IPv4 stack? There is never a single answer to a situation. It is always conditional. For example, if one of these server applications was written 10 years ago and code familiarization has not been maintained, this may be a case for “test or isolate.”

A test or isolate principle is basically standing up a server with the mix of subject applications, enabling IPv6, and running a few functional tests. The best option is #1. Odds are your network applications need some TLC (Tender Loving Care) anyway, so this may be the best opportunity. However, if re-coding is not an option and everything checks out OK in those tests, then #3 might be just fine. Usually #1 has the highest risk of performance and availability issues.

Issue #3: IA and Cyber Security issues on the enterprise
Didn’t think I’d leave out the most important of the three, did you? This issue has so much mis-information surrounding it that we hear on a regular basis from IA Managers, Security and Accreditation Officers, etc., so I’d like to set the record straight with the following:

• Myth #1: IPv6 is not a security issue. In fact, that statement is partially right. IPv6 on a network does not, in itself, provide intrusion risks, but trusting your current IA architecture is wrong. Assessment after assessment, the IA industry has failed to fix this problem. Every vendor from Sourcefire, to McAfee, to TippingPoint, to Fortinet is not addressing the real problems. Keep reading, we’ll get into those.

• Myth# 2: I’m not running IPv6 so there’s no risk. I hear “we are blocking IPv6 at the edge,” or “IPv6 and known tunneling like protocol 41 is being blocked, so there’s no issue.” Sadly, this isn’t the case. In the past 3 months Command Information has uncovered high-risk tunneling and attempted hacks/probes using IPv6 on Federal Government networks. So merely blocking and filtering based solely on port and protocol is not enough. That’s why deep-packet inspection is key to solving this issue. Don’t believe me? Well, don’t take my word for it, but will you take Bob Gourley’s word for it? See article here.

I wish those were all the issues an enterprise network could face, but that’s only scratching the surface. More later, Semper Fi….

This entry was posted on Tuesday, May 4th, 2010 at 12:09 pm and is filed under Real IPv6 Features Series, Jeremy Duncan, Cybersecurity, Federal Enterprise Architecture, Blog: IPv6. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.