Mecanismos de transición IPv6

Los mecanismos de transición a IPv6 son las tecnologías que facilitan y facilitarán la transición de Internet de su infraestructura IPv4 al sistema de direccionamiento de nueva generación IPv6. Concretamente, hay métodos que permitirán a hosts conectados únicamente a IPv4 ó IPv6 acceder a recursos sólo disponibles utilizando el otro protocolo.

La Internet Engineering Task Force (IETF) gestiona a los grupos de trabajo y discusiones hacia los Internet Drafts y procesos Request for Comments para desarrollar estos métodos. Algunos mecanismos básicos de transición a IPv6 están ya definidos en la RFC 4213.

Stateless IP/ICMP Translation (SIIT)

La traducción IP/ICMP sin estado (asíncrona) traduce entre los formatos de cabecera IPv6 y IPv4. El método SIIT define un rango de direcciones IPv6 llamado direcciones IPv4-traducidas (IPv4-translated). Es el prefijo (subred) ::ffff:0:0:0/96 y se puede escribir como ::ffff:0:a.b.c.d, donde la dirección en formato IPv4 a.b.c.d se refiere a un nodo "IPv6-disponible" (IPv6-enabled). Se ha elegido el prefijo para que diera un checksum de 0, evitando cambios en el checksum de la cabecera del protocolo de transporte.^[1]

El algoritmo permite que hosts IPv6 sin dirección IPv4 asignada se comuniquen con host sólo-IPv4. La asignación de direcciones y los detalles del encaminamiento no se abordan en la especificación.

La especificación es un producto de un grupo de trabajo IETF NGTRANS, y se redactó inicialmente en Febrero de 2000 por E. Nordmark de Sun Microsystems. La especificación estándar del protocolo está en la RFC 6145.^[2]

6rd

6rd es un mecanismo para facilitar un rapido despliegue de IPv6 a través de infraestructuras IPv4 de los Proveedores de Servicios de Internet (PSI, o las siglas ISP en inglés). Utiliza traducciones asíncronas entre direcciones IPv4 e IPv6, y transmite paquetes IPv6 dentro de túneles IPv4 automáticos que siguen las mismas rutas optimizadas entre nodos como cualquier otro paquete IPv4.

Ha sido utilizado para el primer gran despliegue de un servicio IPv6 con direcciones nativas a finales de 2007 (RFC 5569^[3] ). La especificación estándar del protocolo está en la RFC 5969.^[4]

Transport Relay Translation (TRT)

La RFC 3142 define el método Traducción en capa de Transporte (Transport Relay Translation o TRT), reservando para él el rango unicast C6::/64. Es el método más común de NAT-PT/NAPT-PT; se basa en la translación entre los registros DNS AAAA y A conocida como DNS-ALG, definida en la RFC 2694.

NAT64

NAT64 es un mecanismo que permite a hosts IPv6 comunicarse con servidores IPv4. El servidor NAT64 dispone de al menos una dirección IPv4 y un segmento de red IPv6 de 32-bits (por ejemplo 64:ff9b::/96, véase RFC 6052, RFC 6146). El cliente IPv6 construye la dirección IPv6 destino utilizando el rango anterior de 96 bits más los 32 bits de la dirección IPv4 con la que desea comunicarse, enviando los paquetes a la dirección resultante. El servidor NAT64 crea entonces un mapeo de NAT entre la dirección IPv6 y la dirección IPv4, permitiendo la comunicación.^[5]

DNS64

Cuando un Servidor DNS con funcionalidad DNS64 recibe una petición de dominio por registro AAAA, pero sólo dispone de registros A, crea registros AAAA a partir de los registros A. La primera porción de la dirección IPv6 creada apunta a un traductor IPv6/IPv4, y la segunda incluye la dirección IPv4 del registro A. El traductor en cuestión suele ser un servidor NAT64.^[6]

Hay dos puntos importantes a tener en cuenta con el mecanismo de transición:

• Sólo funciona cuando se utiliza DNS para encontrar la dirección del host remoto. Si se utilizan direcciones IPv4 directamente, el servidor DNS64 no podrá estar involucrado.
• Dado que el servidor DNS64 responde con registros no especificados por el propietario del dominio, la validación DNSSEC contra el propietario fallará, salvo que el servidor DNS64 que hace la traducción sea asímismo propietario del dominio.

Proyectos

Los mecanismos mostrados a continuación están actualmente en discusión o han sido abandonados por la IETF.

Dual-Stack Lite (DS-Lite)

DS-Lite

Debido al agotamiento de las direcciones IPv4,^[7] se diseñó Dual-Stack Lite para permitir a un proveedor de servicios de Internet (ISP) omitir la asignación de una dirección IPv4 al equipo local de cliente (CPE). En su lugar, asignan únicamente direcciones IPv6 globales. (Un entorno Dual Stack normal requiere la asignación de direcciones públicas IPv4 e IPv6).

El CPE distribuye direcciones IPv4 privadas en la LAN del cliente, de igual modo que un dispositivo NAT. La subred es elegida aleatoriamente por el cliente, tal como en el modelo NAT. La diferencia estriba en que en lugar de realizar un NAT, el CPE encapsula el paquete IPv4 dentro de un paquete IPv6. El CPE utiliza su conexión IPv6 para enviar el paquete a un Carrier Grade NAT (CGN) del ISP, que sí dispone de una dirección IPv4 pública. Se desencapsula el paquete IPv6, restaurando el paquete IPv4 original; se le aplica NAT al paquete IPv4 y se encamina a la Internet IPv4. El CGN identifica flujos de tráfico únicamente registrando la dirección IPv6 pública del CPE, la dirección IPv4 privada y los puertos TCP o UDP.^[8]

Address plus Port (A+P)

Dirección más Puerto [A+P] utiliza un NAT en la red del cliente (o cerca de él) para acceder a la Internet IPv4. El proveedor de Internet proporciona una dirección IPv4 (como se hace hasta ahora) y un rango de puertos TCP/UDP para el NAT. El tráfico IPv4 de salida es traducido (nateado) utilizando el rango de puertos TCP/UDP disponible, y el proveedor de servicios encaminará los paquetes de vuelta al cliente adecuado utilizando tanto la dirección IPv4 destino como el puerto TCP/UDP de destino. ^{[9] [10]}

4rd

4rd es un mecanismo que permite el despliegue residual de servicios IPv4 sobre redes IPv6. A igual que el 6rd, utiliza mapeos de direcciones asíncronos entre IPv6 e IPv4. Soporta una extensión de la dirección IPv4 basada en puertos de la capa de transporte. Es similar a A+P, pero cada cliente puede tener hasta 4 rangos de puertos, con los puertos derivados algorítmicamente del prefijo IPv6 del cliente.

Obsoletos

Estos mecanismos han sido abandonados por la IETF.

NAT-PT

La Traducción de la Dirección de Red/Traducción de Protoloco (o simplemente 'NAT-PT, del inglés Network Address Translation/Protocol Translation) fue definida en la RFC 2766 pero debido a numerosos problemas, ha quedado obsoleta por la RFC 4966 y en desuso posteriormente. Típicamente se utiliza conjuntamente con un DNS application-level gateway (DNS-ALG).

NAPT-PT

Casi idéntico a NAT-PT y descrito también en la RFC 2766, Network Address Port Translation + Protocol Translation añade traducción de puertos además de la dirección. Se utiliza para evitar que dos hosts en el mismo lado del mecanismo utilicen el mismo puerto al otro lado del mecanismo, lo que puede causar inestabilidad de las aplicaciones y/o fallos de seguridad. Este mecanismo quedó obsoleto por la RFC 4966

Véase también

• Comparativas de soporte IPv6 en Aplicaciones
• Comparativas de soporte IPv6 en Sistemas Operativos

Implementaciones

• stone (software), traductor de puertos para Windows y sistemas Unix.
• faithd, Implementación TRT (sistemas BSD) por el proyecto KAME
• TAYGA, una implementación NAT64 para Linux
• naptd, user-level NAT-PT
• Ecdysis, un gateway NAT64
• Address Family Transition Router, una implementación DS-Lite
• niit
• IVI (second page)
• Microsoft Forefront Unified Access Gateway, un proxy inverso y solución VPN que implementa DNS64 y NAT64

Enlaces externos

• TRT Howto from 2003
• IPv6 - Prospects and problems: a technical and management investigation into the deployment of IPv6
• Network World: Understanding Dual-Stack Lite
• IETF Draft: Framework for IPv4/IPv6 Translation

Referencias

• IPv6 in Practice, Benedikt Stockebrand (2006), ISBN 3-540-24524-3
• RFC 2767, Bump-in-the-Stack
• RFC 3338, Bump-in-the-API
• RFC 3089, Socks-based Gateway