Autor: Roque Gagliano - LACNIC.
Versión 1.1 - 23/12/2008
(Documento en elaboración)
Introducción:
Impulsadas por el agotamiento de las direcciones IPv4, organizaciones a nivel global se encuentran en diferentes etapas de adopción del protocolo IPv6. La resolución de dominios (o DNS) es fundamental para cualquier desarrollo y por lo tanto la adopción de IPv6 por los administradores de dominios de países (ccTLDs) y por toda la cadena de distribución asociada a ellos.
¿Qué es lo que un cliente o la comunidad espera de un ccTLD respecto a IPv6?
Podemos distinguir tres elementos:
Registro AAAA para servidores de dominio:
Este punto busca conseguir la incorporación, en las zonas administradas por un ccTLD, de registros AAAA para los servidores de dominio a los que se realizan las re-delegaciones (los llamados “glue records”). Este registro significará la verificación del sistema de aprovisionamiento del ccTLD, ya sea manual, automático vía web o utilizando algún protocolo como EPP (RFC 4931 da soporte IPv6 para EPP) o API.
El cambio puede incluir modificaciones en las pantallas web, base de datos y en el servicio whois.
Si existen terceras organizaciones que participan en el registro de dominio (“registrars”), estas también deberán actualizar sus sistemas de forma de permitir a sus clientes el registro. El operador ccTLD podría aplicar políticas activas para fomentar la adopción por parte del registrar.
Hay que destacar que el registro de la dirección IPv6 de los servidores de dominio sólo es necesaria si el nombre del servidor se encuentra aguas abajo en la jerarquía de dominio.
Transporte sobre IPv6 para la resolución de nombres:
Este punto involucra dos aspectos, por un lado la adaptación del software de resolución de dominios para su uso con IPv6, aceptando la llegada de conexiones (tanto UDP o TCP según corresponda) sobre IPv6. Todos los softwares de DNS actuales permiten esta función, muchas veces sólo necesitando una pequeña configuración.
El segundo aspecto es la infraestructura de red necesaria para el transporte IPv6. Esta infraestructura puede incluir configuraciones o actualizaciones de routers, firewalls y tránsito IPv6. Generalmente la obtención de tránsito IPv6 constituye la principal barrera para la adopción de el protocolo y debe planificarse con tiempo.
No es necesario el transporte IPv6 para todos los servidores de un ccTLD, actualmente el tráfico IPv6, tanto a nivel consultas como de paquetes, es bajo y puede ser soportado por un pequeña cantidad de servidores. En particular muchos ccTLD ya cuentan con secundarios en organizaciones externas, por lo tanto es importante verificar pues puede suceder que estos secundarios ya cuenten con transporte IPv6.
Es importante notar que LACNIC cuenta con políticas de direcciones exclusivas para ccTLD, bajo el nombre “Microasignaciones IPv6 para Infraestructura Crítica”. Esta política permite la fácil obtención de direcciones independientes del proveedor (PI) por parte de un ccTLD, incluso independiente de la organización que aloja al ccTLD (por ejemplo una red académica), permitiéndole más libertad de acción en el encaminamiento.
Las políticas de LACNIC de IPv6 para infraestructura crítica pueden encontrarse aquí: http://www.lacnic.net/sp/politicas
Los formularios para la solicitud de direcciones pueden encontrarse aquí: http://www.lacnic.net/templates/isp-v6-template-sp.txt
Acceso a Herramientas a través de IPv6:
Un ccTLD ofrece un conjunto de herramientas a sus clientes y a la comunidad, estas herramientas deberían ser posibles de ser accesible sobre el transporte IPv6. Dentro de este conjunto de herramientas se encuentran: sitio web, consultas whois, servicio de correo electrónico, etc.
Conclusiones:
La adopción de IPv6 en los registro de dominios, y en particular en los ccTLD ,constituyen un paso fundamental para la adopción del protocolo. Se han delimitado tres pasos para la adopción de IPv6 en un ccTLD, permitiendo colmar las expectativas de sus clientes y la comunidad en general.
El campo "Total Lengh" que forma parte de la cabecera IPv4, no lo encontramos en la cabecera IPv6... Esto se debe a que, su función es la de contabilizar el tamaño de carga útil del paquete más el tamaño de una cabecera que puede variar. Por lo que, al ser la nueva cabecera de un tamaño fijo, resulta innecesaria la presencia de este campo.