ICANN’s IPv6 Initiative

Background

Beyond the IANA function of allocating top-level Internet Protocol (IP) identifiers (including IPv6), the ICANN organization shares a collective responsibility for preserving and supporting a globally secure, stable and Interoperable Internet.

According to RFC 2460, IPv6 is the protocol that will support the next generation of the Internet:

"… IP version 6 (IPv6) is a new version of the Internet Protocol, designed as the successor to IP version 4 (IPv4) [RFC-791]. The changes from IPv4 to IPv6 fall primarily into the following categories: …"

The current trend suggests that it will be difficult to envisage the Internet's continued growth without IPv6. Keeping in mind ICANN's strategic objective to "support a healthy, stable, and resilient unique identifier ecosystem," it is important for us contribute our fair share in helping to promote IPv6 uptake within our circle of influence. ICANN's role here can be compared to what we do for other critical protocol standards, such as Domain Name System Security Extensions (DNSSEC).

Recently, the Internet Architecture Board (IAB) made a statement stressing the importance of considering IPv6 as the default Internet Protocol for new network standards, instead of focusing on IPv4 compatibility:

"The Internet Architecture Board (IAB), following discussions in the Internet Engineering Task Force (IETF), advises its partner Standards Development Organizations (SDOs) and organizations that the pool of unassigned IPv4 addresses has been exhausted, and as a result we are seeing an increase in both dual-stack (that is, both IPv4 and IPv6) and IPv6-only deployments, a trend that will only accelerate. Therefore, networking standards need to fully support IPv6. The IETF as well as other SDOs need to ensure that their standards do not assume IPv4.

The IAB expects that the IETF will stop requiring IPv4 compatibility in new or extended protocols. Future IETF protocol work will then optimize for and depend on IPv6.

Preparation for this transition requires ensuring that many different environments are capable of operating completely on IPv6 without being dependent on IPv4 [see RFC 6540]. We recommend that all networking standards assume the use of IPv6, and be written so they do not require IPv4. We recommend that existing standards be reviewed to ensure they will work with IPv6, and use IPv6 examples. Backward connectivity to IPv4, via dual-stack or a transition technology, will be needed for some time. The key issue for SDOs is to remove any obstacles in their standards which prevent or slow down the transition in different environments.

In addition, the IETF has found it useful to add IPv6 to its external resources (e.g., Web, mail) and to also run IPv6 on its conference network since this helps our participants and contributors and also sends the message that we are serious about IPv6. That approach might be applicable to other SDOs.

We encourage the industry to develop strategies for IPv6-only operation. We welcome reports of where gaps in standards remain, requiring further developments in IPv6 or other protocols. We are also ready to provide support or assistance in bridging those gaps.

https://www.iab.org/2016/11/07/iab-statement-on-ipv6/

Such a statement makes it even more important for ICANN to ensure that:

• All services that we provide to the community can accept connections from IPv6 networks.
• Registries and Registrars comply with their agreed-upon IPv6 requirements.
• We provide regular updates to the community about where we stand on all the above, and seek input from the community on actions we can take to close any identified gaps.

Our partners and peers working at the Regional Internet Registries (RIRs) and Internet Society (ISOC) are already very active in promoting IPv6. The RIRs are working on this with their stakeholders (Internet network infrastructure operators and service providers) and ISOC is including it as part of its overall open Internet development advocacy mission. At the same time, we at ICANN have to focus our attention on engaging with the domain name industry.

We need to demonstrate how we share collective responsibility with the other I* organizations to "safeguard" stable and resilient growth of the Internet's infrastructure.

Scope of ICANN's IPv6 Initiative

There are few areas that ICANN can focus on:

1. IPv6 compatibility requirements for ICANN's contracted parties (including our own procurement)

   As a way of leading by example, we must make it clear that we expect our contracted parties to provide services that are IPv6 compliant. To be effective, we can limit our focus to two categories of contracted parties:

   1. gTLD Registries: The new gTLD Registry Agreement has a clear provision in its specifications section about compliance with standards. Clause 6.1.5 states:

      ---

      "IPv6. Registry Operator shall be able to accept IPv6 addresses as glue records in its Registry System and publish them in the DNS. Registry Operator shall offer public IPv6 transport for, at least, two of the Registry's name servers listed in the root zone with the corresponding IPv6 addresses registered with IANA. Registry Operator should follow "DNS IPv6 Transport Operational Guidelines" as described in BCP 91 and the recommendations and considerations described in RFC 4472. Registry Operator shall offer public IPv6 transport for its Registration Data Publication Services as defined in Specification 4 of this Agreement; e.g., Whois (RFC 3912), Web based Whois. Registry Operator shall offer public IPv6 transport for its Shared Registration System (SRS) to any Registrar, no later than six (6) months after receiving the first request in writing from a gTLD accredited Registrar willing to operate with the SRS over IPv6."

      ---

      While these requirements are systematic for all new gTLD registries, they are slowly being extended to the legacy registries as well.

   2. Registrars: The expectation for Registrars is currently limited to IPv6 transport for their WHOIS services and AAAA records acceptance for domain name registration parameters. However, the same expectation does not apply to domain name resellers that have no agreement with ICANN.
   3. ccTLD Operators: As a result of not having a formal contractual relationship with ccTLD operators, ICANN cannot enforce any requirements. The approach here will be based on a voluntary adoption, supported by active engagement by ICANN with this specific community on the topic (similar to what the RIRs have with their members).
   4. Contractors providing services to ICANN or the community: Based on what we have gathered from our procurement department, there is generic IPv6 language in our "Contractor and Consulting Agreement," which states the following about IPv6 compliance:

      ---

      "IPV6 SPECIFICATION COMPLIANCE:
      To the extent the Services and/or Deliverables include development or provision of (i) website design, hosting, implementation and/or programming, and/or (ii) software and/or devices that support network or Internet connectivity, Contractor warrants and represents that all such Services and Deliverables will be fully compliant with the Internet Engineering Task Force (IETF) Internet Protocol, Version 6 Specification, sometimes referred to as the IPv6 Specification and, in addition, will be fully backward-compatible with the Internet Engineering Task Force (IETF) Internet Protocol, Version 4 Specification, sometimes referred to as the IPv4 Specification, including without limitation having the capabilities: (a) to create or receive, process, and send or forward (as appropriate) IPv6 packets in mixed IPv4/IPv6 environments, and (b) to interoperate with other iPv6 compliant software, devices and websites on networks supporting only IPv4, only IPv6, or both IPv4 and IPv6. The expectation is that any networked application or service developed for ICANN would operate irrespective of whether such services were accessed using IPv4 or IPv6."

      ---

   For a more generalized approach, ICANN's procurement guidelines should also be updated to ensure that proper guidelines are given to have proper IPv6 requirements across the board, along with ways to assess compliance and deal with cases where it is practically impossible to be in compliance. Current published guidelines can be found at: https://www.icann.org/en/system/files/files/procurement-guidelines-21feb10-en.pdf [PDF, 1 MB]

2. ICANN's own infrastructure and services

   To become a role model in the Internet ecosystem, we must aspire to make our own infrastructure fully IPv6 compliant, both from network infrastructure and application perspectives. Our community must be able to transparently access all our online services over both IPv4 and IPv6. A lot of internal work has already gone into this area. It will be rewarding to be able to share our experiences with the community, including how we did it, challenges we faced throughout the process and how we overcame them.

Doing everything described above will position ICANN as a robust and engaged technical player in this specific are of IPv6 within the community.