IPv6 at ccTLDs

Autor: Roque Gagliano - LACNIC.
Version 1.1 - 23/12/2008
(Work in progress)

Introduction:

Driven by the depletion of IPv4 resources, organizations at global level are in different stages of the process of adopting the IPv6 protocol. Domain name resolution (DNS) is essential for any development, and consequently so is the adoption of IPv6 at country code Top Level Domain (ccTLD) administrator level and the entire distribution chain to which they are related.

What does a client or the community expect from a ccTLD in terms of IPv6?
We can distinguish three elements:

1. Ability to accept AAAA records for their domain name servers (“glue records”) in case they are necessary.
2. Name resolution over IPv6.
3. Ability to access administrative tools (web, WHOIS, EPP) over IPv6.

AAAA records for domain name servers:

This item proposes the availability of AAAA records for domain name servers to which re-delegations are made (the so-called “glue records”) in the areas administrated by a ccTLD. These records will involve a verification of the ccTLD provisioning system, either a manual system, an automatic online system, or a system that uses a protocol such as EPP (RFC 4931 specifies IPv6 support for EPP) or API.
Changes may include modifying user interfaces, databases and WHOIS service .

If there are other organizations participating in domain name registration (“registrars”), these must also update their systems so as to allow their clients to register. The ccTLD operator could apply active policies to promote adoption on the part of the registrar.

It is important to highlight that registering domain name server IPv6 addresses is only necessary if the server name is downstream within the domain name hierarchy.

Name resolution over IPv6:

This item involves two aspects. The first involves adapting domain name resolution software so that they may be used with IPv6, accepting incoming connections (both UDP and TCP as appropriate) over IPv6. All current DNS software applications allow this function, and in many cases all they need is a minor configuration.

The second aspect is the network infrastructure needed for IPv6 transport. This infrastructure may require router configurations or updates, firewalls and IPv6 transit. Generally, obtaining IPv6 transit represents the main barrier to the adoption of the protocol and must be planned well in advance.

It is not necessary to have IPv6 transport for all the servers of a ccTLD. IPv6 traffic is currently low, both at query as well as at packet level, and can be supported by a small number of servers. Specifically, many ccTLDs already have secondary servers located at external organizations, so it is important to verify these secondary servers as they may already have IPv6 connectivity.

It is important to note that LACNIC has an address policy that applies exclusively to ccTLDs, under the name of “Micro-Assignments to Critical Infrastructure”. This policy allows a ccTLD to easily obtain provider-independent (PI) addresses, independent even from the organization hosting the ccTLD (for example an academic network), and this provides greater freedom of action when routing.

LACNIC’s policies on IPv6 for critical infrastructure can be found at: http://www.lacnic.net/en/politicas

Address request forms can be found at: http://www.lacnic.net/templates/isp-v6-template-en.txt

Accessing tools through IPv6:

A ccTLD offers their clients and the community a set of tools which should be accessible over IPv6. This set of tools includes: website, WHOIS queries, e-mail service, etc.

Conclusions:

The adoption of IPv6 by domain name registries, particularly by ccTLDs, is a critical step for the adoption of the protocol. Three elements have been identified for the adoption of the IPv6 protocol at a ccTLD that will allow satisfying the expectations of its clients and the community in general.