|
|
|
|
| DoD Acquisitions Guidance for IPv6 Products
The Internet Engineering Task Force (IETF) developed the next-generation Internet Protocol version 6 (IPv6) to overcome fundamental limitations of IPv4 by expanding available address space, improving routing support, enhancing end-to-end security, providing new enhancements to quality of service and easing the burdens of system administration. Both the DoD and the U.S. Federal Government have mandated a transition to "IPv6 Capable" networks by 2008. The "core" standards for all IPv6 devices are well proven and understood. These standards are generally defined as the IPv6 Protocol Specification [RFC 2460], Neighbor Discovery for IPv6 [RFC 2461], IPv6 Stateless Address Auto-configuration [RFC 2462], Internet Control Message Protocol for IPv6 (ICMPv6) [RFC 2463], and Path Maximum Transmission Unit Discovery [RFC 1981], which are all well enough understood that they are being promoted to "Internet standards" by the IETF. The application of other IPv6-related standards is less clear. Without clear guidance, it has been difficult to establish and implement effective "IPv6 Capable" product standards, a condition that impacts consumers such as the DoD and other US Federal agencies that require formal specifications in their acquisitions process. A DoD Program Manager (PM) often specifies system and component requirements several years before a custom system is built, accepted, and fielded. If incorrect or incomplete requirements are used, it is usually difficult and expensive to correct later in the acquisitions cycle. SRI is teamed with the CERDEC Space and Terrestrial Communications Directorate (S&TCD) Next Generation Networks Division at Fort Monmouth to support PMs like the Army's Product Manager for Common Hardware/Software (PM CHS) to help them meet the DoD mandate to integrate IPv6 into their products. CHS is a major vendor that distributes ruggedized and standard commercial IT components to operational users and system integrators in the Army, other DoD components, Homeland Security, and other U.S. Federal agencies. One of the first questions CHS engineers asked us was, "What does IPv6-capable really mean?" The engineers at the PM office needed simple guidance on how to meet requirements for "IPv6 Capable" components to ensure interoperability. S&TCD and SRI engineers assessed available DoD guidance and commercial standards, but couldn't find a published "standard" that was concise, applicable to all of the different classes of IT equipment in the CHS catalog, implementable and easily testable. S&TCD and SRI engineers immediately began working with the Army technical leadership, DISA and the DoD IPv6 Transition Office to develop a unified IPv6 product profile. S&TCD and SRI engineers have held meetings to discuss product profile development with the DoD IPv6 Standards Working Group, DoD IPv6 Transition Office, Office of the Secretary of Defense (OSD), representatives of the component services (Army, Navy, Air Force and Marines), and the DoD Joint Interoperability Test Command (JITC) personnel who must test and certify IPv6 conformance. This work lead to a draft of IPv6 "Product Profiles" developed for PM CHS as guidance on meeting DoD requirements and commercial standards for various IPv6 products. The profile defines common IPv6 requirements for all classes of equipment and specific requirements by functional areas for workstations, laptops, routers, servers, etc. As an example, the requirements from many IETF RFCs are split so that a profile for a workstation PC only shows the relevant requirements for workstations and does not show requirements for a router or server. To create one common DoD-wide IPv6 product profile, we leveraged our work from CERDEC S&TCD Next Generation Network Division and are participating in an ongoing DISA effort to define a "Product Profile for IPv6 Capable Products" that will provide guidance on IPv6 functions and services to be implemented for specific classes of equipment. The product profile was designed to be consistent with the following requirements documents:
To support this standard development activity, we have consulted with various other subject matter experts on IPv6 and product standards, including members of The Open Group Grid Enterprise Service Forum, members of the IPv6 Forum and its North American IPv6 Task Force (NAv6TF), University of New Hampshire IOL test lab personnel who support IPv6 Ready Logo testing, the DoD Joint Interoperability Test Center (JITC) IPv6 certification team and many product vendors. We are reaching out to as many parties as possible to widely coordinate requirements so that the guidance we produce will "get it right" the first time. Our hope is that this effort will lead to industry-common IPv6 product profile guidance similar to the Single UNIX Specification v3 or the Common Operating Environment (COE). This guidance should help organizations develop clear IPv6 requirements for product development, certification and acquisitions. We realize that this product profile development process is only a small part of a larger effort by Government and Industry bodies to help assure that IT products are developed and tested to a common standard in accordance with approved procedures. With IPv6 in its introductory stages, it is vital to ensure that IPv6 products are built to a common high standard in order to deliver the promised benefits of next-generation networks. IPv4 was adopted in various increments over the years without much industry self-regulation or outside regulation. Many good ideas for IPv4 were proven in laboratories, but were not widely deployed throughout the Internet. With the IPv6 transition, we have an opportunity to incorporate many
of those ideas into our networks to create a more capable Internet infrastructure
as the "plumbing" for tomorrow's advanced applications
and network services. We hope that having well-defined IPv6 product profile
guidance will encourage industry self-regulation and increase the adoption
of IPv6. Like many network engineers, we are ready for the full IPv6 transition
so we can start engineering the networks, services and applications of
tomorrow. About the author:
|
|
|
