HHS Policy For The Transition To Internet Protocol Version 6 (Ipv6)

Document #: HHS-OCIO-OES-2021-08-004
Version #: 1.0
Last Reviewed: 08/2021
Next Review: 08/2023
Owner: OCIO/OES
Approved By: Janet Vogel, HHS CIO (Acting)

Table of Contents

  1. Nature of Changes
  2. Purpose
  3. Background
  4. Scope
  5. Authorities
  6. Policy
  7. Roles and Responsibilities
  8. Information and Assistance
  9. Effective Date and Implementation
  10. Approval

Appendix A: Procedures

Appendix B: Standards

Appendix C: Guidance

Appendix D: Forms and Templates

Appendix E: List of References

Glossary and Acronyms

1. Nature of Changes

This is the first issuance of the U.S. Department of Health and Human Services (HHS) Policy for the Transition to the Internet Protocol Version 6 (IPv6), (hereinafter referred to as, Policy).

2. Purpose

This Policy provides the guidance to which the Department of Health and Human Services (HHS) Operating Divisions (OpDivs) and Staff Divisions (StaffDivs) must follow to meet the requirements and milestones laid out in the Office of Management and Budget (OMB) Memorandum 21-07, Completing the Transition to Internet Protocol Version 6 (IPv6)1 (hereinafter referred to as M-21-07). The OMB memorandum defines the underlying directives for completing the operational deployment of IPv6 across all Federal information systems and services, and helps HHS and agencies overcome barriers that impede them from migrating to IPv6-only network environments. Migrating to an IPv6-only environment will enable HHS to align itself with the Federal government's strategic intent to deliver its information services, operate its networks, and access the services of others using only IPv6 capabilities.

Among the many benefits to transitioning, the IPv6 protocol can handle packets more efficiently, improve performance and increase security. It enables Internet Service Providers (ISPs) to reduce the size of their routing tables by making them more hierarchical. There is no need for Network Address Translation (NAT).

3. Background

IPv6 is the next-generation Internet Protocol (IP), designed to replace version 4 (IPv4) that has been in use since 1983. IP addresses are the globally unique numeric identifiers necessary to distinguish individual entities that communicate over the Internet. The global demand for IP addresses has grown exponentially with the ever-increasing number of users, devices, and virtual entities connecting to the Internet, resulting in the exhaustion of readily available IPv4 addresses in all regions of the world.

Over time, numerous technical and economic stop-gap measures have been developed in an attempt to extend the usable lifetime of IPv4, but all of these measures add cost and complexity to network infrastructure and raise significant technical and economic barriers to innovation. It is widely recognized that full transition to IPv6 is the only viable and sustainable option to ensure future growth and innovation in Internet technology and services. It is essential for the Federal government to consistently expand and enhance its strategic commitment to the transition to IPv6 in order to keep pace with and capitalize on industry trends. Building on previous initiatives which date back to 2003, the Federal government remains committed to completing this transition.

The Federal government's IPv6 initiative has served as a vital catalyst, fostering commercial development and adoption of IPv6 technology. In the last five years, IPv6 momentum in industry has dramatically increased, with large IPv6 commercial deployments in many business sectors driven by reducing cost, decreasing complexity, improving security and eliminating barriers to innovation in networked information systems. Several large network operators, software vendors, service providers, enterprises, state governments, and foreign governments have deployed significant IPv6 infrastructures. In fact, many of these organizations have migrated, or are planning to migrate, to "IPv6-only" infrastructures to reduce operational concerns associated with maintaining two distinct networking regimes.

This Policy communicates OMB M-21-07 requirements for HHS and its OpDivs and StaffDivs to complete the operational deployment of IPv6 across all HHS information systems and services and helps HHS agencies overcome barriers that impede them from migrating to IPv6-only network environments. With the establishment of this Policy, it is HHS' commitment to support the Federal government's strategic intent to deliver its information services, operate its networks, and access the services of others using only IPv6.2 This Policy in conjunction with supporting processes, procedures and templates is expected to support HHS wide services and each OpDiv's and StaffDiv's transition to IPv6.

4. Scope

This Policy applies to the Department and to all HHS OpDivs and StaffDivs' information systems and all other networked assets interfacing with or conducting business for, and on behalf of, HHS, whether directly or through contractual relationships. All organizations collecting, maintaining, using, or operating information systems on behalf of HHS, are subject to this Policy's stipulations.

This Policy requires all new IT procurements using Internet Protocol, to the maximum extent practicable, include IPv6-capable3 products and services. Proactive integration of IPv6 requirements into Federal contracts may reduce future costs and complexity of transition by ensuring that Federal applications can operate in an IPv6 environment without costly upgrades. Any exceptions to the use of IPv6 require the HHS CIO to give advance, written approval.

This Policy does not apply to any network or system that processes, stores, or transmits foreign intelligence or national security information under the cognizance of the Special Assistant to the Secretary (National Security) pursuant to Executive Order (E.O.) 123334 , United States Intelligence Activities, or subsequent orders. The Special Assistant to the Secretary (National Security) is the point of contact (POC) for issuing Information Technology (IT) security and privacy policy and guidance for these systems.

OpDivs must follow this Policy, or create their own which cannot be less restrictive or comprehensive and must be compliant with all requirements contained in this Policy.

This Policy does not supersede any applicable law or higher-level agency directive or policy guidance.

5. Authorities

Authorities include:

Legislation, Federal Regulations and Executive Orders

  • Executive order 14028: Improving the Nation's Cybersecurity. 12May. 2021
  • Federal Acquisition Regulation (FAR) Part 11, Describing Agency Needs
  • FAR Part 12, Acquisition of Commercial Items
  • FAR Part 39, Acquisition of Information Technology
  • FAR Part 7, Acquisition Planning

Federal Guidance

  • NIST Special Publication (SP) 800-119, Guidelines for the Secure Deployment of IPv6, December 2010
  • NIST SP 500- 267B Revision 1, USGv6 Profile
  • NIST SP 500- 267B Revision 1s, USGv6 Capabilities Table
  • NIST SP 500- 281A Revision 1, USGv6 Test Program Guide
  • NIST SP 500- 281A Revision 1s, USGv6 Suppliers Declaration of Conformity
  • NIST SP 500-267A Revision 1, NIST IPv6 Profile
  • NIST SP 500-267A Revision 1s, NISTv6 Capabilities Table
  • NIST SP 500-281 B Revision 1, USGv6 Test Methods: General Description and Validation
  • NIST SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
  • OMB, Circular No- A-130, Managing Information as a Strategic Resource, July 28, 2016
  • OMB, Memorandum for Chief Information Officers of Executive Departments and Agencies, Transition to IPv6, September 28, 2010
  • OMB, Memorandum, M-05-22, Transition Planning for Internet Protocol Version 6 (IPv6), August 2, 2005
  • OMB, Memorandum, M-21-07, Completing the Transition to Internet Protocol Version 6 (IPv6), November 19, 2020

Departmental Policy and Guidance

  • HHS Policy for Information Technology Acquisition Reviews (ITAR), June 2020
  • HHS Policy for Information Technology Asset Management (ITAM), August 2020
  • HHS Policy for Information Technology Procurements - Security And Privacy Language, March 2021
  • HHS Policy for IT System Inventory Management, December 2020

Links to the authorities cited above can be found at the following main websites: Executive Orders, FAR, NIST Publications, OMB and Departmental Policy and Guidance. For additional references regarding IPv6, reference Appendix E: List of References

6. Policy

The Department and HHS OpDivs and StaffDivs must adhere to the requirements below for completing the operational transition to, and deployment of, IPv6 across all HHS information systems and services, and helps the Department overcome barriers that impede the migration to IPv6-only network environments. The strategic intent is for the Department to deliver its information services, operate its networks, and access the services of others using only IPv6-only environments when appropriate.

The technical, economic and security benefits of operating a single, modern, and scalable network infrastructure are the driving forces for the evolution towards IPv6-only in the private sector. To keep pace with and leverage this evolution in networking technology, HHS and its OpDivs and StaffDivs are required to:

  1. Designate a Department-wide IPv6 integrated project team (IPT) (including acquisition, policy, and technical members), and an associated governance structure, to effectively govern and enforce IPv6 efforts;
  2. Issue and make available on the Department's publicly accessible website, an Enterprise IPv6 policy. The Enterprise IPv6 policy must require that, no later than Fiscal Year (FY) 2023, all new networked information systems are IPv6-enabled5 at the time of deployment, and state the agency's strategic intent to phase out the use of IPv4 for all systems. For further detail into the IPv6 Implementation Schedule, reference Appendix A: Procedures;
  3. Identify opportunities for IPv6 pilots and complete at least one pilot of an IPv6-only-supported operational system by the end of FY 2021 and report the results of the pilot to OMB upon request;
  4. Develop an IPv6 implementation plan, and update the HHS IT Strategic Plan as appropriate, to update all networked information systems (and the IP-enabled assets associated with these systems) to fully enable native IPv66 operation. The plan will describe the agency transition process and include milestones, as detailed in Appendix A: Procedures. For guidance on phased deployment, reference Appendix C: Guidance;
  5. Collaborate with external partners to identify systems that interface with networked Federal information systems and develop plans to migrate all such network interfaces to the use of IPv6; and
  6. Complete the upgrade of public/external facing servers and services (e.g., web, email, DNS, and ISP services) and internal client applications that communicate with public Internet services and supporting enterprise networks to operationally use native IPv6.

6.1. Federal IPv6 Acquisition Requirements

In accordance with the Federal Acquisition Regulation (FAR) Part 11.002(g) which requires IPv6 compliant products be included in all information technology (IT) acquisitions using IP, and as defined by the National Institute of Standards and Technology (NIST) Special Publication (SP) 500-267 series, HHS and its OpDivs and StaffDivs are required to:

  1. Use the United States Government version 6 (USGv6) Profile to define agency or acquisition specific requirements for IPv6 capabilities when purchasing networked information technology and services. Going forward, this must include specifying the requirement for hardware and software to be capable of operating in an IPv6-only environment (reference Appendix C: Guidance);
  2. Require vendors to document compliance with such IPv6 requirement statements through the USGv6 Test Program; and
  3. Provide a process for the HHS Chief Information Officer to waive this requirement on a case-by-case basis when implementing IPv6 capabilities may pose an undue burden. In such cases, the purchasing authority must request documentation from vendors detailing explicit plans (e.g., timelines) to incorporate IPv6 capabilities to their offerings. For more information on the waiver process, reference Appendix A: Procedures.

This strategic acquisition approach enables natural technology refresh cycles to upgrade the installed base of networked IT products and services to be IPv6-capable7 . Doing so ensures that Federal IT systems are positioned to leverage the technical and economic benefits of IPv6 and enable Federal Chief Information Officers to eventually migrate to IPv6-only environments when appropriate.

6.2. Internet Engineering Task Force (IETF) Testing Requirements

To continue to protect IT investments in IPv6 technology, NIST will continue to issue periodic updates to the USGv6 Profile to incorporate the latest Internet Engineering Task Force (IETF)8 specifications relevant to IPv6 technology. Reference Appendix C: Guidance for more information on testing. Special emphasis must be placed on ensuring the inclusion of IPv6 security technologies and those network capabilities necessary to support other Federal initiatives such as Internet of Things (IoT), adoption of cloud-based shared services, advanced wireless communications, and software defined and virtualized networks.

The USGv6 Test Program will continue to provide government-wide conformance and general interoperability testing of commercial product offerings. This program will continue to be implemented by accredited external testing laboratories and continue to be coordinated, to the maximum extent possible, with existing industry driven test programs to minimize the burden on vendors. To avoid any unnecessary duplication of generic testing requirements, HHS and its OpDivs and StaffDivs are required to:

  1. Leverage the USGv6 Test Program for basic conformance and general interoperability testing of commercial products; and
  2. Ensure that agency or acquisition specific testing focus on specific systems integration, performance, and information assurance testing not covered in the USGv6 Test Program.

6.3. IPv6 Security Requirements

In addition to Federal guidance, industry guidance and best practices for the secure deployment of IPv6 have been well documented. While the knowledge base of how to secure IPv6 has matured significantly, the understanding of how IPv6 enables more efficient approaches to overall security is often overlooked. In order to help realize the security benefits across the Department, HHS and its OpDivs and StaffDivs are required to:

  1. Ensure that plans for full support for production IPv6 services are included in IT security plans, architectures and acquisitions;
  2. Ensure that all systems that support network operations or enterprise security services (e.g., identity and access management systems, firewalls and intrusion detection / protection systems, end-point security systems, security incident and event management systems, access control and policy enforcement systems, threat intelligence and reputation systems) are IPv6-capable and can operate in IPv6-only environments;
  3. Follow applicable Federal guidance and leverage industry best practices, as appropriate, for the secure deployment and operation of IPv6 networks; and
  4. Ensure that all security and privacy policy assessment, authorization and monitoring processes fully address the production use of IPv6 in Federal information systems.

Reference Appendix C: Guidance for more information on IPv6 deployment security considerations.

7. Roles and Responsibilities

7.1. HHS Chief Information Officer (CIO)

The HHS CIO, or designee, must:

  1. Establish the IPv6 Integrated Project Team (IPT) to coordinate with external partners and share information and best practices;
  2. Appoint an HHS IPv6 Transition Manager to lead the IPv6 IPT and represent HHS' IPv6 efforts with OMB and other Federal agencies;
  3. Ensure compliance and implementation of this Policy at the department-level;
  4. Ensure all applicable HHS OCIO policy, guidance, procedures, initiatives and best practices align with this Policy;
  5. Ensure the completion of the HHS IPv6 Implementation Plan;
  6. Ensure the HHS IT Strategic Plan is updated to align with the HHS IPv6 Implementation Plan;
  7. Ensure as part of the IT Acquisition Review (ITAR) Program that IPv6 requirements are addressed for OpDivs that do not have CIO delegated authority; and
  8. Act as the decisional authority over waivers of acquisitions of networked assets not capable of IPv6.

7.2. HHS Chief Information Security Officer (CISO)

The HHS CISO, or designee, must:

  1. Ensure cybersecurity policies, guidance, procedures, and best practices fully integrate IPv6 requirements into network operations and security services;
  2. Collaborate with the HHS Chief Enterprise Architect (CEA) to develop and implement the IPv6 Transition Pilot Program;
  3. Collaborate with the HHS CEA to ensure that hardware and software function within an IPv6-only environment by establishing product profiles for the IT hardware, software and services, as required;
  4. Collaborate with the IPv6 IPT regarding security and data protection efforts related to the IPv6 transition;
  5. Collaborate with the HHS CEA to ensure annual reconciliation of system inventories with considerations for IPv6 capability requirements; and
  6. Ensure IPv6 is implemented in accordance with guidance from NIST SP 800-119, Guidelines for Secure IPv6 Deployment.

7.3. HHS Chief Enterprise Architect (CEA)

The HHS CEA, or designee, must:

  1. Develop and manage the Policy;
  2. Collaborate with the HHS Vendor Management Office (VMO) to ensure IPv6 requirements are implemented into the IT Asset Management (ITAM) inventory and IT System inventory, as applicable;
  3. Collaborate with the HHS VMO and the IPv6 IPT, annually, to reconcile the ITAM inventories with IPv6 assets, as directed by OMB;
  4. Collaborate with the IPv6 IPT regarding IPv6 implementation and transition as required.
  5. Collaborate with the HHS CISO to develop and implement the IPv6 Transition Pilot Program;
  6. Collaborate with the HHS CISO to ensure that all hardware and software function within an IPv6-only environment, by establishing product profiles for the IT hardware, software, and services; 
  7. Collaborate with the HHS CISO to ensure annual reconciliation of system inventories with considerations for IPv6 capability requirements;
  8. Ensure networked assets are IPv6-enabled upon deployment; and
  9. Ensure networked assets are in compliance with the USGv6 Test Program.

7.4. HHS Chief Acquisition Officer (CAO)

The HHS CAO, or designee, must:

  1. Ensure all contract vehicles involving the acquisition of networked assets incorporate IPv6 capability requirements;
  2. Require vendors to document compliance with IPv6 requirement statements through the USGv6 Test Program;
  3. Identify, document, and report any acquisition which is not IPv6-capable, and submit waivers, when applicable; and
  4. Collaborate with the HHS VMO, the IPv6 IPT, the HHS CEA and vendors to ensure network services are IPv6-enabled at the time of deployment.

7.5. Chief Information Officer Council (CIOC)

The CIOC must identify opportunities to implement IPv6 programs that span across HHS and communicate back to the HHS IPv6 IPT.

7.6. Enterprise Architecture Review Board (EARB)

The EARB is a part of the HHS governance structure, serves as an expert advising body on IPv6 capabilities and configuration management, and collaborates with the HHS IPv6 IPT as necessary.

7.7. HHS Vendor Management Office (VMO)

The HHS VMO, or designee, must:

  1. Incorporate IPv6 hardware inventory management into the current ITAM inventory requirements, and track networked assets in accordance with this Policy, the HHS Policy for IT Asset Management (ITAM) and the HHS Policy for IT System Inventory Management;
  2. Validate compliance and implementation of this Policy at the vendor level
  3.  As part of the ITAM Data Call, in accordance with the HHS Policy for ITAM, request OpDiv and StaffDiv networked asset information specific to IPv6 capabilities to assist in identifying, justifying, and developing schedules to retire legacy networked assets while also transitioning those needs to IPv6-only assets;
  4. Collaborate with the HHS CEA, annually, to reconcile the hardware inventories with the IPv6 assets, as directed by OMB;
  5. Require vendors to document compliance with IPv6 requirement statements through the USGv6 Test Program; and
  6. Ensure IPv6 networked assets are enabled upon deployment.

7.8. HHS IPv6 Transition Manager

The HHS IPv6 Transition Manger, or designee, must:

  1. Build the necessary structures to champion and manage a successful adoption of IPv6 enabled services;
  2. Ensure compliance and implementation of this Policy;
  3. Lead the IPv6 IPT, coordinates with OpDivs and StaffDivs to share information and best practices;
  4. Lead the development of the HHS IPv6 Charter, Policy and Implementation Plan;
  5. Oversee an IPv6 Transition Pilot Program as a part of the IPv6 Implementation Plan, and report findings to OMB, upon request;
  6. Collaborate with the HHS cross-functional leadership team and critical partners, to include governance, operations and acquisitions, in support of the IPv6 Transition Program;
  7. Communicate the impact of IPv6 efforts within HHS to the Federal IPv6 Task Force and OMB; and
  8. Review and make recommendations to the HHS CIO for approval requests to waive IPv6 compliance requirements. The IPv6 Transition Manager will confirm the justification is valid and vendor documentation is in order, prior to submitting the form to the HHS CIO for approval.

7.9. HHS IPv6 Integrated Project Team (IPT)

The HHS IPv6 IPT members must:

  1. Provide oversight over HHS' transition to an IPv6-only environment;
  2. Build the necessary structures to champion and manage a successful adoption of IPv6 enabled services for their OpDiv/StaffDiv;
  3. Lead the IPv6 transition effort for their OpDiv/StaffDiv, coordinate with HHS and other OpDivs and StaffDivs to share information and best practices;
  4. Assist OpDivs with IPv6 implementation plan development and compliance;
  5. Coordinate with the HHS VMO to issue an annual data call for OpDiv and StaffDiv IPv6 asset inventory updates to assist in identifying, justifying, and developing schedules to retire legacy networked assets; and
  6. Collaborate with the HHS CEA and the VMO, annually, to reconcile the ITAM inventories with IPv6 assets, as directed by OMB.

7.10. OpDiv CIO

The OpDiv CIO, or designee, must:

  1. Ensure compliance and implementation of this Policy at the OpDiv level;
  2. Ensure all applicable OpDiv policy, guidance, procedures, initiatives and best practices align with this Policy;
  3. Oversee and ensure the reporting of IT hardware, software, and services in accordance with the HHS and the Department of Homeland Security;
  4. Collaborate with the organizational cross-functional leadership to include governance, operations, and acquisitions, in support of the IPv6 Transition Program to include all OpDiv critical partners; 
  5. Ensure all non-compliant IPv6 capable waiver requests for networked asset acquisitions are submitted for HHS CIO adjudication;
  6. In accordance with the Department strategy ensure the use of USGv6 profiles for all IP related procurements; and
  7. Ensure as part of the IT Acquisition Review (ITAR) Program that IPv6 requirements are addressed for OpDivs with CIO delegated authority.

7.11. OpDiv CISO

The OpDiv CISO, or designee, must:

  1. Ensure cybersecurity policies, guidance, procedures, and best practices fully integrate IPv6 requirements into network operations and security services;
  2. Collaborate with OpDiv Enterprise Architecture (EA) to report all IPv6 and IPv4 deployment and utilization levels within the organization to the Department;
  3. Collaborate with the OpDiv EA to ensure that hardware and software function within an IPv6-only environment by establishing product profiles for the IT hardware, software and services, as required; and
  4. Ensure IPv6 is implemented in accordance with guidance from NIST SP 800-119, Guidelines for Secure IPv6 Deployment.

7.12. OpDiv Enterprise Architecture (EA)

The OpDiv EA, or designee, must:

  1. Collaborate with the OpDiv CISO to share networked assets related information in accordance with this Policy, the HHS Policy for ITAM, and HHS Policy for IT System Inventory Management reporting requirements;
  2. Collaborate with the OpDiv CISO to ensure all hardware and software function within an IPv6-only environment, by establishing product profiles for the IT hardware, software and services; 
  3. Collaborate with the CAO, System Owners (SO) and Business Owners (BO) to ensure IPv6 capable networked assets are enabled at the time of deployment, in accordance with the IPv6 Implementation Plan;
  4. Collaborate with the SO and the BO to phase out and retire IPv4-only networked assets;
  5. Ensure networked assets are IPv6-enabled upon deployment;
  6. Identify, document, and report any acquisition which is not IPv6-capable, and submit waivers, when applicable;
  7. Ensure networked assets are in compliance with the USGv6 Test Program; and
  8. Ensure current and future solution designs, changes, and enhancements are compatible with IPv6 standards.

7.13. OpDiv CAO

The OpDiv CAO, or designee, must:

  1. Ensure all contract vehicles involving the acquisition of networked assets incorporate IPv6 capability requirements;
  2. Require vendors to document compliance with such IPv6 requirement statements through the USGv6 Test Program;
  3. Identify, document, and report any acquisition which is not IPv6-capable, and submit waivers, when applicable; and
  4. Collaborate with OpDiv EA, SO, BO, and vendors to ensure network services are IPv6-enabled at the time of deployment.

7.14. OpDiv Architecture Review Board (ARB)

The OpDiv ARB must:

  1. Serve as the expert advising body on IPv6 capabilities, configuration management, and oversight over the transition to an IPv6-only environment;
  2. Provide oversight over the transition to an IPv6-only environment; and
  3. Ensure current and future solution designs, changes, and enhancements are compatible with IPv6 standards.

7.15. System Owner (SO)

The SO, or designee, must:

  1. Develop and submit an IPv6 Implementation Plan;
  2. Ensure compliance and implementation of this Policy;
  3. Ensure all networked assets are properly registered, documented, and maintained;
  4. Implement commercial product testing for conformance and interoperability in accordance with the USGv6 Test Program;
  5. Transition IP-enabled assets, as necessary, to IPv6-only in accordance with OMB M-21-07 milestones;
  6. Collaborate with OpDiv CISO to ensure system testing focuses on system integration, performance, and information assurance;
  7. Collaborate with the CAO, BO and the OpDiv EA to ensure IPv6 capable networked assets are enabled at the time of deployment, in accordance with the IPv6 Implementation Plan;
  8. Collaborate with BO to identify and justify information systems that cannot be converted to use IPv6 and provide a schedule for replacing or retiring these systems; and
  9. Collaborate with the BO and the OpDiv EA to phase out and retire IPv4-only networked assets.

7.16. Business Owners (BO)

The BO, or designee, must:

  1. Collaborate with the SO to ensure all networked assets are properly registered, documented, and maintained;
  2. Ensure compliance and implementation of this Policy;
  3. Plan and request necessary funding to support the transition to IPv6;
  4. Collaborate with the CAO, SO and the OpDiv EA to ensure IPv6 capable; networked assets are enabled, in accordance with the IPv6 Implementation Plan;
  5. Collaborate with SO to identify and justify information systems that cannot be converted to use IPv6 and provide a schedule for replacing or retiring these systems; and
  6. Collaborate with the SO and the OpDiv EA to phase out and retire IPv4-only networked assets.

8. Information and Assistance

The HHS Chief Enterprise Architect (CEA) is responsible for the development and management of this Policy. Questions, comments, suggestions, and requests for information about this Policy should be directed to HHS_EA_Program@hhs.gov or to the IPv6 Integrate Project Team (IPT) at HHSIPv6IPT@hhs.gov.

9. Effective Date and Implementation

The effective date of this Policy is the date on which the Policy is approved. This Policy must be reviewed, at a minimum, every three (3) years from the approval date. The HHS CIO has the authority to grant a one (1) year extension of the Policy. To archive this Policy, approval must be granted, in writing, by the HHS CIO.

10. Approval

/S/

Janet Vogel, HHS CIO (Acting)

08/01/2021

Appendix A: Procedures

Please note that this appendix is subject to change at any time. The current version of this Policy will always reside in the OCIO Policy Library.

A1. IPv6 Transition Implementation Schedule

The IPv6 Implementation Schedule reflects the requirements and milestones, as directed by OMB M-21-07: Completing the Transition to IPv6.

Figure 1 – IPv6 Implementation Schedule

Figure 1 – IPv6 Implementation Schedule

By the end of Fiscal Year (FY) 2021, the IPv6 Integrated Project Team (IPT) is required to finalize and deliver the HHS IPv6 Implementation Plan to include details on updating all networked information systems to fully enable native IPv6 in coordination with other modernization initiatives and shared services for full IPv6 support. Additionally, the plan will outline IPv6 Pilot Program criteria to assist the Department and its OpDivs in identifying and deploying pilots of IPv6 only operational system, to include OMB reporting instructions and/or data calls.

  1. By the end of FY 2023, 20% of networked assets must be IPv6-only. This includes phasing out IPv4 networked assets, enabling IPv6 on existing systems that are capable, and ensuring new networked are IPv6-only upon deployment.
  2. By the end of FY 2024, 50% of networked assets must be IPv6-only. This includes the conditions mentioned above, as well as identifying networked assets that cannot be converted to IPv6, and then developing a schedule to replace or retire those assets.
  3. By the end of FY 2025, 80% of networked assets must be IPv6-only. This includes the conditions mentioned above, as well as justifying networked assets to remain IPv4, requesting waivers for those assets, and retiring assets, as applicable.

Annually, the IPv6 IPT may request a data call for OpDiv and StaffDiv IPv6 asset inventory updates. The IPv6 IPT, the HHS Chief EA, and the HHS VMO will then reconcile their asset inventories to assist in identifying, justifying, and developing schedules to retire legacy networked assets.

A2. IPv6 Implementation Plan

This appendix will be updated with IPv6 Implementation Plan when it is fully developed and approved by the HHS CIO; expected September 2021.

A3. IPv6 Risk Acceptance Waiver Process

On a case by case basis, the HHS CIO has the authority to waive the IPv6 transition implementation when an undue burden is posed upon the Department. In such cases, the purchasing authority must request documentation from vendors detailing explicit plans (e.g., timelines) to incorporate IPv6 capabilities to their offerings.

When no alternatives exist, and the vendor's IPv6 plans are in place, the appropriate authority is required to submit justification through the HHS Risk Acceptance Waiver Form, referenced at Appendix D: Forms and Templates, to the HHS IPv6 IPT, HHSIPv6IPT@hhs.gov and carbon copy HHS.Cybersecurity@HHS.gov, for review and clearance by the IPv6 Transition Manager. The IPv6 Transition Manager will confirm the justification is valid and vendor documentation is in order and submit the form to the HHS CIO for approval.

The HHS Risk Acceptance Waiver Form is not intended to waive adoption of an IPv6-only environment. Instead, an approved waiver will provide temporary authorization to proceed with the purchase of a legacy product while the agency explores contingency strategies to procure an IPv6-capable product in the future.

IPv6 Transition Waiver Justification:

  1. Specific justifications must detail why the IPv6 transition requirements should be delayed or will not apply. Please incorporate the following details to justify obtaining waiver approval. This information should include:
    • A brief explanation of the program, product, or project
    • The specifics of the current status of the effort
    • The procurement situation that highlighted the IPv6 issue
    • The impact immediate compliance would have on the program, product, or project
    • Justification for a waiver (why the IPv6 requirement does not apply or should be delayed)
    • Risks: Provide information on the areas (e.g. security aspects, etc.) affected and associated risks (with and without IPv6 integrated)  
    • Provide Roadmap and Schedule to become compliant
  2. It is required to submit vendor statements that acknowledge the vendor's awareness of the requirement to provide an IPv6-capable product in the future at no additional cost to the agency.

Appendix B: Standards

Please note that this appendix is subject to change at any time. The current version of this Policy will always reside in the OCIO Policy Library.

No standards are required to comply with this Policy.

Appendix C: Guidance

Please note that this appendix is subject to change at any time. The current version of this Policy will always reside in the OCIO Policy Library.

C1. Phased IPv6 Deployment

The basic assumption is that, for the foreseeable future, organizations will either operate dual stack networks or accommodate both IPv4 and IPv6 networking through other means. However, the eventual goal is to transition to an IPv6-only network to the maximum extent possible.

This section covers the deployment of IPv6. The IPv6 deployment should follow the NIST guidelines for a secure information system life cycle9 and should include the following stages:

  1. Initiation Phase
  2. Acquisition/Development Phase
  3. Implementation Phase
  4. Operations/Maintenance Phase
  5. Disposition Phase.

The framework calls for a phased approach10 or a gradual transition from IPv4 to IPv6. The use of a phased implementation will enable an organization to implement IPv6 with as little disruption to the current environment as possible. Existing users should be unaware of the new protocol until they require its use. The phased approach will minimize the effect on day-to-day operations. There are two main approaches to transition deployment:

  1. Pervasive IPv6 deployment
  2. Sparse IPv6 deployment.

In a pervasive approach, the organization enables dual (IPv4/IPv6) stack equipment rapidly throughout the entire enterprise. This scenario is appropriate when an organization has mostly new equipment that supports both IPv4 and IPv6. After the organization validates core services and translation mechanisms are functioning properly, IPv4 is disabled on all equipment, leaving an IPv6 dominant network.

Edge to core describes a sparse IPv6 deployment. In this approach, organizations enable groups or islands of IPv6 equipment in an IPv4 dominant network. After most of the edge devices transition to IPv6, the network core transitions to either dual stack or IPv6-only. A sparse IPv6 deployment requires supporting both IPv4 and IPv6 traffic throughout the duration of the deployment life cycle. This approach makes extensive use of IPv4/IPv6 and IPv6/IPv4 tunneling. This scenario is appropriate when an organization has a large installed base of older equipment or services that cannot transition to IPv6.

Software or applications may be more important than equipment when selecting a transition approach. Upgrades for hardware and embedded operating systems can be quicker than custom or off the shelf applications. The hardware vendors have been working towards IPv6 support for longer than application software vendors have. Many vendors may not be able or willing to upgrade software to support IPv6 and many organizations do not have the expertise in house to upgrade the code base. The more legacy applications and custom code an organization supports (either developed in house or highly customized off the shelf software) the greater the risk that the software will not support IPv6. Transition planners must address software in the approach to IPv6 transition.

The two main differences between an IPv6 pervasive deployment and an IPv6 sparse deployment are:

  1. The IPv6 pervasive deployment has a shorter lifecycle than an IPv6 sparse deployment.
  2. An IPv6 sparse deployment will take longer and make use of tunneling mechanisms.

Both deployment scenarios (IPv6 pervasive deployment and IPv6 sparse deployment) are covered by the same general deployment plan. All phases of the lifecycle are the same regardless of approach.

Organizations that are not yet deploying IPv6 globally should implement the following recommendations:

  1. Blocking all IPv6 traffic, native and tunneled, at the organization's firewall. Both incoming and outgoing traffic should be blocked.
  2. Disabling all IPv6-compatible ports, protocols and services on all software and hardware.
  3. Beginning to acquire familiarity and expertise with IPv6, through laboratory experimentation and/or limited pilot deployments.
  4. Making organization web servers, located outside of the organizational firewall, accessible via IPv6 connections. This will enable IPv6-only users to access the servers and aid the organization in acquiring familiarity with some aspects of IPv6 deployment.

C1.1. Initiation Phase

The initiation phase is concerned with requirements gathering. It is important for an organization to understand its current environment before deploying IPv6. By understanding the current environment, the correct transition approach can be selected, and an organization can ensure that it maintains security parity between its IPv4 and IPv6 environment.

An organization must also begin to plan for new IPv6 features. The transition to IPv6 gives an organization an opportunity to fix problems in its current environment. IPv6 addressing will allow more opportunities to aggregate addressing and simplify routing and access control rules if requirements are collected early.

One of the key tasks in the initiation phase is to conduct an extensive inventory of the IP equipment and services. The Internet Engineering Task Force's (IETF) Request for Comments (RFC) 4057, IPv6 Enterprise Network Scenarios, covers the types of questions that an organization needs to answer to plan a successful IPv6 transition. These questions are broken out by different scenarios, because each type of organization will have unique transition requirements.

What all organizations have in common are IPv4 assets that require transition to IPv6. In an effort to understand the transition requirements, an organization must perform an asset discovery. While it is feasible that asset discovery could populate a configuration management database (CMDB), the primary purpose of asset discovery in an IPv6 transition plan is to gather transition requirements.

Transition requirements determine which assets will transition to IPv6, the order assets will transition, the transition methods selected, and the security controls implemented. The type of information that can help determine if an asset or service will transition to IPv6, require some other coexistence mechanism, or be replaced include system security categorization, operating system and applications, lifecycle replacement, and dependencies.

Each information system should designate a security categorization. FIPS 199, Standards for Security Categorization of Federal Information and Information Systems,11 is the document that guides an organization in the determination of a system's category. The category of the system determines which security controls must be implemented to protect the system appropriately. The controls implemented for IPv6 will be similar to the controls implemented for IPv4.

Most organizations have a large installed base of legacy equipment and applications. Many legacy systems cannot support IPv6. IPv6 is widely supported by network equipment vendors, and desktop systems and productivity applications generally support IPv6. Firewall and IDS implementations also are beginning to have good support for IPv6. Where organizations have difficulties supporting IPv6 is with management applications, embedded systems, and legacy applications. Legacy applications that implement network protocols or process network addresses were not written to support IP agnostic addressing (IPv4/IPv6). There were no requirements for IPv6 address handling. These applications' code assumes 32-bit addressing. The application code logic and storage allocations work with IPv4 addressing. It will take a long time to update legacy applications to support IPv6. Applications that cannot support IPv6 require the evaluation and selection of co-existence mechanisms. Organizations should plan that a significant number of legacy applications will not natively support IPv6 and include requirements to support accessing IPv4 only applications and services by IPv4 and IPv6 clients.

The information captured in this inventory should populate the organization's IPv6 configuration management database and be maintained by configuration management. Configuration management data will not be perfect and will become out of date with the production environment. An organization must decide the acceptable level of accuracy needed to make good decisions and build processes to maintain the inventory data within the established parameters. The following decisions need to be made for each piece of equipment:

  1. Will the equipment be replaced to support IPv6?
  2. Can a service be upgraded to support IPv6?
  3. Will a translation mechanism be necessary?

The asset inventory is the main input into the organization's decision process concerning the deployment scenario. If the inventory demonstrates mostly new equipment, an IPv6 pervasive scenario is available as a deployment option. On the other hand, if the inventory demonstrates mostly older equipment that cannot readily support IPv6, then an IPv6 sparse deployment scenario is the more likely choice.

Organizations should consider the life cycle replacement of equipment in conjunction with the IPv6 rollout schedule. When possible, the IPv6 rollout schedule should align with the lifecycle replacement to reduce costs of the overall transition. Organizations that do not align schedules should plan for additional costs.

Other requirements subject areas are:

  1. Security
  2. Routing
  3. Network Management
  4. Host Configuration
  5. Address Planning
  6. Application Support and Development
  7. Performance and Bandwidth.

C1.2. Acquisition and Development Phase

The acquisition and development phase is concerned with taking the requirements gathered during the initiation phase and developing the IPv6 enterprise architecture. When developing the IPv6 environment, the current enterprise architecture should be considered. The acquisition/development phase will work with three different architectures: the "as is" IPv4 based enterprise architecture, the "to be" IPv6, and the transitional architecture that bridges the "as is" and "to be."

During the development phase, an organization should plan for an IPv6 evaluation pilot. The goals of an IPv6 pilot are to test IPv6 configuration and design assumptions against existing equipment, test and evaluate new IPv6 equipment and begin training staff. The pilot is the time to test the IPv6 numbering plan and other design assumptions. It is easier and less expensive to correct design deficiencies earlier in the transition lifecycle. As the requirements are evaluated against the existing equipment, inventory gaps may be discovered. It should be expected that some equipment will not make the transition; either it does not support IPv6 or does not meet performance expectations. The pilot should be used to evaluate new equipment and its ability to coexist in the "to be" and transition architectures. The pilot is a great opportunity to allow technical staff to develop their IPv6 skills. A pilot affords the opportunity to combine classroom training with a hands-on environment.

IPv4 and IPv6 are different protocols; they behave differently on similarly configured equipment. The IPv6 pilot should include testing to validate the performance of IPv6 in the environment and to develop strategies to mitigate any problems. IPv6 generally performs worse on equipment that was designed for IPv4. This is mainly the result of IPv6 header manipulation in software instead of hardware. Other factors besides header size can degrade performance, including extension headers, large packet sizes, and differences in fragmentation characteristics. This performance difference can vary.

The pilot should establish the baseline performance of IPv4-only, IPv6-only, and dual stack equipment and services. The baseline performance will allow the enterprise architects to understand the different performance characteristics and to design capacity into the "to be" and transition architectures. When possible, the testing should use production configuration to reduce the variation between the production and the test environment.

When establishing a baseline for security equipment, performance and coverage measures must be established. Security equipment evaluates traffic, which introduces latency into the network and reduces network throughput. IPv6 security equipment tends to have fewer known heuristics available for identifying potentially suspicious traffic than equivalent IPv4 equipment, which reduces the level of traffic coverage and potentially increases risk. Testing should be performed after establishing equivalent levels of coverage between IPv4 and IPv6. All security controls should be tested to include access control list, firewall rules, and IDPS signatures. The goal should be to design an IPv6 environment that is as secure as or more secure than the IPv4 environment.

Another area the pilot should address is the validation of tunnel performance. A mixed IPv4/IPv6 environment uses tunnels to connect the islands of similar protocol equipment. The performance of these tunnels affects the user experience, availability, and scalability of the network. Each transition mechanism has different performance characteristics. Before the pilot begins, the enterprise architecture team should select the appropriate mechanism based on functionality, performance, and the capabilities of the communicating peers. The testing of tunnels requires a realistic environment.

The final area the pilot should address is baseline transition mechanisms. Translation is performed in software and incurs a performance penalty.

In addition to developing the "to be" and transition enterprise architectures and running the IPv6 pilot, the other activities of the acquisition and development phase include:

  1. Developing a risk assessment.
  2. Developing a sequencing plan for IPv6 implementation.
  3. Developing IPv6 related policies and enforcement mechanisms.
  4. Developing training material for stakeholders.
  5. Developing and implementing a test plan for IPv6 compatibility/interoperability.

IPv6 Enterprise Architecture introduces new risks into the current environment. These risks can be the result of many different factors, including reduced security coverage, new IPv6 features, lack of IPv6 experience, degraded performance, and dual operations. A formal risk assessment must be performed with a risk mitigation strategy to address the identified risks. The risk assessment drives several other deliverables, including the security plan and certification and accreditation.

The transition to IPv6 offers a clean slate in implementing ingress and egress firewall rules. Organizations should have few IPv6 source or destination addresses that traverse the perimeter. Organizations, at this point, should be able to implement a deny all, permit by exception IPv6 firewall policy. In the future, as new external connections are required, either in bound or out bound, they can be documented and allowed by exception.

As the transition enterprise architecture is developed, a transition plan must also be developed. The transition plan details which equipment and servers are to be transitioned and in which order. The transition plan, which includes a coexistence plan, drives the project plan. The coexistence plan documents the type of transition mechanism used to connect islands of like protocol hosts and will also document the translation mechanisms for enterprise services.

Existing policies must be reviewed to determine whether they provide adequate coverage for IPv6. New policies should be developed to address IPv6 specific areas or areas where IPv6 has a significant impact. Senior leadership should support the new policies and sign off on them. Once policies are established, standards, procedures, and guidelines can be developed to provide guidance for equipment configuration and operation. The procurement policies should be amended early in the transition to require that all new equipment introduced to the environment support IPv6. This requirement should include both equipment that is lifecycle replacement and equipment introducing new capabilities. In many cases, existing policies can simply be amended.

IPv6 affects a broad range of support and operations personnel. During the acquisition and development phase, individual jobs should be evaluated, and training material should be developed or identified. IPv6 skills are not readily available in the job candidate pool, and organizations should expect to increase training budgets for IPv6 training for existing staff and new hires.

Proving the connectivity and interoperability of the enterprise architecture is a key factor in the success of the IPv6 transition. To ensure a successful transition, organizations must develop measures and test procedures for key services, applications, and capabilities. These measures and procedures collectively are the test plan. After a service, application, or capability is migrated, the test plan validates that the IPv6 equivalent provides service equal to or better than the IPv4 service.

At the conclusion of the acquisition and development phase, an organization should have produced the following artifacts:

  1. Enterprise Architecture
  2. Address Allocation Plan
  3. Address Management Plan
  4. Routing Plan
  5. Training Plan
  6. Security Plan
  7. Coexistence Plan.

The first design decision is to determine the organization's IPv6 address allocation. The size of the address space required to support the deployment depends on the number of devices and how many networks those devices require.

At this point, the organization should request an IPv6 address allocation from their regional internet registrar (RIR).

The organization also needs to create an address management plan. The address management plan documents the following:

  1. How devices allocate an address (for example, clients could use autoconfiguration or Dynamic Host Configuration Protocol version 6 (DHCPv6)
  2. Which nodes will have fixed IP addresses.
  3. How to update DNS with address ranges.

The training plan documents the training requirements across the organization as related to the IPv6 deployment. Typically, core engineers, help desk support, application developers, the security team, and system administrators will need training. The training plan includes both the types of training and length of training required. Training should allow IT operations to support IPv6 in production along with their current job specifications. Poor security practices, misconfiguration, and operator error are some of the leading causes of system compromise and loss of availability. Increasing staff knowledge about security and the computing environment will increase security and availability.

The goal of the security plan is to ensure that the IPv6 environment has the same level of security or better than the existing IPv4 environment. It should document how an organization plans to maintain security parity during the IPv6 deployment. The security plan should address the following areas:

  1. Equipment configuration
  2. Perimeter defense (firewall, ACL, IDPS)
  3. Content filtering
  4. Mail filtering
  5. Patch management
  6. Vulnerability management (scanning)
  7. Certification and accreditation of the new systems
  8. AAA (authentication, authorization, and accounting)
  9. Rogue detection
  10. Infrastructure protocol security.

The coexistence plan documents which mechanisms support IPv6/IPv4 internetworking. The coexistence plan details how IPv6 clients will access legacy IPv4 services (i.e., deployment of which translation mechanisms) and how existing IPv4 clients will access IPv6 services. By planning the coexistence mechanism in advance, an organization is able to leverage economy of scale and select technology that can be a repeatable solution. This reduces the amount of required training and increases operator familiarity with the mechanisms.

C1.3. Implementation Phase

The implementation phase involves the secure installation and configuration of IPv6 equipment, tunnels, and translation mechanisms. The deployment stage differs depending on which deployment scenario is used (IPv6 pervasive deployment or IPv6 sparse deployment). In both scenarios, the actual IPv6 roll out involves a phased deployment. The first three steps are the same regardless of deployment scenario.

The steps for the IPv6 pervasive deployment are as follows:

  1. Enabling perimeter firewall IPv6 policies and IPv6 access control lists and configuring devices in accordance with security plan, standards, and procedures.
  2. Deploying external IPv6 connectivity with exterior IPv6 routing.
  3. Deploying basic IPv6 services (DNS, DHCPv6, and NTPv6).
  4. Deploying IPv6 interior routing.
  5. Enabling management monitoring (SNMP, service monitoring, IDPS, authentication, statistical monitoring, and NetFlow).
  6. Enabling IPv6 hosts.
  7. Deploying IPv6 to IPv4 translation mechanisms.

The steps for the IPv6 sparse deployment are as follows:

  1. Enabling perimeter firewall IPv6 policies and IPv6 access control lists and configuring devices in accordance with security plan, standards, and procedures.
  2. Deploying external IPv6 connectivity with exterior IPv6 routing.
  3. Deploying basic IPv6 services (DNS, DHCPv6, and NTPv6).
  4. Enabling dual protocols on core routers. (This step can be performed at this point or after completing Step 5).
  5. For each IPv6 island:
    1. Enabling IPv6 on hosts.
    2. Enabling transition mechanism (tunnels) to other IPv6 islands.
  6. Enabling management monitoring (SNMP, service monitoring, IDPS, authentication, statistical monitoring, and NetFlow).
  7. Deploying IPv4 to IPv6 translation mechanisms.

With Step 5 above, the process is iterative until all hosts are either dual stack or IPv6 enabled.

Organizations should have a change control board that enforces the change control process. The security manager should be a member of the change control board. An IPv6 transition should follow established change control processes. Once a system is transitioned, it should be accredited and certified using inspection and acceptance testing. The measures and test procedures developed during the acquisition and development phase are used to certify that the transition equipment performs in the environment as intended.

Organizations must validate IPv6 migrated equipment by inspecting the configuration and running test procedures before transitioning devices to production. Device configurations must comply with established security and operations standards. Device configuration settings can be validated using either manual inspection or automated inspection tools. When possible, the use of automated compliance management solutions will increase the accuracy and consistency of configuration compliance.

Transitioned equipment must integrate and interoperate with other production and migrated equipment and systems. Integration validates that equipment is able to communicate with other systems and equipment and correctly exchange data. Checklists should be consulted that list the services with which a transitioned device must interoperate. Some examples include routing neighbors, DNS, DHCPv6, NTPv6, SNMP trap servers, syslog servers, mail servers, and application gateways. Integration and interoperations testing are difficult and usually performed manually.

Transitioned equipment must perform at the levels established in the test plan. Performance testing may be validated using live traffic or load generators. Failure to comply with test plans could result in a loss of availability when the equipment is placed into production.

IPv6 migration efforts require the certification and accreditation of systems. The migration to IPv6 (either IPv6 or dual stack) has the potential to significantly change the existing security posture. While the same security controls required for IPv4 are also required for IPv6, existing controls require reworking and reconfiguration to support IPv6, and new security controls are required to mitigate new IPv6 vulnerabilities. Organizations should plan on certifying and accrediting systems that have been migrated to IPv6 and systems that interact with IPv6 systems. Organizations should evaluate their certification support tools, techniques and procedures to ensure that these support IPv6. Organizations should ensure auditors performing the certification function are knowledgeable about IPv6 security and have the tools to look for IPv6 traffic and vulnerabilities. If two separate environments are supported (IPv4 and IPv6), then a system accreditor may require two separate certifications and accreditations; with a dual stack environment only a single certification and accreditation may be required. The goal should be to achieve security as good as or better than the IPv4 network.

C1.4. Operations and Maintenance Phase

The operations phase often begins concurrently with the implementation phase. During operations, the focus is the secure operation of a dual stack or mixed IPv6/IPv4 environment. One of the most difficult challenges facing the operations staff in a mixed IPv6/IPv4 environment is keeping the two environments synchronized.

When operations make changes to security controls such as firewall rule sets, access control lists, and IDS signatures, they must ensure the change occurs on both the IPv4 and IPv6 networks. Rules and signatures must be translated between IPv4 and IPv6 syntax and deployed as a single coordinated process. If strict change control is not followed, the two environments will have non-overlapping protections.

In a dual stack environment, the physical topologies of the equipment are the same, but the logical topologies can be very different. Configuration changes can have unpredictable or unforeseen consequences. Configuration management controls should be structured to prevent configuration changes on IPv4 or IPv6 networks that affect the other network. Organizations should manage and monitor their IPv4, IPv6, and dual stack environment as a single environment.

C1.5. Disposition Phase

A migration from IPv4 to IPv6 results in displacement or retirement of equipment. Some equipment does not support IPv6 and is retired, while other equipment is transferred to IPv4 islands or to other organizations. Organizations must plan for the secure disposition of this obsolete equipment, ensuring that no confidential data is released. Organizations place themselves at great risk for exposing confidential information when disposing of obsolete equipment.

A key decision concerning sanitization is whether the equipment is planned for reuse or retirement. Often, equipment is reused to conserve an organization's resources. Equipment should be sanitized before it is reused or retired. Most organizations have policies, regulations or standards that require the proper disposition of obsolete equipment. It is important that these processes be followed.

Failure to follow proper disposition procedures could result in the disclosure of confidential information. Organizations store and process information such as personal records of employees, personal records of clients, credit card numbers, social security numbers, medical information, trade secrets, classified data, system passwords, system configuration, network documentation, and many other examples of data that must be kept confidential. Network equipment can expose administrative accounts, passwords, authentication credentials, certificates, pre-shared keys, and community strings.

Failure to maintain confidentiality could result in embarrassment to the organization, system intrusions, software and hardware license violations, legal fees and fines, and other avoidable consequences. Some data requires protection under State law or Federal law or both (e.g., the Health Insurance Portability and Accountability Act (HIPAA), the Family Education Rights Privacy Act (FERPA) or industry governance boards like the Payment Card Industry Security Standards Council).

There are several methods available for sanitizing storage media. Equipment should be carefully evaluated to determine the types of media employed for persistent information. Some equipment (e.g. personal computers) employs a single persistent storage mechanism (hard drive); other equipment (e.g. routers) could employ multiple methods including hard drives, flash memory, Electronically Erasable Programmable Read-Only Memory (EEPROM), and other non-volatile memory. It is important to address the sanitation of solid-state memory. The method of media destruction should ensure the destruction of the information or media so that the information is unrecoverable. NIST SP 800-88, Guidelines for Media Sanitization,12 provides information about the proper sanitation or destruction of equipment. SP 800-88 includes pointers to other resources such as the U.S. Department of Defense 5220.22-M Clearing and Sanitization Matrix.13

One overlooked aspect of disposition is the management of software and hardware license and service agreements. Licensing agreements often dictate the terms under which software or hardware is transferable. Once equipment is at end-of-life, it may be possible to remove that equipment from support agreements, potentially saving money.

Organizations should adopt a proactive approach to media sanitation. Equipment removed from the network should be sanitized before the replacement equipment is installed. This reduces the window of vulnerability and greatly decreases the risk of information disclosure. Installers should provide proof of sanitation, including a certificate of destruction with serial numbers and asset tags.

C1.6. Summary

Security risks are inherent during the initial deployment of a new protocol such as IPv6, but mitigation strategies exist and many of the residual risks are no different from those that challenge existing IPv4 networks.

IPsec is a major component of IPv6 security and should be deployed, wherever possible, to secure IPv6 networks. Transition mechanisms allow existing IPv4 networks to coexist and interoperate with IPv6 networks, systems, and services. These transition mechanisms cover a wide range of technologies and transition scenarios. Organizations should plan their deployment and account for the full lifecycle of equipment from inception to disposal.

C2. IPv6 Deployment Security Considerations

The Office of Management and Budget (OMB) developed the Enterprise Architecture Assessment Framework14 to help organizations transitioning to IPv6. The deployment of IPv6-enabled equipment is a small part of the OMB framework. In the framework, most of the tasks deal with documenting the environment, communicating the transition both internally and externally, and making the strategic decisions. The framework outlines high-level tasks that should be accomplished during the transition effort:

  1. Conduct a requirements analysis to identify the current scope of IPv6 within an organization, current challenges using IPv4, and target requirements.
  2. Develop a sequencing plan for IPv6 implementation, integrated with the organization's Enterprise Architecture.
  3. Develop IPv6-related policies and enforcement mechanisms.
  4. Develop training material for stakeholders.
  5. Develop and implement a test plan for IPv6 compatibility/interoperability.
  6. Deploy IPv6 using a phased approach.
  7. Maintain and monitor networks.
  8. Update IPv6 requirements and target architecture on an ongoing basis.

The Architecture Assessment Framework can also be used to measure an organization's progression from an IPv4 operational environment to an IPv6 operational environment. Although the framework is not a detailed transition plan, a transition plan should address each of the framework's objectives.

C2.1. Security Risks

The deployment of IPv6 is inevitable. The IPv4 address space is almost exhausted and the only long-term solution is to deploy IPv6. IPv6 is not backwards compatible with IPv4, which means organizations will have to change their network infrastructure and systems to deploy IPv6. Organizations should begin now to understand the risks and the risk mitigation strategies. Planning will enable an organization to make a smooth, secure and successful transition.

Some general risks an organization may face include:

  1. The attacker community's use of IPv6
  2. Unauthorized deployment of IPv6 on existing IPv4 production networks
  3. Vulnerabilities present in IPv6, including "day zero" vulnerabilities that are inherent in any new or revised system
  4. Complexity added by dual IPv4/IPv6 operations
  5. Immaturity of IPv6 security products and processes
  6. Possible lack of vendor support.

C2.1.1. Vulnerabilities in IPv6

The IETF regards security as an important design constraint when developing standards for IPv6. Work to address a lack of confidentiality and integrity in IPv4 has resulted in the development of IPsec. IPv6 with IPsec resolves these issues, but IPsec has not addressed other weaknesses found in the TCP/IP protocol stack.

IPv6 does not solve many traditional layer 2 attacks like sniffing traffic, traffic flooding, man-in-the-middle attacks, rogue devices, or Address Resolution Protocol (ARP) table overflow attacks. Some of these attacks are dealt with partially in IPv6 while other attacks, similar in nature, exploit different features.

Although most modern operating systems have supported IPv6 since at least 2003, the protocol stacks of these operating systems have not been fully proven. A review of the National Vulnerabilities Database (NVD)15 shows stack vulnerabilities in most major operating systems. As new vulnerabilities are exposed, vendors will release updates. With any new code, vendors will need time to stabilize or harden their code. When deploying IPv6, an organization should understand that the code used in the IPv6 protocol stacks could be relatively new.

IPv4 Layer 2 and layer 3 attacks are possible because IPv4 assumes all network nodes will behave in a trustworthy manner. IPv4 uses ARP to associate physical addressing to logical addressing.

This assumption allowed attacks that interfered with IP address resolution and the association of physical addresses with logical addresses. IPv6, however, does not use ARP to map IP addresses to physical interfaces. Instead, IPv6 uses Internet Control Message Protocol version 6 (ICMPv6). IPv6 uses ICMP for neighbor discovery and stateless address autoconfiguration processes that associate physical and logical addresses. IPv6 is still vulnerable to layer 3 attacks. A type of layer 3 attack is the host initialization attack. Three common host initialization attacks are:

  1. Neighbor Solicitation (NS). For neighbor discovery, a client node sends an NS message. The problem is that any node can claim to be any other node on the LAN. An attacker can falsify a NS message with their MAC address and the fake IP address. This technique is similar to ARP spoofing in IPv4 and only works on link-local.
  2. Router Solicitation (RS). With stateless address autoconfiguration, the client node sends an RS message. Like the NS attack, any node can claim to be the default router and subvert the initialization process. These attacks are link-local scoped.
  3. Duplicate Address Detection (DAD) Process. When a node attempts to configure its link-local address, it runs DAD. An attacker can cause a denial of service attack by responding to a DAD request. As a result, the victim's interface will fail to initialize.

The subnet size in IPv6 can present its own security challenges. These challenges are discussed in RFC 5157, IPv6 Implications for Network Scanning. The subnet size is much larger than it was in IPv4; a default subnet can have 264 addresses. Subnet size and resulting lengthy scan times are often presented as security features since they will slow down a malicious scanner or the propagation of malicious logic. The subnet size, however, makes it difficult for network and system administrators to manage assets. Attackers and administrators need to rely on other discovery techniques like layer 2 discovery and DNS to find hosts. The large address space makes it more difficult to find rogue hosts, possibly causing administrators to rely on passive discovery techniques. Administrators may need to resort to predictable or sequential numbering schemas for device addressing.

To mitigate most layer 3 vulnerabilities, administrators should consider using fixed addressing or DHCPv6 with DHCP rogue detection instead of stateless address autoconfiguration. Autoconfiguration and ND can be secured with SEND. More information on SEND is available in NIST SP 800-119, Guidelines for the Secure Deployment of IPv6. Layer 2 discovery, 802.1x based network access control, and good configuration management practices will help to mitigate layer 3 vulnerabilities.

The deployment of IPv6 reinforces the basic security lessons learned with IPv4. These security practices include defense in depth, diversity, patching, configuration management, access control, and system and network administrator best practices. Good security practices remain unchanged with the deployment of IPv6. Good security practices will reduce exposure and recovery time in case of a security event.

C2.1.2. Perceived Risk

A misconception about IPv6 is that IPv6 by itself introduces many more security risks than the IPv4 protocol. Perceived risk can cause an organization to delay deployment despite the fact that IPv6 enabled equipment is already on hand. IPv6 is no more or less secure than IPv4. General security concepts are the same for both IP protocols. However, it will take time to acquire the level of operational experience and practical deployment solutions that have been developed for IPv4 over the years.

C2.2. Dual Operations

An organization that deploys IPv6 may support IPv4 for legacy applications, services, and clients. This will result in a dual protocol environment and increased complexity. The risk is that an organization's security infrastructure may not be aware of both protocols. Dual protocols will increase the complexity of the environment. Two protocols mean twice as many things can go wrong, and twice the number of configurations are required to install new equipment or change existing equipment. Attacks against upper layer protocols could use either the IPv4 or IPv6 stack to reach the client. Administrators will need to maintain the same level of coverage for both protocols to mitigate risks.

C2.2.1. IP4 and IPv6 Threat Comparison

The deployment of IPv6 can lead to new challenges with respect to the types of threats facing an organization. This section provides a high-level overview as to how threats differ from an IPv4 environment to an IPv6 environment and combined IPv4-IPv6 environment. The following chapters provide additional details to these threats as required. It should be noted that many IPv6 threat discussions rely on IPsec to provide protection against attack. Due to issues with key management and overall configuration complexity (including applications), it is possible that IPsec will not be deployed much more than it is with IPv4 today for initial IPv6 use. IPsec is covered in detail in NIST SP 800-119, Guidelines for the Secure Deployment of IPv6.

Network reconnaissance is typically the first step taken by an attacker to identify assets for exploitation. Reconnaissance attacks in an IPv6 environment differ dramatically from current IPv4 environments. Due to the size of IPv6 subnets (264 in a typical IPv6 environment compared to 28 in a typical IPv4 environment), traditional IPv4 scanning techniques that would normally take seconds could take years on a properly designed IPv6 network. This does not mean that reconnaissance attacks will go away in an IPv6 environment; it is more likely that the tactics used for network reconnaissance will be modified. Attackers will still be able to use passive techniques, such as Domain Name System (DNS) name server resolution, to identify victim networks for more targeted exploitation. Additionally, if an attacker is able to obtain access to one system on an IPv6 subnet, the attacker will be able to leverage IPv6 neighbor discovery to identify hosts on the local subnet for exploitation. Neighbor discovery-based attacks will also replace counterparts on IPv4 such as ARP spoofing.

Prevention of unauthorized access to IPv6 networks will likely be more difficult in the early years of IPv6 deployments. IPv6 adds more components to be filtered than IPv4, such as extension headers, multicast addressing, and increased use of ICMP. These extended capabilities of IPv6, as well as the possibility of an IPv6 host having a number of global IPv6 addresses, potentially provides an environment that will make network-level access easier for attackers due to improper deployment of IPv6 access controls. Moreover, security related tools and accepted best practices have been slow to accommodate IPv6. Either these items do not exist or have not been stress tested in an IPv6 environment. Nevertheless, global aggregation of IPv6 addresses by ISPs should allow enhanced anti-spoofing filtering across the Internet where implemented.

Attacks that focus on exploitation above the IP layer, such as application-based attacks and viruses, will not see a difference in the types of threats faced in an IPv6 environment. Most likely, some worms will use modified IPv6 reconnaissance techniques for exploitation. Additionally, because many IPv4 broadcast capabilities have been replaced with IPv6 multicast functionality, broadcast amplification attacks will no longer exist in an IPv6 environment.

From this comparison of IPv4 and IPv6 threats, one can surmise that IPv6 will not inherently be either more or less secure than IPv4. While organizations are in the process of deploying IPv6, the lack of robust IPv6 security controls and a lack of overall understanding of IPv6 by security staff may allow attackers to exploit IPv6 assets or leverage IPv6 access to further exploit IPv4 assets. There is a very likely possibility that many IPv6 services will rely on tunneling IPv6 traffic in IPv4 for infrastructures that do support the protocol, which will also increase the complexity for security staff. Additionally, since IPv6 systems and capabilities are not yet widely used in production environments, there is a distinct possibility that the number of vulnerabilities in software from implementing IPv6 capabilities could rise, as IPv6 networks are increasingly deployed.

Based on the threat comparison between IPv4 and IPv6, the following actions are recommended to mitigate IPv6 threats during the deployment process:

  1. Apply different types of IPv6 addressing (privacy addressing, unique local addressing, sparse allocation, etc.) to limit access and knowledge of IPv6-addressed environments.
  2. Assign subnet and interface identifiers randomly to increase the difficulty of network scanning.
  3. Develop a granular ICMPv6 filtering policy for the enterprise. Ensure that ICMPv6 messages that are essential to IPv6 operation are allowed, but others are blocked.
  4. Use IPsec to authenticate and provide confidentiality to assets that can be tied to a scalable trust model (an example is access to Human Resources assets by internal employees that make use of an organization's Public Key Infrastructure (PKI) to establish trust).
  5. Identify capabilities and weaknesses of network protection devices in an IPv6 environment.
  6. Enable controls that might not have been used in IPv4 due to a lower threat level during initial deployment (implementing default deny access control policies, implementing routing protocol security, etc.).
  7. Pay close attention to the security aspects of transition mechanisms such as tunneling protocols.
  8. On networks that are IPv4-only, block all IPv6 traffic.

C2.3. Vendor Support

Many security vendors are waiting for customer demand before implementing support for IPv6, while customers are waiting for vendors to support IPv6 before purchasing software and systems. This has resulted in a "chicken and egg" problem. While some vendors fully support IPv6, many do not support IPv6 at all or only offer limited support.

Organizations need to analyze their existing IPv4 security infrastructure and develop baseline requirements that an IPv6 infrastructure must meet to achieve the same or better security as their IPv4 environments. New base requirements may be added to address IPv6-only requirements or deficiencies in the existing environment. Some existing IPv4 equipment may support both IPv4 and IPv6 requirements, but organizations should plan to evaluate products with IPv6 support to supplement and/or replace existing equipment or bridge security gaps. Use the developed baseline security requirements to evaluate IPv6 security products. Product evaluation, selection and procurement can slow down the deployment schedule for IPv6. Organizations planning to deploy IPv6 should begin a dialog with their security vendors to support IPv6 as early as possible.

There are no industry standards that define IPv6 support. Organizations must understand they will be gaining and losing capabilities by deploying IPv6 and this will change their security posture. When vendors claim IPv6 support, it is up to the organization to evaluate whether they can function with the vendors' level of IPv6 support. Often IPv6 support is not as complete as IPv4 support. An example of this is that many IPv6 security devices require IPv4 addressing for management and configuration.

NIST has issued a special publication to define the capabilities IPv6 devices should support. NIST SP 500-267, A Profile for IPv6 in the U. S. Government – Version 1.0 21 will help organizations identify and select products that support IPv6. This document has a section dedicated to Network Protection Devices that discusses the capabilities firewalls, application firewalls, and intrusion detection systems should support. When evaluating these types of security devices, organizations should ensure the equipment complies with the profile. To facilitate that goal, NIST has launched a USGv6 (US Government IPv6) test program52 to verify the IPv6 conformance and interoperability of three classes of IPv6 devices: hosts, routers and Network Protection Devices (NPDs). Testing is conducted by independent laboratories; the laboratories are accredited to perform the testing by ISO-certified accreditors. Vendors declare products that have qualified as USGv6-compliant through the use of a Supplier's Declaration of Conformity (SDOC), which enables potential users of the product to identity the capabilities that were tested and the laboratory that conducted the testing.

NIST Special Publication 500-267B Revision 1 does not address several classes of security devices including security event/log management, vulnerability/patch management, flow (NetFlow, SFlow), forensic tools, and authentication systems. Many vendors are able to process IPv6 traffic but lack capabilities to present the information effectively, require IPv4 enabled equipment for management, or are not as feature-rich. Organizations will have to develop capability profiles for their security tools.

Organizations should accept the possibility that they may not achieve full parity in their IPv4 and IPv6 environments and take steps to mitigate associated risks.

C3. USGv6 Profile and Testing Program

The goal of the USGv6 Program is to deliver operating systems, network devices, security devices16 and applications which meet a minimal requirement based on the need of the agency.

The Internet Engineering Task Force (IETF) Request for Comments (RFC)17 is a consensus standard which defines the operations and security of a network protocol. NIST updates the consensus standards and creates a default NISTv618 capability definition, a USGv6 Profile19 , and finally the USGv6 Capabilities Table20 .

Figure 1: USGv6 Program

Figure 1: USGv6 Program

In 2019 NIST updated the USGv6 Profile and Test Program technical specifications and to streamline their use in Federal procurement. This new profile incorporated a number of changes to include product functionality which makes it necessary to support IPv6-only environments and testing of IPv6 capable applications. The revision of the profile and capabilities table are available21 for any agency to view and begin the customization process based on their specific needs. See figure 2 below for details.

Figure 2: IPv6 Profile Revision

Figure 2: IPv6 Profile Revision

Appendix D: Forms and Templates

Please note that this appendix is subject to change at any time. The current version of this Policy will always reside in the OCIO Policy Library.

On a case by case basis, the HHS CIO has the authority to waive the IPv6 transition implementation when an undue burden is posed upon the Department.

Fill out the HHS Waiver Risk Acceptance Form in accordance with instructions at Appendix A, and submit to the HHS IPv6 IPT, HHSIPv6IPT@hhs.gov and carbon copy HHS.Cybersecurity@HHS.gov for adjudication.

Appendix E: List of References

Please note that this appendix is subject to change at any time. The current version of this Policy will always reside in the OCIO Policy Library.

References include:

Legislation, Federal Regulations and Executive Orders

  • Federal Information Security Modernization Act of 2014 (FISMA 2014), 44 United States Code (U.S.C.) § 3551
  • Federal Information Technology Acquisition Reform Act (FITARA) H.R. 1232, as amended.
  • Federal Register, Department of Health and Human Services, March 7, 2012, 45 CFR Part 170
  • Section 508 of the Rehabilitation Act of 1973, as amended in 1998 (29 U.S.C. § 794d)
  • The Office of Management and Budget, The Federal Cloud Computing Strategy

Federal Guidance

  • Federal Information Processing Standard (FIPS) 199, Standards for Security Categorization of Federal Information and Information Systems, February 2004
  • Internet Engineering Task Force (IETF), Request for Comment (RFC) 4057, IPv6 Enterprise Network Scenarios, June 2005
  • IEFT, RFC 5157, IPv6 Implications for Network Scanning, March 2008
  • IEFT RFC 8504, IPv6 Node Requirements, January 2019
  • ITL Bulletin , Internet Protocol Version 6 (IPv6): NIST Guidelines Help Organizations Manage The Secure Deployment Of The New Network Protocol, January 2011
  • National Institute of Standards and Technology (NIST) National Vulnerability Database (NVD)
  • NIST Special Publication (SP) 800-37 Rev. 2, Risk Management Framework for Information Systems and Organizations: A System Life Cycle Approach for Security and Privacy, December 2018
  • NIST Special Publication (SP) 800-88 Rev. 1, Guidelines for Media Sanitization, December 2014
  • NIST Special Publication (SP) 800-97, Establishing Wireless Robust Security Networks: A Guide to IEEE 802.11i, February 2007
  • NIST Special Publication (SP) 800-126 Rev.3, The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.3, February 2018
  • NIST Special Publication (SP) 800-128, Guide for Security-Focused Configuration Management of Information Systems, August 2011
  • NIST Special Publication (SP) 800-153, Guidelines for Securing Wireless Local Area Networks (WLANs), February 2012
  • NIST Special Publication (SP) 800-160 Vol.1, Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems, November 2016 (updated 3/21/2018)
  • NIST Special Publication (SP) 800-161, Supply Chain Risk Management Practices for Federal Information Systems an Organizations, April 2015
  • Office of Management and Budget (OMB), Enterprise Architecture Assessment Framework (EAAF)
  • OMB, Circular No A-11, Preparation, Submission and Execution of the Budget, Section 55, June 28, 2019
  • OMB, Memorandum for Chief Information Officers, Security Authorization of Information Systems in Cloud Computing Environments, December 8, 2011
  • OMB, Memorandum, M-15-14, Management and Oversight of Federal Information Technology, June 10, 2015
  • OMB Memorandum, M-17-06, Policies for Federal Agency Public Websites and Digital Services, November 8, 2016
  • OMB, The Federal Cloud Computing Strategy, June 24, 2019

Departmental Policy and Guidance

  • HHS Directive for Acquisition Strategy
  • HHS Federal Information Technology Acquisition Reform Act (FITARA) Implementation-Revised HHS IT Governance Framework, October 25, 2016
  • HHS Federal Information Technology Acquisition Reform Act (FITARA) HHS Implementation Plan, September 2015
  • HHS Information System Security and Privacy Policy, (IS2P), July 30, 2014
  • HHS Minimum Security Configuration Standards Guidance, October 2017
  • HHS Policy for Capital Planning and Investment Control (CPIC), April 26, 2019
  • HHS Policy for Cyber Supply Chain Risk Management, August 2020
  • HHS Policy for Domain Name System (DNS) and Domain Name System Security Extension (DNSSEC) Services, October 2019
  • HHS Policy for Internet and Email Security, October 2019
  • HHS Policy for IT Enterprise Performance Lifecycle (EPLC), October 6, 2008
  • HHS Policy for Software Development Secure Coding Practices, August 2019
  • HHS Policy for the Implementation of Trusted Internet Connection, March 17, 2021
  • HHS Policy for Section 508 Compliance and Accessibility of Information and Communications Technology (ICT), July 2020
  • HHS Standard for Encryption of Computing Devices and Information, December 14, 2016

Links to the authorities cited above can be found at the following main websites: Executive Orders, FAR, NIST Publications, OMB and Departmental Policy and Guidance.

Glossary and Acronyms

Definitions:

  • Address Exhaustion – Full consumption of endpoint identifiers. IPv4 addresses contain fewer than 4.3 billion addresses and were fully allocated to Internet carriers, companies, and governments.
  • Dual stack (IPv6/IPv4) - A system or product that can process both IPv6 and IPv4 packets, receive from or forward IPv6 packets to other IPv6-only and dual stack systems, and receive from or forward IPv4 packets to other IPv4-only and dual stack systems.
  • External facing servers and services - All networked services accessible from the public Internet, but not intended for the general public (all users of the public Internet) and that have some form of access control. This scope extends to any and all restricted external services provided by or contracted by or entirely outsourced to commercial providers by the HHS. Examples of external facing services that are within scope of this definition include external web (Hypertext Transfer Protocol /Hypertext Transfer Protocol Secure (HTTP/HTTPS)), email and restricted mobile applications. Internal services (i.e., accessible only within the HHS enterprise or intra-net) are not within the scope of this definition. HHS-provided external facing servers and services should be available to a user with only IPv6 capabilities once cybersecurity requirements are met and authorization is provided.
  • Information Technology (IT) - "IT" is defined as any services, equipment, or interconnected system(s) or subsystem(s) of equipment, that are used in the automatic acquisition, storage, analysis, evaluation, manipulation, management, movement, control, display, switching, interchange, transmission, or reception of data or information by the agency.
  • Internet Protocol (IP) - addresses are the global numeric identifiers necessary to uniquely identify entities that communicate over the Internet.
  • IPv4 - IP addresses in use since 1983.
  • IPv6 - Next-generation protocol designed to replace version 4 (IPv4) that has been in use since 1983.The protocol was developed and operational testing for over 19 years and standardized on July 2017 as IETF Standard 86.
  • IPv6-capable products - Products (whether developed by commercial vendor or the government) that can create or receive, process, and send or forward (as appropriate) IPv6 packets in Dual Stack environments. IPv6 capable products shall be able to interoperate with other IPv6-capable products on networks supporting IPv4-only, IPv6-only, or dual stack.
  • IPv6-capable network - Networks that can receive, process, and forward IPv6 packets from/to devices within the same network and from/to other networks and systems, where those networks and systems may be operating with IPv4-only, IPv6-only, or dual stack. An IPv6 capable network shall be ready to have IPv6 enabled for operational use.
  • IPv6-enabled network - An IP network that is supporting operational IPv6 traffic, through the network, end-to-end.
  • IPv6/IPv4 equivalency - Any function that is defined in the Internet Engineering Task Force (IETF) IPv4 standards and which can be implemented on an IPv4 network, which is also defined in the IETF IPv6 standards and can be implemented on an IPv6 network with demonstrated connectivity, interoperability, security, and performance at least equal to, if not exceeding that function on an IPv4 network.
  • IPv4-only - A system or product that can process IPv4 packets and can receive from or forward IPv4 packets to other IPv4-only and dual stack systems, but cannot process, receive, or forward IPv6 packets.
  • IPv6-only - A system or product that can process IPv6 packets and can receive from or forward IPv6 packets to other IPv6-only and dual stack systems, but cannot process, receive, or forward IPv4 packets.
  • IPv6 Transition – The process of moving networks, applications and systems from an IPv4 only networks, through a dual stack with the final goal of an IPv6 only computing and network environment. 
  • Network Address and Port Translation (NAPT) - Network Address and Port Translation was a method to slow address exhaustion for IPv4. Although marketed by vendors in the 1990's through today, the NAPT is not a security feature.
  • Network Address Translation – A routing technology used by many firewalls to hide internal system addresses from an external network through use of an addressing schema.
  • Networked Asset - Any IT asset that is capable of connecting to a network
  • Public facing servers and services - All networked services that HHS currently provides, or will provide, to the general public (all users of the public Internet). This scope extends to any and all public-unrestricted services provided by or contracted by or entirely outsourced to commercial providers by the HHS. Examples of public facing services that are within scope include external web (HTTP/HTTPS, unrestricted mobile applications and authoritative domain name system (DNS) services. Internal services (i.e., accessible only within the HHS enterprise or intranet) and HHS external services (i.e., accessible from the public Internet with some form of access control) are not within the scope of this definition. U.S. Government-provided public facing servers and services must be available to an Internet user with only IPv6 capabilities.

Acronyms:

  • CSS – Capability Summary String
  • DNS - Domain Name System
  • E.O - Executive Order
  • FAR - Federal Acquisition Regulation
  • FedRAMP – Federal Risk and Authorization Management Program
  • HHS - United States Department of Health and Human Services
  • HTTP/HTTPS - Hypertext Transfer Protocol/ Hypertext Transfer Protocol Secure
  • IETF – Internet Engineering Task Force
  • IPv4 – Internet Protocol version 4
  • IPv6 – Internet Protocol version 6
  • IT – Information Technology
  • NIST - National Institute of Standards and Technology
  • OCIO – Office of the Chief Information Officer
  • OMB - Office of Management and Budget
  • OpDiv - Operating Division
  • POC - Point of Contact
  • RFC - Request for Comment
  • SDoC – Suppliers Declaration of Conformity
  • StaffDiv – Staff Division
  • UCT - USGv6 Capabilities Table
  • USGv6 – United States Government version 6
    1. U.S. Office of Management and Budget. OMB Memorandum 21-07 Completing the Transition to Internet Protocol Version 6 (IPv6). [Washington, D.C.]: Executive Office of the President, Office of Management and Budget.
  • back to note 1
    • 2. M-21-07 notes that for public Internet services, maintaining viable IPv4 interfaces and transition mechanisms at the edge of the service infrastructures may be necessary for additional time, but this does not preclude operating the backend infrastructures as IPv6-only.
  • back to note 2
    • 3. IPv6-capable refers to a system or service that has correctly implemented a complete set of IPv6 capabilities. The NIST USGv6 profile describes detailed technical requirements for IPv6 capabilities for distinct product types (https://www.nist.gov/programs-projects/usgv6-program/news-and-related-info).
  • back to note 3
    • 4. Executive Order 12333, United States intelligence activities (December 4, 1981), 46 FR 59941, 3 CFR, 1981 Comp., p. 200. Available at https://www.archives.gov/federal-register/codification/executive-order/12333.html (retrieved July 23, 2020).
  • back to note 4
    • 5. IPv-6 enabled refers to a system or service in which the use of IPv6 is "turned on" for production use.
  • back to note 5
    • 6. Native IPv6 refers to direct support of IPv6 in a system or service without requiring the use of IPv4 for basic communications
  • back to note 6
    • 7. IPv6-capable refers to a system or service that has correctly implemented a complete set of IPv6 capabilities. The NIST USGv6 profile describes detailed technical requirements for IPv6 capabilities for distinct product types (https://www.nist.gov/programs-projects/usgv6-program/news-and-related-info).
  • back to note 7
    • 8. For additional information on the IETF, refer to https://www.ietf.org/
  • back to note 8
    • 9. NIST SP 800-160, Systems Security Engineering: Considerations for a Multidisciplinary Approach in the Engineering of Trustworthy Secure Systems
  • back to note 9
    • 10. NIST SP 800-119, Guidelines for the Secure Deployment of IPv6
  • back to note 10
    • 11. NIST FIPS 199, Standards for Security Categorization of Federal Information and Information Systems.
  • back to note 11
    • 12. NIST SP 800-88, Guidelines for Media Sanitization
  • back to note 12
    • 13. DOD 5220.22-M, Clearing and Sanitization Matrix
  • back to note 13
    • 14. OMB, Enterprise Architecture Assessment Framework (EAAF)
  • back to note 14
    • 15. NIST National Vulnerabilities Database (NVD)
  • back to note 15
    • 16. https://www.nist.gov/publications/guidelines-secure-deployment-ipv6, and https://www.nccoe.nist.gov/events/security-ipv6-enabled-enterprises
  • back to note 16
    • 17. RFC Search Detail (rfc-editor.org)
  • back to note 17
    • 18. See https://doi.org/10.6028/NIST.sp.500-267Ar1s
  • back to note 18
    • 19. See https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.500-267Br1.pdf
  • back to note 19
    • 20. See https://www.nist.gov/publications/usgv6-capabilities-table
  • back to note 20
    • 21. https://www.nist.gov/programs-projects/usgv6-program/usgv6-revision-1
  • back to note 21
Content created by Office of the Chief Information Officer (OCIO)
Content last reviewed