Posts Face IPv6 Challenges
IMPLEMENTING NEXT-GENERATION INTERNET NETWORKS ON ARMY INSTALLATIONS POSES TOUGH TECHNOLOGICAL AND POLICY ISSUES.
When the Department of Defense first began implementing communications networks using Transmission Control Protocol/Internet Protocol (TCP/IP), network protocols were fairly immature. Configuration of devices was manual, security and prioritization were absent, network management was immature, and communications speeds were incredibly slow by today’s standards. Over time, our IP networks have become more robust, more user-friendly, and equivalently more relied upon by users and managers. Our users now expect a high level of performance from our IPv4 networks. We have in-depth security systems, highly robust network management, auto-configuration, prioritization, converged voice and video, multicast, mobility and high-speed performance capabilities on our IPv4 networks.
The challenge of implementing IPv6 into an Army network comes from two conditions placed upon DoD by Congress: Do No Harm and IPv4 Parity. The first is easily understood and met—we do not want to diminish our current communications capability in order to develop a future capability. The second is the real challenge: that the IPv6 network will perform equivalent to or better than the current IPv4 network.
The upside of IPv6 implementation is that most IPv4 vendors are now moving to support IPv6 in the same devices that currently run our IPv4 networks. The downside of IPv6 implementation is that the equivalent features and capabilities of IPv6 tend to lag several years behind IPv4.
In June 2003, the DoD chief information officer published a memorandum requiring a migration of DoD networks to IPv6. This and a subsequent memo defined that the IPv6 transition would be accomplished through technical refresh cycles, and that all future purchases should be of IPv6-capable products, with a loose definition of what IPv6-capable means. The hope was that by 2008, all network devices would be IPv6- capable and enabling IPv6 would be relatively simple and cost-effective.
The fallacy of this approach is that the products available for purchase in 2003 were not really IPv6-capable, and continuing progress has not generated IPv6-capable products. It was well known in 2003 that several Asian countries were building IPv6 networks, but the commercial products available at that time did not have the capabilities of IPv4. For example, Gigabit Ethernet (GbE) switches, which pass IPv4 packets at rates of 1 billion bits per second could only pass IPv6 packets at less than 1 percent of that rate. This may not have been an issue for China, which had little to no IPv4 infrastructure, but it stymied DoD deployments. Even now, four years later, many capabilities regularly found in IPv4 products are not available in IPv6 implementations, and vendors are more motivated to build new IPv4 capabilities than to improve IPv6.
PILOT STRATEGY
One of the DoD goals is transition through technical refresh. Communications hardware often gets replaced every three to five years. Replacing the hardware with IPv6-capable products, if they existed, could be accomplished with little additional cost. The technical refresh approach, however, does not solve all the needs of a transition to IPv6. At best, it can cover much of the hardware and software cost of the migration; but it fails to address many other issues such as testing, modeling and simulation; developing policies; changing security archi tec ture; increased operations and maintenance; and training.
DoD’s solution to these gaps in the implementation is through the extensive use of pilot programs. A pilot is considered to be an intermediate step between test and implementation. The department hopes to eliminate much of the costs of testing and training through the use of service pilots and has been pressuring the services to identify pilot candidate programs and to begin testing IPv6 in constrained implementations.
In addition to the memoranda mentioned previously, numerous different mandates and memos from DoD, the Office of Management and Budget, and assistant secretary of defense for networks and information integration provide guidance for implementing IPv6 on government and DoD networks. Following are the milestone objectives for conducting an IPv6 pilot:
• Milestone Objective 1 (MO1) states that services and agencies are authorized to operate IPv6 systems within an enclave. The MO1 allows the use, familiarization and testing of IPv6 protocol and applications for operational pilots in order to ascertain issues and derive migration strategies. Pilots have been authorized to operate at MO1 since 2005.
• Milestone Objective 2 (MO2) provides the ability to evaluate the scalability and further evaluate the IPv6 information assurance implications using tunneling and native IPv6 routing, as available. The MO2 permits applica tions to test IPv6 specific endto- end capabilities and routing schema efficiencies. Pilots were authorized to operate at MO2 last year.
• Milestone Objective 3 (MO3) will be authorized when all policy, planning, and technical transition guidance has been provided to allow tunneled and native IPv6 traffic to exist on DoD operational networks. The MO3 will permit applications and data owners to complete operational transition to IPv6 with at least the same functionality as currently found in IPv4. The target date for MO3 is fiscal year 2008.
The Army is considering leveraging the Installation Information Infrastructure Modernization Program (I3MP) to conduct a pilot for IPv6 on an installation. I3MP provides for the engineering, acquisition, implementation and management of the Army’s installation level telecommunications infrastructure. While I3MP is primarily responsible for Ethernet switches that compose the network backbone, a pilot cannot simply be enabling IPv6 on a couple of switches or routers. An effective pilot requires an IPv6 application running across the post infrastructure, demonstrating the operation of IPv6 end to end.
At the I3MP program manager’s request, engineers at the U.S. Army Information Systems Engineering Command conducted an analysis to determine how to enable an IPv6 pilot on an Army post. Our approach to this analysis was to answer the question, “What do we need to do on the post today to be ready for IPv6 application tomorrow?”
We scoped the problem with a couple of assumptions, including that every affected device in the system will be dual-stack, supporting IPv4 and IPv6. This includes the application server, client and network backbone. There will not be any IPv6-only devices and no tunneling. In addition, the application will reside entirely on-post. The client and server machines will all be on the same post and no IPv6 traffic will leave the post. This meets the MO1 guidance.
NETWORK REQUIREMENTS
On an Army installation network or any campus network, the network backbone typically consists of IP routers and switches overlaid on some type of layer 1 and 2 communications technology (Asynchronous Transfer Mode, Ethernet). This backbone provides connectivity for the central server farm, network management stations, and client devices. The Army post connection to the Internet is protected by a security suite, through which all external traffic must traverse.
Several issues must be addressed that will affect all aspects of the IPv6 implementation. These are policy, addressing and training. For policy, current DoD directives state that IPv6 traffic is not allowed on any operational DoD network, except under a pilot project. The DoD IPv6 Transition Office (DITO) has established that any pilot must adhere to the MO1 and MO2 guidance and must be registered with the DITO. Another policy issue relates to security. A pilot implementation must define appropriate security policies of what IPv6 traffic will be allowed on the network and where that traffic will be allowed to go.
An address plan is necessary before establishing IPv6 traffic. Most IPv6 experts suggest that a post IPv6 address plan should closely reflect the current IPv4 addressing plan, to ease network management, but opportunity exists to improve the addressing scheme in IPv6. Addresses should be given out in a manner that will facilitate hierarchical routing, where prudent, and should follow Army and DoD addressing policies. Unfortunately, Army and DoD addressing policies are not complete at this time, and so a post cannot at present obtain permanent IPv6 address space.
The final global requirement is equipping the network administration team, who will be responsible for troubleshooting network problems and enabling IPv6 on the network. Network administrators require training on the IPv6 protocols and require tools that can analyze both IPv4 and IPv6 traffic.
Network Backbone. The backbone of an Army network typically consists of a handful of Layer 3 (L3) Ethernet switches, which support connections to the user buildings. The user buildings are connected by Layer 2 (L2) Ethernet switches or other L2 technology. The L2 devices do not deal with traffic at the IP layer, so do not have to support IPv4 or IPv6, other than to support remote network management access.
Current I3MP requirements dictate that L3 switches must meet full performance parity of IPv6 and IPv4. This means that those switches must be able to transmit the full 1 or 10 Gigabits per second on each GbE or 10-GbE port. In addition, they must have support for Open Shortest Path First (OSPF) version 3 (the IPv6 equivalent of OSPF version 2), and must support IPv6 Access Control Lists (ACLs) and security logging. Often an L3 switch will be dualhomed, so if one link fails, the other will automatically take over. This should be a requirement for IPv6 traffic as well as IPv4. Lastly, all IPv6 devices must support Internet Protocol Security (IPSec), according to IPv6 standards and the DoD Information Technology Standards Registry (DISR) Product Profile.
There are several L3 switches that meet the performance, OSPFv3, and ACL/security logging requirements, but none tested at the Technology Integration Center have met the IPSec requirements to date. We have not tested dual-homing capabilities for IPv6 to date, so that capability is unknown. Additional I3MP requirements go into effect on January 1, 2008, requiring L3 switches to fully support IPv6 network management and IPv6 security, equivalent to current IPv4 standards.
Client Devices. A typical IPv6 application will communicate between a client and a server across the network. For the assumed scenario, some number of client computers will need to be IPv6-enabled. This will require a computer operating system (OS) that can run in dual-stack mode. Most commercial operating systems can do this; LINUX, Solaris, Macintosh, and Windows Vista all support IPv6 fairly well. Windows XP lacks many IPv6 capabilities, so it should not be used for a pilot.
In addition to a dual-stack OS, the client system needs some sort of autoconfiguration support from the network. Dynamic Host Configuration Protocol is not mature in IPv6, so switch-based autoconfiguration is the preferred method, and it is supported in most L3 switches.
Those are the minimum requirements; however, several features that users expect from their client devices are not mature for IPv6. Public key infrastructure and common access card support, for example, are not developed yet for IPv6. Active Directory and thin-client support for Microsoft OSs are not established yet for IPv6 either, although Microsoft promises these features in their next server OS, Longhorn, due in late 2007. Dynamic Domain Name Service (DDNS) is also not mature for IPv6. The DDNS is highly valuable for network managers, who otherwise have to manually enter every IP address into static DNS tables. Manual entry is very time-consuming and errorprone with IPv4, and much more so with IPv6.
Finally, the issue of user applications is critical to IPv6 deployment. At present, few commercial applications fully support IPv6, and it is incredibly rare to find one that uses features of IPv6 that IPv4 cannot support. This is a major issue in the push for IPv6 deployment: Without applications that use IPv6 features, the motivation to migrate to IPv6 is very low, and the momentum to improve IPv6 capabilities in network devices very limited.
Server Farm. The server farm is where the domain controllers, mail, file and other application servers reside. It is typically a centralized location where the network administrators can conveniently maintain hardware components, monitor security patches and conduct system backups. For an IPv6 implementation, the required components are an IPv6-capable DNS system and a dual-stack OS on the server that will host the IPv6 application. Other server farm components, such as DDNS, Active Directory and back-up tools, are optional to run on IPv6 at this time.
Commercial DNS products have supported IPv6 for several years; in fact, DNS is one of the first aspects to fully support IPv6. Dual-stack OSs are coming along. Most UNIX platforms support most IPv6 features, but Windows 2003 does not. Microsoft’s Longhorn promises built-in IPv6 support, including Active Directory and DDNS support over IPv6. Longhorn will require a 64-bit server bus, which means many DOIMs will have to upgrade their server hardware to implement it. Once released, users should expect several months before Network Enterprise Technology Command (NETCOM) policy allows Longhorn’s implementation on Army networks.
Standard office applications do not typically make use of IPv6 features and often do not support it. Microsoft’s Exchange 2007, for example, will not support IPv6 until Service Pack 1, due out late this year. Other applications are at various stages of IPv6 implementation.
Network Management. Network management over IPv6 will often be one of the last areas enabled for an IPv6 implementation. Devices that use IPv6 traffic in a dual-stack mode can be managed using IPv4, without any impact to the IPv6 traffic. Network management is also the least mature of the IPv6 technologies in the commercial realm. It will eventually become a requirement when the Army moves to IPv6-only deployments, and with that goal in mind, I3MP is requiring IPv6 network management in L3 switches starting in January 2008. But few vendors presently show much capability in this area.
Element manager tools, like Hewlett- Packard OpenView and Spectrum, use secure Simple Network Management Protocol (SNMP) over IPv4 to manage network devices, but presently do not support secure SNMP over IPv6. Patch management tools, like Systems Management Server (SMS) and anti-virus updates, currently cannot be accomplished over IPv6. Again, these tools do not need to run over IPv6 for a network to support IPv6, but we will eventually need this capability when we leave our dual-stack environments for IPv6-native deployments.
Network management includes the ability to scan networks for hostile IPv6 traffic, IPv6 viruses, and vulnerabilities to IPv6 attacks. It also includes the ability to analyze traffic patterns and tools for troubleshooting and optimizing networks. These tools are things DOIMs use frequently in their day-to-day operations and are vital for deploying and maintaining an operational or a pilot network. Some network sniffers, such as Ethereal, support IPv6, but the status of vendor development for other scanning tools varies, and DOIMs will need to determine if the tools they presently use can support IPv6.
Security Suite. For any campus network, the security suite protects the network from external intrusions and attacks. For the Army, it is typically installed and managed by NETCOM, instead of the local DOIM.
Our initial conditions for this paper stated that an IPv6 application would not leave the local post. This means that the security suite really is not involved in passing IPv6 traffic. The only thing necessary in the TLA stack is to block IPv6 traffic from crossing either direction. Current firewalls do this by default, so no action is necessary at the security suite for a local pilot implementation.
However, the Army is moving toward regional server consolidation, so remote applications are desirable. If an IPv6 application were to be hosted at a remote location, several new requirements would emerge. First of all, some sort of tunneling mechanism would be required between the remote server and either the local servers or the client machines. The tunnel mechanism must encapsulate the IPv6 data into IPv4 packets to ship across the NIPRNet. Tunnel mechanisms exist, but they create a new requirement for security devices, firewalls and intrusion detection systems (IDSs). In a tunnel, IPv6 packets are encapsulated within IPv4 and usually encrypted. This makes deep packet inspection, required by current defense-in-depth policies, extremely difficult. Security as an industry is far behind in the deployment of IPv6, and finding IPv6-inspecting firewalls and IDSs is challenging.
An alternative solution to tunneling is to use IPv6-capable virtual private networks (VPNs) to encrypt IPv6 traffic between the local post and the remote servers. This removes the requirement for a tunneling device and bypasses the issue of packet inspection on firewalls and IDSs because encrypted traffic cannot be inspected. This approach is counter to the current security policies, however, and much collaboration is needed between DoD and Army security architects and IPv6 implementers to work through these security issues.
Eventually, we will need to open up the entire network to IPv6 traffic, so that IPv6 applications can communicate between any military posts and to the Internet. When that time comes, we will need full IPv6 support on firewalls, IDSs, VPNs, and proxy servers. Current security routers may require hardware upgrades to support dual-stack, and industry will have to start building IPv6 capability into these security devices, which at present have very little IPv6 support.
GLIMMERS OF HOPE
A lot of the delays in DoD’s IPv6 implementation have occurred because commercial vendors do not see the pressing need to migrate to IPv6. Twenty years ago, DoD was a dominant customer in the communications industry and defense directives were taken very seriously by industry. Today, it represents a relatively small market segment for most commercial vendors. To make matters worse, the department as a whole is not investing money into IPv6 development and is only half-heartedly promoting IPv6 implementation on its networks. It is a classic Catch-22: Defense agencies do not want to invest a lot of money into IPv6 until industry starts making better products, but industry does not want to spend a lot of money developing IPv6 products until customers start buying them.
Some glimmers of hope do exist, though. DoD has established a number of test beds where IPv6 capabilities are being evaluated and products are being recommended for implementations. For example, the Army’s TIC has established an IPv6 System Integration Facility for validating IPv6 capabilities for hardware, software and systems. Under the sponsorship of I3MP, this lab is testing Ethernet switches, routers, OSs and security devices. They also are testing commercial applications and are able to test Army-specific applications in a replicated Army post environment.
DoD has also established an Approved Products List (APL) of commercial products that have demonstrated conformance to DoD standards, interoperability with DoD equipment, and a certain level of performance in IPv6. As the APL gets populated, the department intends to mandate that only products on the APL can be purchased and used on DoD networks.
Several concerns are prevalent in any implementation of IPv6, with IPSec one of the most controversial. Current guidance states that all IPv6 devices must support IPSec. Current NSA guidance appears to indicate any IPSec device is an IA device and therefore must undergo Federal Information Processing Standard (FIPS) certification and National Information Assurance Partnership (NIAP) Common Criteria evaluation. The majority of IPv6 devices available at present do not support IPSec. Both the development of IPSec capabilities and the FIPS/NIAP processes are very expensive for vendors and time-consuming, meaning extensive delays in getting secure products for DoD implementations. With DoD’s recently reduction of this IPSec requirement for switches and routers, this concern is reduced somewhat for the network backbone, but it is still a concern for IPv6 deployment.
Another issue is that upgrades are required for most servers to support the 64-bit bus speed required for Longhorn. NETCOM has proactively mandated that future server purchases must be 64-bit, but the bulk of current servers are only 32-bit.
Finally, the issue of addressing policies is not yet defined for DoD and the Army. A pilot implementation could proceed with temporary IPv6 addresses, but unless an addressing plan is defined, implementers risk wasting a great deal of time and effort in renumbering and restructuring a pilot implementation when the addressing plans are finalized.
Implementing IPv6 on an Army post requires many more components than just IPv6-enabling core elements. Besides the switches, implementers need to be concerned with server and client operating systems, network scanning and vulnerability analysis tools, addressing plans, policies and training. Commercial products for these aspects are lacking in IPv6 development, so conducting pilots at this time is very difficult.
DoD needs to continue to encourage industry to develop IPv6 products. DITO should publish a mandate now requiring APL usage at some future date and encouraging vendors to submit their products for APL testing. Army program managers need to pressure vendors to develop IPv6 capabilities now in their products and applications and pursue testing, at places like the TIC, to confirm that they will work in the Army secure dual-stack environment. ♦
