USGv6 Version 1

Frequently Asked Questions (FAQ)

1)  Where can I get a copy of the USGv6 profile and related materials?

All USGv6 profile and test program materials can be found through the http://www.antd.nist.gov/usgv6/ web site, including the current version of the USGv6 profile.

2)  How do I ask a question or submit a comment about the USGv6 profile?

Simply send your question or comment to sp500-267-comments@antd.nist.gov.  You will receive an email response and, if the question is thought to be of a general enough nature, we will include it (anonymously) here for the benefit of others.

3)  What is the purpose, scope and applicability of the USGv6 profile?

For a detailed explanation refer to the following sections of the USGv6 profile: Executive Summary, 1.0 Introduction, 1.1 Purpose and Scope, 1.2 Audience.

Summarizing the above, the USGv6 profile is a recommended acquisition guide for IPv6 capabilities in common network products.  It is meant as a strategic planning guide for USG IT acquisitions to help ensure the completeness, correctness, interoperability and security of early IPv6 product offerings so as to protect early USG investments in the technology.

As published, the USGv6 profile is simply a recommendation from NIST.  The USGv6 profile and corresponding test program aim to provide a technical basis upon which agency specific or USG wide policies and plans can be defined, but on its own, NIST SP-500-267 does not embody policy.

In general, the applicability of the NIST information technology recommendations is limited to USG IT systems that are not classified as national security systems (see NIST SP 800-59 Guideline for Identifying an Information System as A National Security System).  Having said that, it is also common for entities outside the USG to adopt and use our recommendations in part or in their entirety in their own processes.  To the extent this profile is of value to other communities, we welcome its broader use.

4)  Why is the USGv6 profile distinct from the IETF Node Requirements summary, the DoD IPv6 profile, and the IPv6 Forum IPv6 Ready Logo program?

Prior to the development of the USGv6 profile and test program we surveyed all IPv6 standards, profiling and test programs that we were aware of.  Certainly our initial goal was to adopt any existing program that we felt could serve the general needs of the USG acquisition and deployment plans that we were asked to support.  As noted in the Executive Summary, clearly the proliferation of divergent profiling and standards efforts is something to be avoided in general.  Having said that our initial survey of existing programs did not find an existing program well suited to the general USG IPv6 adoption plans we were asked to support.  

All profile and testing efforts are tailored to particular usage goals, scopes of applicability, user/constituent bases, time horizons, governance processes and specification techniques.  Question 3 above addresses the first three issues with respect to the USGv6 profile.  In terms of time horizons, the USGv6 profile is meant to be a strategic planning document that provides a means of communicating forward looking requirements between USG IT system designers/implementers and the IPv6 product industry.  The USGv6 profile is designed to express user requirements for a 24 to 36 month horizon.  This “lead time” was purposefully chosen to serve typical USG IT planning and budgeting horizons and product development cycles in the industry.  See section 1.4, profile Life Cycles and Change Management, for a full explanation of the rationale for these time horizons and their implementation mechanisms within the specification.

5)  How does the USGv6 profile relate to these other IPv6 profiling efforts?

Each of the other profiling efforts mentioned above (and other international efforts) differs in one or more of their basic attributes.  The fact that profiling and test programs (if available) differ are precisely because the specific programs are tailored to best serve differing usage goals, scopes of applicability, user/constituent bases, time horizons, and governance processes.  A general summary of some of the ways in which the efforts differ include:

a)      IETF Node Requirements RFC4294 IPv6 Node Requirements specification attempts to summarize the IPv6 requirements published in other IETF specifications so as to define the common functionality required for both IPv6 hosts and routers.  As such the Informational specification captures the current view of the minimal mandatory (MUSTs) IPv6 requirements for all conceivable types of devices (i.e., IPv6 nodes) and usage scenarios.   Given its broad scope and immediate applicability RFC4294 is very conservative in its definition of requirements, as is appropriate for a base standard specification.  The form and format of RFC4294 is tailored to IPv6 vendors and serves as something of an implementer’s roadmap and summary of other core IPv6 specifications.

Given its purpose, the IETF IPv6 Node Requirements document is not particularly well suited to serve as an acquisition guide for users.  The specification does not provide guidance or documentation mechanisms to easily enable the selection and specification of user requirements for IPv6 capabilities that are optional in the base specification.  In general the IETF does not involve itself in the definition of product test and certification programs, and as a result, there is nothing that the USGv6 test program could leverage directly from the IETF.

b)      DoD IPv6 profile – The DoD IPv6 Standard profiles For IPv6 Capable Products is an ongoing effort within the Department of Defense to define an acquisition profile and product test program for use by the DoD in implementing their IPv6 adoption plans.  The DoD IPv6 profile is developed in accordance with the processes of the DoD Information Technology Standards Registry (DISR) and the corresponding test program is implemented under the auspices of the Joint Interoperability Test Command (JITC).  The DoD profile and test program has been operational since 2006 and the profile is in its 3rd iteration.

From the beginning of the civilian USG IPv6 profiling effort there has been strong collaboration and synergy with the DoD IPv6 effort.  Given that the profiles share similar usage goals, and generally similar scopes of application and user bases, the profiles have achieved a significant degree of technical convergence.  The development cycle of version 1 of the USG profile overlapped that of version 3 of the DoD profile.  These most recent versions of each profile have undergone several rounds of harmonization and convergence within the respective development teams.  The end result is that version 3.0 of the DoD IPv6 profile and version 1.0 of the USG IPv6 profile are tightly aligned from a technical perspective. The only remaining differences between the two are minor in the sense that (a) they will not cause interoperability issues between the profiles, or (b) do not preclude a single implementation from meeting both requirements simultaneously.  In many cases the remaining technical differences are transient conditions, in which one profile adopted a requirement one revision earlier than the other (i.e., a requirement that is a MUST in one and a SHOULD+ in the other).  The following notes a few of the differences and examines their origins and potential future harmonization:

                                            i.             Scopes of Applicability – While both profiles share the same general target audiences (i.e. acquisition officials, systems designers / integrators and IPv6 product vendors) and usage goals (i.e., providing the means to convey IPv6 technical requirements between these groups), their scopes of applicability are somewhat different.  The USGv6 profile, as published as a NIST SP-500-267, only provides recommendations for IT systems that are not identified as national security systems.  The DoD profile has a scope of applicability that explicitly includes national security systems.  This difference in scope of applicability manifests itself in some technical differences in security requirements and testing programs for network security devices.  These differences are an inherent factor of the different scopes of applicability of the respective efforts.

                                          ii.             Life Cycle Management – The latest versions of both profiles have adopted the same approach to the specification and evolution of forward looking requirements.  This is a significant benefit to the industry in that we have established common techniques and time horizons for the specification and enforcement of forward looking requirements and have synchronized our planned profile revision cycles.

While these issues have been harmonized going forward, the DoD IPv6 profile is on its 3rd version and has been in effect for over two years.  As a result, the current DoD profile must address certain requirements for compatibility with, and evolution of, products that were compliant to previous versions.  While this is of course an issue that the USG profile will have to deal with also as soon as its second version is published, it is not an issue that must be faced with version 1.  In summary, this is an area that is well harmonized going forward; in the current versions of the profiles, the DoD specification has some requirements that derive from evolution/compatibility requirements that do not exist for version 1 of the USG profile.

                                        iii.             Information Assurance / Network Protection Devices Requirements – The two profiling efforts take a somewhat different approach to the specification of the capability requirements for network security devices (e.g., firewalls, intrusion detection / prevention systems, network security gateways, etc.).  For the USGv6 profile, there was a perceived immediate need for a public specification and open test program for IPv6 enabled firewalls, and intrusion detection systems.  Given that initial USGv6 deployment mandates required connecting enterprise infrastructures to external networks and that no public specification of IPv6 network protection devices existed, the USGv6 profile defined its own technical requirements in these areas (based upon similar IPv4 industry and DoD requirements).

The DoD profile does not embody specific IPv6 Information Assurance functions but instead refers to previously established IA device policies and requirements in this area and emerging DoD IPv6 information assurance test plans.  To the extent that these specifications become public in the future, requirements in these areas can be further harmonized.

                                        iv.             Product Classes and Device Types – The USG and DoD IPv6 profile specifications take a somewhat different approach to documenting the sets of unique IPv6 requirements that distinct classes of products must implement.  The DoD profile explicitly identifies several named product classes (host/workstation, network appliance, advanced server, router, layer 3 switch and IA device) along with specific conditional capabilities for each.  The USG profile only distinguishes requirements based upon the device types recognized in the IETF specifications (hosts and routers) but provides a set of explicit configuration options for each device type.  The USG profile stops short of grouping and naming specific subsets of these configuration options into product classes but instead leaves that for specific procurement specifications or subsequent profile usage guidance documents.

Beyond the specification mechanisms, one could examine if it is possible to select sets of configuration options under the USGv6 Host profile to instantiate requirements equivalent to each of the DoD host product classes and similarly for routers and network security devices.  In general, this is possible with all classes of host and router requirements with the following caveats.  The DoD profile product classes for network appliances and layer 3 switches currently do not include some capabilities required by the minimal mandatory USGv6 Host and Router requirements.  The differences lie in current lack of IP security (IPsec) requirements in both DoD product classes and the current lack of management and quality of service (QoS) requirements in the layer 3 switch class.  In each of these cases, the DoD profile indicates (SHOULD+) that the missing requirements will be added in the next (or future) versions of the profile and thus we feel these differences are transients and not of long term significance.  

                                          v.              Testing Programs – The DoD IPv6 profile has been in effect since 2006 and the JITC IPv6 test program has been operational and testing and certifying IPv6 products for inclusion in the Approved Products List.  The DoD test program is documented in DoD IPv6 Generic Test Plan (GTP) and consists of 1st party conformance testing using a variety of commercial IPv6 test suites and 3rd party interoperability testing at DoD labs using environments that simulate specific DoD network architectures (i.e., the DISN IP Core network). 

The USGv6 Test program is under development and is not expected to be operational for at least 12 months following final publication of the profile.  The Compliance section of the USGv6 profile describes the general attributes of the program.  As planned the USGv6 program will be an open test program enabling participation by a variety of formally accredited test laboratories (1st, 2nd and 3rd party labs) conducting standardized conformance and interoperability tests.  To ensure the viability of mutual recognition of results (i.e., one-stop testing), the program will be based upon public, consensus test specifications and a program of laboratory accreditation.   Rather than maintain a monolithic register of qualified products, the program will rely on vendors’ self declarations of tested conformance and interoperability.  Such self declarations must be traceable to open standardized tests conducted in accredited laboratories.

The USGv6 test program is leveraging the best of the DoD test program and that of the international IPv6Ready Logo program (see below) to establish its testing infrastructure.  While the form of the two testing programs may be somewhat different, it is certainly envisioned that any lab can become an accredited test lab for the USGv6 test program, including those labs currently implementing the DoD program.  Thus, one-stop testing will remain feasible even if some of the technical details of the test regimes remain distinct.  

Of course, the DoD IPv6 test program is currently operational and the USGv6 test program is only in development.  Once both are operational, it is a recognized goal to minimize the technical and procedural differences in the programs while still supporting any unique program requirements.

In summary, the USG and DoD IPv6 profiling efforts have achieved significant convergence already over the course of the development of their current versions.  In terms of technical requirements for IPv6 capabilities in hosts and routers, there are only a few differences between the two profiles and most are transient differences (i.e., a requirement made mandatory in one that will be mandatory in the other in the next version, etc).  In the few instances where requirements are out-of-phase, they typically reflect requirements or constraints that are inherent from their differing scopes of applicability and/or their supporting processes and programs (i.e., waiting to mandate a requirement until appropriate testing is available, etc.).

c)      IPv6 Ready Logo – The international IPv6 Forum has established an IPv6 Ready Logo program for IPv6 conformance and interoperability testing.  The IPv6 Ready Logo program has been operational since 2003 and has gone through two significant revisions (Phase-1 and Phase-2) and continues to add testing capabilities for service/protocol specific logos today.  The program is managed by a committee of IPv6 Forum members (mainly vendors and test labs) from around the world that include the University of new Hampshire Interoperability Testing Lab (USA), members from the TAHI project (Japan), IRISA (France), ETSI IPv6 Plugtests (Europe), TTA (Korea), BII (China), and CHT-TL(Taiwan).

The IPv6 Ready program does not have explicit standards profile specifications; instead, requirements for IPv6 Hosts and Routers are defined by a series of published conformance and interoperability test suites that comprise each logo Phase.  These test suites are publicly reviewed and implemented in multiple test tools (both proprietary and public domain).  The IPv6 Logo committee works to maintain the technical harmonization of the testing services of its participating labs around the world so as to permit the mutual recognition of results.  The IPv6 Ready Logo program maintains a registry of products that have successfully passed testing (Phase-2 Approved Product List).

There is significant overlap between the IPv6 capabilities addressed in Phase-2 of the IPv6 Ready Logo program and those of the USGv6 profile.  The testing infrastructure (i.e., public test specifications, public domain and proprietary test tools, harmonized international network of test labs) associated with the IPv6 Ready Logo program has many attributes in common with the objectives of the USGv6 Test Program and represents a significant existing resource to build upon.  For these reasons, NIST has established MOUs with IPv6 Forum members to adopt the IPv6 Ready Logo test specifications as the initial basis for the USGv6 test program and to agree to maintain compatibility between the two programs going forward.

Over the course of the next year, NIST will work with IPv6 Ready committee members to adapt existing Logo tests to address the specifics of the USGv6 profile and to fill any testing gaps that remain uncovered.  As part of this collaboration, NIST and Logo committee members will establish a process by which to ensure that future test suites and methods remain coordinated.

6)  How will these profile / test efforts converge in the future?

As noted above, with the first versions of the profile and test programs the USGv6 program will have already achieved significant convergence with both the DoD IPv6 program and that of the IPv6 Forum.  While it is too soon to predict how future revisions of the USGv6 effort will evolve, the program remains committed to the harmonization and convergence of these efforts into broader, international collaborative user/vendor profiling and testing initiatives in which the technical and process requirements of the USG can be fully accommodated.  The goal will always be to harmonize the USG capability and testing requirements with those of other signification national and international efforts until we achieve the broadest possible program that addresses the needs of the USG as an IT consumer and minimizes the burden on the vendor community.

The next near term goal along this path will be the completion and operation of the USGv6 Test Program.  Through dialog with industry in multiple public meetings and public comment periods, we have heard, and are responding to, industry’s request for a flexible test program that supports multiple models of testing (1st, 2nd and 3rd party), open and publicly reviewed test methods and suites, and a laboratory accreditation process that will enable one-stop testing and mutual recognition of test results, not only within the USG but internationally as well.  The test program we are developing in collaboration with the IPv6 Ready Logo program will embody these goals and provide vendors the flexibility and economies that they requested in a testing program, while affording USG system planners and acquisition authorities the confidence they need in product test results.

7)  Why are there only 3 “Device Types” in the USGv6 profile?

For a detailed explanation refer to the following sections of the USGv6 profile: 1.3 profile Structure and Conventions, 3 Host profile, 4 Router profile, 5 Network Protection Device profile, and Appendix A profile Usage Guidance and Examples.

In general, such questions are indicative of some confusion between the use of the notion of “device types” to distinguish and organize sets of requirements within the profile and the notion of “product classes” to describe typical bundlings of capabilities in distinct consumer products.

In general, base IETF IPv6 technical specifications only differentiate requirements based upon two types of nodes; Hosts and Routers.  The USG profile follows the IETF (e.g. RFC4294 IPv6 Node Requirements) and IPv6 Ready profiling efforts by maintaining this taxonomy as the primary discriminator among sets of technical requirements.  To address the typical variability in feature sets among difference classes or vendors of products, the USGv6 profile provides a set of explicit configuration options for each device type.  The USG profile stops short of grouping specific subsets of configuration option selections into named product classes but instead leaves that for specific procurement specifications or subsequent profile usage guidance documents.  Refer to Appendix A profile Usage Guidance and Examples for examples of how to use configuration options in each device type to instantiate requirements for a broad range of product classes.

That explains Host and Router device types in the USGv6 profile; it does not explain the Network Protection Device (NPD) type.  Due to the lack of public specifications of technical capability requirements for network security devices such as firewalls, intrusion detection systems, etc., the USGv6 profile provides its own.  The USGv6 NPD requirements only focus on the IPv6-specific network security capabilities.  Given that such devices sometimes behave in non-standard ways (omitting or altering protocol functions for the sake of security) with respect to normal Host / Router requirements, we do not attempt to specify the basic IPv6 protocol capabilities of NPDs.  Refer to section 6 Network Protection Device Requirements for a detailed explanation of NDP specifications.

8)  What is the purpose of the Node Requirements Table?

For a detailed explanation refer to the following sections of the USGv6 profile: 1.3 profile Structure and Conventions and 8 Node Requirements Table.

In short, the Node Requirements Table (NRT) is meant to be the normative specification of requirements for the USGv6 profile.  The NRT, when indexed by device type and a specific set of selected configuration options, enumerates the normative requirements for implementation of IETF RFCs and, when necessary, specific sub-clauses and additional requirements.

The text in the profile in section 6 only serves as explanatory support for the requirements as expressed in the NRT.  Note that Network Protection Devices are a special case, in that the profile itself contains the base specification of requirements.  Here the NRT refers to specific aspects of the NPD specification in section 6.12.

9)  Does the requirement for IPsec in every node imply that every node must contain a FIPS-140 compliant crypto module?

The scope of the USGv6 profile and claims of conformance to it are strictly limited to the definition of IPv6 capabilities in networking products.  If used as a basis for acquisitions, the USGv6 profile should not modify or affect any other requirements or regulations that would otherwise apply to the acquisition.

The protections provided by IPsec and the protection that IKE provides to its own traffic require the use of cryptographic algorithms, which include encryption algorithms (to provide confidentiality), MACs or Message Authentication Codes (to provide integrity protection), and PRFs or Pseudo-Random Functions (to generate secret keys and other values used within the IPsec protocols).  Users of this profile should consult the scope and applicability statements of the most recent revision of FIPS 140 Security Requirements for Cryptographic Modules to determine if additional procurement requirements apply to the specific intended use of cryptographic algorithms required by IPv6 IPsec and IKE implementations.  While such additional requirements may apply to a given procurement, they are outside the scope of this profile and its definitions of compliance.