38.107.179.213

You are NOT using IPv6.

Every day there are a flurry of news articles detailing the latest cyber security breaches within corporate and government IT networks. Lots of commentary is offered by experts reprimanding these enterprises for not defending their information. But it isn’t so simple. We exist in a complicated technology ecosystem. A mix of legacy and new systems contain a woven assortment of classified, personal and other information. These networks are supported by engineers of varying levels of training and certification.

To fix the fundamental issues, enterprises need a clear plan for the future to systematically address where they are headed. One area of increasing vulnerability is the transition to IPv6. Many corporate networks and all US government networks are in the midst of transitioning to the new Protocol. Today we are already seeing many different types of IPv6 attacks including router header, IPv6 tunnels, DNS queries and rogue router advertisements. These are complicated issues to address and organizations are just trying to keep their heads above water.

We offer our clients an alternate approach. We work with them to plan, design and test to get IPv6 implemented on all their networks. But we don’t stop there – we ensure that there is a proactive security plan in place with a focus on IPv6. We then help clients get their systems and network engineers trained, which includes holding all involved security vendors accountable.

Several Department of Defense and Security agencies are implementing these best practices with us to help ease the transition to IPv6. Departments like the US Air Force are putting comprehensive security and training plans in place and using comprehensive Deep Packet Inspection tools like our Assure6TM to monitor, detect and prevent malicious attacks. These kind of bold approaches protect mission critical networks and get to the root of the problem rather than just covering it up.

World IPv6 Day has come and gone, and overall has been a great success. Reports of IPv6 problems were almost non-existent, and IPv6 traffic volumes were significantly higher. Awareness was raised in the business, technical, and end-user communities about this important upgrade to the Internet platform. Just a few key takeaways from the event:

The success of the event is mostly a validation that organizations that have deployed IPv6 have done a good job, introducing little “brokenness” into the network function or performance by “dual-stacking” their networks and systems. Note these are organization that probably followed a good process – starting early, planning methodically, and working methodically. Many have had staff involved in the IPv6 effort for years.

It also validates that standards are well-established and provide for good interoperability between systems and that vendors have done a good job of implementing IPv6 into their products in a predictable and compliant way.

One outcome provides both good and bad news. The good news is that
IPv6 traffic volume were up – as would be expected – and shows that there are some IPv6 implementations “in the wild”. The bad news is the traffic increase was not big – many organizations remain IPv4-only. These organizations must continue to evaluate the benefits of IPv6 deployment and the risks to lagging other organizations. In a world where IPv4 address exhaustion at IANA has been reached, with regional blocks soon to be depleted as well, the networking community remains far behind where we should be, collectively, to have dual-stack capability fully deployed and proven.

IPv6 projects take time to do right – years not months for most large organizations – and can be quite expensive to run. The key is to start early, plan carefully, and make steady progress. A clean project start, training for staff, and guidance from experts – especially early – are keys to success.

Overall, however, World IPv6 Day is a big success. Some Internet properties are remaining dual-stack from this point forward. For others, there is already talk of “World IPv6 Week” late this year. I am predicting we are only about 12 months from most big content providers going dual-stack entirely. We still have much work to do as a community.

The pre-event content will stay up for awhile to provide insight into the overall event.
Salient is joining such major organizations as Facebook, Yahoo! and Google in offering all of our web content over Internet Protocol version 6 (IPv6) on June 8th. This “24-hour test flight” is sponsored by the Internet Society to help motivate organizations to get prepared for this major transition.

At Salient, this is not a one-day event. We have spent years working with Defense and Intelligence agencies to prepare for a successful and secure transition.

The U.S. Government is one of the fastest adopters of IPv6, adding new functionality for the government but also significantly increasing its vulnerabilities to cyber-attacks. To aid in agencies’ secure move to IPv6, Salient is offering the following videos on real world attack and risk mitigation scenarios based on our experience deploying security solutions:

Truths and Myths About World IPv6 Day

Things about World IPv6 Day that are TRUE…

Normal Internet users *need do nothing* to participate, and for almost all people there will be no noticeable impact to the event at all

For this one day, many websites will be reachable via IPv4 or IPv6 – rather than IPv4-alone, which is customary

The goal of the event is to shine a light on “broken” IPv6 systems and networks, and mobilize the technical community to fix whatever problems exist – discovery of those problems is a key World IPv6 Day goal

Some devices – those with an IPv6 implementation that is not working – will have trouble reaching some websites

On June 7th most sites will return to having only IPv4 services (www.salientfed.com is and will remain dual-stack)

The number of devices adversely affected by this event is expected to be on the order of 0.5% – a very small percentage – but a significant number of people and devices when extrapolated world-wide

Sometime in the future – date unknown but 1/1/2012 is a good guess – many websites will go “dual-stack” permanently, which is another reason a single-day test on World IPv6 Day is a good milestone towards readiness

Things about World IPv6 Day (and IPv6 in General) that are NOT TRUE…

No websites are going to “IPv6-only” – World IPv6 Day is about using “dual-stack” – IPv4 will still be present
Even on whatever future date when major content providers go to “dual-stack” and stay there – no sites will go to IPv6-only – IPv6-only content sites are several years (or more) away
The Internet is not “converting” to IPv6 anytime soon – the Internet is “going dual-stack” for one day – World IPv6 Day – and then again on a permanent basis in 2012 or 2013 or somewhere in that timeframe

More about World IPv6 Day

World IPv6 Day is a single-day event (June 8th, 2011, GMT-time) where many Internet websites will make their sites accessible via both IPv4 and IPv6 (aka “dual-stack”). This is a global “experiment” – an IPv6 pilot project – to advance IPv6 deployment status, in preparation for a future where almost all systems will be “dual-stack”.

Today, most sites (such as www.google.com) are only reachable via IPv4. On June 8th, many sites will also enable IPv6 services, and advertise reachability for both protocols though the global DNS infrastructure. Our site – www.salientfed.com – is dual-stack already – because we are an IPv6-centric company and leaders in IPv6 deployment.

This site is reachable over IPv4 and IPv6, and has the DNS records shown here.

  This years Rocky Mountain IPv6 Summit, put on by the Rocky Mountain IPv6 Task Force, was probably one of the best years yet.  The house was packed with some of the biggest names in IPv6, as well as, some new ones with relevant updates in the community.  My understanding was the conference reached well over 300 people in attendance, representing governments, service providers, health care, and commercial enterprise networks.

The presentations and technical demonstrations spoke on topics ranging from IPv6 enterprise deployments, service provider implementation updates, enterprise testing, vendor IPv6 updates, government deployments and government policy updates.  My favorite part: the audience was not given the “IPv4 is running out, and here’s my guess when it will finally expire.”  There was only a few references to that all week.  The audience gets a little numb to that after the second time, so kudos to RMv6TF!  All the slides are uploaded and available on the RMv6TF website here: http://www.rmv6tf.org/presentations2011.htm

The Presentation Highlights

This is a wrap-up from some of the best presentations from this year:

• Richard Jimmerson from ARIN gave a good brief on where North America is on adoption and IPv4 depletion.  As always a great perspective from our RIR.
• Jeff Carrel, from Network Conversions, gave a good practical immersion demo.  Nominated for the the IPv6 motivational speaker, .  His energy was great.  However, he probably crammed way too much in a 45 min talk/demo.
• (The great) Shannon McFarland from Cisco, gave an awesome low-down on what he recommends for enterprise.  It was the best synopsis of his book IPv6 For Enterprise Networks.
• Kiran Chittimaneni from Google gave an awesome data dump on how Google did its enterprise migration.  Very good gems on SLAAC and DHCPv6.  Google wanted to keep DNS on IPv4, since Mac OSX didn’t support DHCPv6.  However it does support DNS over RAs.  Didn’t understand why, but didn’t have time to find out why they didn’t try that.
• Chip Popoviciu from TechnoDyne gave a great case for IPv6 migration being easy, but IT being the problem.  There were a lot of good tidbits to take back to an enterprise CIO/CTO. Because if you can’t build a business case based on those, then you’ll never be able to.
• Ed Horley from Groupware Technology (and CAv6TF) gave a great assessment on where Microsoft is in the enterprise today.  Good knowing they aren’t too bad.  Just wish Lync would commit to some type of IPv6 support!
• Earlier in the Service Provider track, Chris Gundermann, Ken Sexton and Aaron Hughes went into some great depth on IPv6 routing protocols.  I still like my OSPF
• Later the next day, Barry Greene from ISC gave an awesome presentation on Cyber Criminals and how they have used and will used IPv6 in their criminal activity.  Gave some great points, loved the “7 habits of Highly Successful Cyber Criminals.”
• Then yours truly gave a presentation on the importance of IPv6 test and evaluation in the enterprise.  The big takeaway: test your systems and applications in an IPv6-only environment.  You’ll never know what still might have a hook in IPv4 unless you test it
• From the government, Shelia Frankle from NIST gave a great debrief on the NIST publication Guideline for the Secure Deployment of IPv6 and John Baird discussed DREN’s progress of IPv6 implementation.  Baird also had great points for affecting change in any organization that probably was the best part of his talk.
• Owen DeLong from Hurricane Electric gave a usual rousing presentation on the light at the end of the IPv6 tunnel.  He blasted Carrier Grade NAT (CGN) pretty hard.  He gave the case against doing it because of performance and cost issues.
• Then Tim Winters from UNH-IOL spoke about the great test event on IPv6 Customer Edge routers.  It was a good test event because it showed had bad current implementations are, and will eventually settle on a standard.  So this time next year, your Linksys home router will be able to do anything IPv6-related (DHCPv6 PD, SLAAC, etc).
• Lastly, Comcast (Chris Tuska) and CableLabs (Karthik Sundareson) had a panel on IPv6 in the home.  Apparently, Comcast has opened its IPv6 trials in the Denver area.  Go here for more details: http://comcast6.net

Final Thoughts

Throughout the conference there was a lot of overlap on NAT transition discussions.  Sadly, there was more discussion on this topic than anything else. I understand that the Internet-Drafts for NAT64, DNS64, CGN and NAT44 have been released or will be released, but I felt like 3 overlapping NAT presentations was overkill.  Also, it seemed like the last day had a bit too many “sales pitches” from the folks at Brocade, Verizon, Mu Dynamics and A10.  Next year I hope the presentations are screened a little bit better for sales-type content.

All in all, this was the best Rocky Mountain IPv6 Summit produced yet. Combined with GoGoNET Live earlier this year, this caliber of technical conferences is exactly what the industry needs right now.  No fluff, no sales pitches, not market-ecture, just the facts and help for engineers just starting out trying to crack this IPv6 nut.  Can’t wait for next year!

Updated 29 April 2011: Added links to each presentation referenced above.

On April 4th, InfoSec released what they believed to be a Zero Day vulnerability in Windows 7 related to IPv6. It was a very well written, and for the most part, well researched article that explains the issue. However, like many cyber security professionals they rushed calling it a Zero Day without checking to see if this in fact met the basic criteria to call a security issue a zero day: mainly the zero-th day of developer awareness.
Semantics aside, the issue they spoke about has been known in the IPv6 and cyber security community since the basic inception of IPv6 Stateless Address Autoconfiguration (RFC 4862). The fundamental issue is this: in all default cases of IPv6 host deployments, all operating system environments (Windows XP/Vista/7/2003/2008, Mac OSX, all flavors of Linux and Unix) the host will listen to any and all IPv6 Router Advertisements (RAs) it hears – including RAs sent by malicious systems on your subnets controlled by attackers. Add in some DHCPv6, Teredo and DNS implementations on that same platform (in an IPv4 only environment) and you got yourself the “bad mama jama” of insider threats on your hands.
The Problem and Situation (in a nutshell)

• Problem# 1: IPv6 RAs are used to send detailed network control instructions from a router to a host.  By default these are unencrypted and un-authenticated
• Problem# 2: Many IPv6 tunneling types are enabled in virtually every network today
• Problem# 3: IPv6 is enabled by default and relatively open default security settings are applied (Teredo, 6to4, etc)
• Problem# 4: Your security tools and personnel are blissfully unaware of all of these problems

The 5 Fixes are Easy
This is the time where you put down the “red” phone to your engineers and breathe easy. The fixes are already here to protect it:

1. Start deploying IPv6 on your enterprise network. Seriously, you can’t fight what you don’t know. Deploying IPv6 instead of running away from it will protect 90% of the IPv6-related threats you have on an IPv4 network. This may sound counter intuitive, but it’s not. All of those nasty threats are counteracted by deploying tools that can only be enabled if IPv6 is being used (RE: RA guard, SeND, etc).
2. Implement RA Guard (or something similar in non-Cisco enterprises) – found in the recently published RFC 6105. This is a very simple and clever implementation that blocks Router Advertisements being sent from switchports where devices that are not routers are connected. It can work with other functions like Secure Neighbor Discovery (SeND) as well, though not required.  Cisco’s implementation is probably better known.
3. Implement 802.1x access port authentication. This is another simple solution that will stop unauthorized hosts on your network. However, if the hosts may be infected with malware that runs RAs, you need RA Guard or SeND.
4. Look forward to implementing Secure Neighbor Discovery (SeND). This also started out in a standard from the IETF as RFC 3971. This function uses IPsec that is easily configured in Cisco, but is lacking in Windows client support today. Linux-based hosts have SeND clients that work very well.
5. Hold your perimeter security appliances (Firewalls, IPSs, IDSs, etc) feet to the fire. Most of them have some level of IPv6 support today, but others have a horrible implementation when you get under the hood. McAfee’s Sidewinder firewall platforms do great as standalone firewalls and basic IPv6 security, but go ahead and try to cluster them into a High Available cluster (you can’t, you have to un-install IPv6 completely to cluster them). That’s why many in the industry are looking at Deep Packet Inspection like the Assure6 platform. Deploying Assure6 would actually stop each and every issue presented by InfoSec, hands down.

Basically, the fixes are all out there and can be implemented with a little bit of intelligence and pre-planning. I recommend quickly and securely deploying IPv6 in your enterprise today and following the 5 fixes. Your network will thank you!

010100110110010101101101011100000110010101110010001000000100011001101001

Let’s make this succinct and – I hope – compelling:

IANA has allocated four (4) more IPv4 prefixes, all /8s, as is their habit.  This brings the total of 2010 allocations to nineteen (19)!  There are now only seven (7) allocations left.

The last five (5) allocations will be made automatically, one to each regional registry (aka RIR), when the 6th and 7th allocations are made – likely to be in March 2011 – if not sooner.  The Registries will in turn run out of addresses to allocate later in 2011.

Watch for the headline “Internet Panic Predicted” or something in the mainstream media within the next few months.  If you manage an IT organization, look for a flurry of calls from your executives later that day.  Be ready with a good story about how you know all about it, have it well in-hand, and how they need not worry about it.

Organizations can prepare by doing these three (3) things NOW:

1) Accelerate your IPv6 planning, design, and implementation.

2) Audit your IPv4 address assignments and deployments and, if eligible to make a request for more addresses from your RIR, make that request now, today, without delay.

3) Make a plan to conserve, reorganize, and extend – or all three (3) – your IPv4 addresses.  It is likely that you will have to do something different during the next few years to make your IPv4 address needs match your IPv4 address supply (such as resize subnets in the name of conservation, or migrate some systems from routable-IPv4 to RFC1918-IPv4, or some other “do more with no more” scheme).

If your organization does not already have a 2-year plan for managing the IPv4 runout, then you are already behind – and likely to experience impacts to your business.  In the best possible scenario, if you do these three (3) things just right, and right now, your organization may “squeak by” with no network-related business failures, lost revenue, or missed opportunities. 

In any other scenario – -where a few things go wrong or you delay making your plan — be prepared to take lot of heat and do a lot of very hurried network engineering.  I can tell you – and I bet you know- the worst way to plan a major network changes is under pressure in a rapidly shrinking time window.  Do not delay.

I am sure by now that you have heard about the U.S. Government’s new “game changing” IPv6 implementation memo. It is being hailed the new kick behind a lagging IPv6 roll-out within the Federal Government. On 28 September, US Government CIO, Vivek Kundra and the Obama Administration essentially mandated two things to all Federal Agencies:

• “Upgrade public/external facing servers and services (e.g., web, email, DNS, ISP services, etc.) to operationally use native IPv6 by the end of FY 2012” and

• “Upgrade internal client applications that communicate with public Internet servers and supporting enterprise networks to operationally use native IPv6 by the end of FY 2014.”

You might be asking what is so different between this memo, the 2005 OMB-0522 memo and the 2003 DoD Stenbit Memo? In one word: details.

The 2003 DoD memo said that the “DoD goal is to complete the transition to IPv6 for all inter and intra-networking across the DoD by FY08.” This memo provided so many loopholes such as denying what IPv6-capable meant, lack of available commercial implementations, and security concerns that it fundamentally amounted to very little progress. However, at the time these were very valid concerns.

The 2005 OMB 05-022 memo directed all government agencies transition by stating “all agency infrastructures (network backbones) must be using IPv6 and agency networks must interface with this infrastructure.” However, the demonstration in June 2008 required agencies to simply enable IPv6 on their border routers, and send one ICMPv6 (IPv6 pings) to one other point on their network. Once this was accomplished, IPv6 was disabled and “success” was achieved.

That brings us to today. The Obama Administration has made it nearly impossible to avoid meeting this mandate by stating agencies:

• Must follow the IPv6 FAR which requires IT procurements be tested and in compliance with the US Government IPv6 Profile.

• Network Address Translation should be eliminated

• Enable all public-facing services (public DNS, email, web, etc.) by 30 September 2012.

• All internal services of an agency must be enabled by the 30 September 2014.

Why now? What’s with the Big Push Today?

Cyber Security: The Obama Administration spelled out the importance because of one of the big recommendations in the cyber security document titled “The President’s National Strategy to Secure Cyberspace” by saying, “The United States must understand the merits of, and obstacles to, moving to IPv6 and, based on that understanding, identify a process for moving to an IPv6 based infrastructure. The federal government can lead in developing this understanding by employing IPv6 on some of its own networks and by coordinating its activities with those in the private sector.”

Being Left Behind: The Administration also stated “foreign governments also see a swift transition to IPv6 as a way to gain a competitive advantage in the equipment and applications markets. This, in turn, has raised concerns about the pace of IPv6 deployment within the United States and whether a “lag” in U.S. deployment could jeopardize the competitiveness of domestic firms in cutting-edge IT markets or have adverse security implications for this country.”

What Will Be the Next Steps?

Basically, it comes down to the bite and not the bark. We in the IPv6 community are thoroughly familiar with government mandates. It’s up to the policy makers and the industry to either embrace this for the betterment of humanity or to build in more loopholes to avoid this effort yet again. So which will you choose?

For some time I have been predicting that the “heat” around IPv4 exhaustion and IPv6 deployment will go up dramatically when the IPv4 exhaustion story goes mainstream – out of the Tech press and into the Wall Street Journal, or MSNBC.  To date, concern about IPv4 has been building slowly, with some organizations actively deploying (few, and almost entirely carriers), more “planning, but going slow” (the rest of the carriers, government), and even more “tracking” (all other organizations) – where “tracking” means they’ve heard about it, but are unconcerned. 

This is going to change when the WSJ runs a story like “DSL Provider Misses Earnings Projections – Cites Non-Availability of IP Addresses”.  At that point, more business leaders will ask their CIOs what their own status is – and having a good story will be important.  To have a good story ready, a CIO needs to have a plan, and have thought through that plan to make sure it is achievable.  If not, then the CIO needs to go back in time and get cracking.  In a world where time-travel is not yet commonplace, at least the CIO needs to get cracking now – and with conviction.  As a moving-towards-mainstream example, National Public Radio (NPR) ran a story on IPv4 exhaustion in August of this year “IP Address Shortage Has ISPs Scrambling For Space” on their “Weekend Sunday” radio program – it is not quite the WSJ – but it is not way-tech CNET News either (http://www.npr.org/templates/story/story.php?storyId=128907099). 

How close to that headline are we?  Closer.  Quite close I think.  Consider: 

Currently, IANA (Internet Assigned Numbers Authority) holds 14 “/8s” of unallocated space, out of a possible set of 256 “/8s” (so one (1) /8 equals 1/256^th of the entire IPv4 address supply) (note that a “/8” is a large chunk of addresses suitable for IANA to assign as a regional block, which is then divided further and assigned to carriers and large enterprises). 

In 2010 (and it is only August – not December), IANA has made these assignments – ten (10) in all:

• APNIC, January  (Asia-Pac)

• ARIN, February  (North America)

• ARIN, February (again)

• APNIC, April

• APNIC, April (again)

• RIPE, May (Europe, Middle East)

• RIPE, May (again)

• LACNIC, June (Latin America)

• APNIC, August

• APNIC, August (again)

(Note that AFRINIC – Africa – did not receive any allocations in 2010)
(For more details see http://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xml) 

Per IANA and the NRO (Number Resource Organization – another organization involved in IP address assignment), the last five (5) /8 blocks will be given out – one to each of the five (5) registries – immediately when the 6^th to the last /8 block is given to any registry – in other words assigning the 6^th to last block triggers final, close-out allocations(For the entire policy see http://www.icann.org/en/general/allocation-remaining-ipv4-space.htm) 

Consider this yet another “call to action”.  This one is a little different.  It does not call on CIOs to deploy IPv6.  It calls on CIOs to plan a strategy for IPv4 scarcity, followed by IPv4 exhaustion, throughout which the business can continue to earn, grow, and thrive.  Extending IPv4 services via some kind of Large Scale NAT (LSN) might be part of a near-term strategy, and IPv6 deployment will almost certainly be the mid and long-term strategy. 

Any CIO that hatches a (hasty, ill-conceived, incomplete, somewhat desperate) plan the morning of the WSJ article can’t say they didn’t have some warning. 

It was half a decade in the making (2005) , but the U.S. Government’s IPv6 Federal Acquisition Requirement (FAR) will be in effect on 1 July 2010 (that’s tomorrow).  In most DoD and civilian agencies, this milestone passed without much fanfare.  In fact, many of these agencies are still trying to figure out how to handle its contractual effects.

Fortunately (or unfortunately), each civilian and DoD/IC agency has a lot of latitude in terms of what level of compliance is demonstrated with this Federal Requirement a vendor product must meet in order for that agency to buy the product.

The IPv6 FAR Minimum Requirements

The minimum standard is probably what at least 50% of DoD and Federal Agencies will attempt to achieve as IPv6 isn’t being broadly implemented across the US government at the moment.  So at a minimum, the following is required per the IPv6 FAR:

“Unless the agency Chief Information Officer waives the requirement, when acquiring information technology using Internet protocol, the requirements documents must include reference to the appropriate technical capabilities defined in the USGv6 Profile (NIST Special Publication 500–267) and the corresponding declarations of conformance defined in the USGv6 Test Program. The applicability of IPv6 to agency networks, infrastructure, and applications specific to individual acquisitions will be in accordance with the agency’s Enterprise Architecture (see OMB Memorandum M–05–22 dated August 2, 2005).”

In deconstructing this further, there are two things that need to be done: (1) provide written compliance with the IPv6 standards in the IPv6 Profile from the vendor, and (2) demonstrate compliance with the standards in accordance with the NIST IPv6 Test Program.

The IPv6 Test Program 

So the minimum requirement puts the ownership on the vendor to demonstrate compliance with those standards in accordance with the NIST IPv6 Test Program.  This means the vendor must test their products in the way that the Agency requires in the RFP or procurement requirement.   That looks a little like this:

• Agency issues IPv6 requirements matrix in open or sole source procurement.
• In said requirements matrix, the Agency will state what testing is acceptable.  NIST requires that Conformance be demonstrated in at least Accredited 1st Party (vendor owned) test labs and Interoperability testing demonstrated in at least Accredited 2nd Party (Agency owned) or Accredited 3rd Party (independent) labs.  However, the minimum is 1st Party Conformance Testing for Hosts and Routers and 2nd or 3rd Party Conformance and IA Testing for Network Protection Devices (ie Firewalls, IPSs, and IDSs.
• Vendor provides IPv6 Suppliers Declaration of Conformity (SDoC) proving the stated compliance in the Agency RFP.

Is the Minimum Enough?

Of course that’s the billion dollar question.  Vendors will need to use their judgment as to how much time, effort, and dollars they want to spend on testing. If they chose to do the minimum, they may be “shut out” of some RFPs – the testing they choose to do may not meet the requirements of some agencies.  My advice is that all standard Host and Router companies invest in testing Conformance and Interoperability at one of the NIST and ISO 17025 3rd Party Accredited labs (UNH-IOL or ICSA).  Network Protection Device (NPD) vendors should submit their products for conformance, interoperability and IA testing at one of the aforementioned 3rd Party Accredited labs, as well.

The minimum might be enough for one Agency, but it may not be enough for them all.  For example, DoE might state that Conformance testing at a 1st party vendor lab is enough for that will put onto the DOE network, but the DoD may state that 3rd Party Conformance and Interoperability testing must be done for the routers that will land on DoD networks.  If the vendor only tests for DoE’s requirements, then they could potentially lose a sale for DoD.

However, each vendor must balance risk appropriately as 1 July 2010 is now upon us.  IT equipment vendors must prepare for some type of IPv6 solicitation that will meet this new requirement in the U.S. Government.  Having a plan to respond now will save millions of dollars and man-hours in the future.

  The debate began as rousing and intellectually stimulating as it ended. The motion was, “The Cyber War Threat has been grossly exaggerated.” This Neustar, WAMU, Newseum and Rosencrantz-sponsored debate refreshingly stayed on topic.  This, of course, was unlike the Bipartisan Policy Center’s Cyber Shockwave, which showed how unprepared government and industry can be in even hypothetically discussing cyber threats.

No, this debate took the best minds of cyber security, cyber defense, and cyber warfare and logically debated whether on not the United States is at the precipice of cyber war or merely lots of cyber crime. The debaters were all very qualified in their fields.

• For the motion: Marc Rotenburg and Bruce Schneier
• Against the motion: VADM Mike McConnell (ret.) and Jonathan Zittrain

The debate centered on trying to delineate the differences between cyber war and cyber crime. Both parties recognized that the Internet is not a safe place. In fact, metaphors regarding passing beer from one person to another at a Red Sox game abounded! Cyber crime, as Rotenburg argued, exists; however, calling it a war only provides billions of dollars in un-needed government expenses, and accelerates a historical “power grab” by the National Security Agency (NSA).

Rotenburg insightfully discussed the numerous attempts by NSA to take control of the Internet, referencing the infamous Clipper Chip, which, of course, was NSA’s failed attempt to be the man-in-the-middle of all encrypted communications on the Internet.

However, the side against the motion argued that this issue was not even the point to the debate. In fact, we are threatened every day by Russian and Chinese cyber warfare agencies. That’s right, they have cyber warfare agencies right now and are actively using them. The Russian cyber war attack on Georgia was referenced as evidence. Even more broad and successful cyber attacks used to reinforce traditional warfare have been conducted by Israel against Syriian radar and North Korean nuclear factories.

Unfortunately, the discussion had to remain at an unclassified level, need I say more?  Overall, the debate was very well argued on both sides. I concluded simply that the threat of cyber war is very real, but having defenses and preparations made in secret are counter productive. Keeping this issue open and transparent and reinforcing our cyber defenses are the only ways to actually mitigate these threats.

In the tradition of all Intelligence Squared Debates, a winner is chosen based on audience feedback. Initially, the vote revealed around 54% against the motion, 22% for the motion, and 24% undecided. However, by the close of the debate the tables turned: 72% against, 22% for, and 6% undecided.  So the convincing arguments from Jonathan Zittrain and VADM McConnell won the debate.

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….