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.

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

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:

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.

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.

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).

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]

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.

Document our own implementation experience and share with the relevant communities, including our contributions to address some of the challenges.

Registry & Registrars

Provision in RAA

IPv6 compliance assessment for Registries and Registrars.

Quarterly publication of the compliance ratio's evolution.

Develop a dedicated online resource center to support IPv6 compliance, including a dedicated web area with toolkits, tutorials, webinars, case studies, etc. This could be linked to the Online Learning Platform (OLP).

Regular evaluation of requirements effectiveness.

Explore partnership opportunities with I* organizations for capacity building programs/campaigns.

Data Protection

A note about our privacy policies and terms of service:

We have updated our privacy policies and certain website terms of service to provide greater transparency, promote simplification, and align with recent changes in privacy laws applicable to us. Learn more.

This site uses cookies to deliver an efficient user experience and to help us see how the site is used. Learn more.OK

Domain Name System

Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."