Mecanismos de Transición a IPv6

Introducción

El camino hacia la implementación total de IPv6 en Internet necesariamente pasará por un periodo de transición, en el cual convivirán tanto IPv4 como IPv6 en la red. Ya hoy día estamos viviendo ese momento, puesto que, como comentábamos en artículo anterior, ya no existen bloques de direcciones disponibles a nivel de la IANA.

Cuando se habla de transición se piensa en escenarios en los cuales se hace necesaria la interoperabilidad entre redes sólo IPv4 con redes sólo IPv6, y viceversa; a diferencia de lo que sería un proceso de “migración” en el cual se apagaría la red antigua para amanecer un día con la nueva totalmente desplegada. Este escenario de migración resulta impensable debido entre otras cosas a la complejidad que traería dar ese paso, así, de un zarpazo. ¿Podemos imaginarnos un día sin Internet en el planeta?... ¿Estamos todos y cada uno de los usuarios y dispositivos preparados para este cambio?... Obviamente esto se llevará tiempo, años, quizá décadas o más de un siglo… quizá los que estamos escribiendo y leyendo este artículo al día de hoy no vivamos una Internet sin IPv4.

Por ello se han diseñado diferentes mecanismos de transición, cuyo objetivo principal es la interoperabilidad entre redes IPv4 e IPv6, como se mencionó arriba. Cada mecanismo tiene sus ventajas y desventajas, y algunos son más populares que otros. El tema es que ya existen redes y una Internet que habla IPv6, a las cuales podemos acceder mediante las opciones que nos presentan dichos mecanismos. En este artículo vamos a describir los más importantes, finalizando con el howto para la configuración y una pequeña demostración del mecanismo basado en acceso por tunnel brokers, con el cual nos conectaremos a esa Internet que solo habla IPv6 y que ya lleva rato disponible para entremos a surfear por ella. 

Dual Stack

Uno de los primeros mecanismos de transición de IPv4 a IPv6 implementados, y quizá el más popular hoy día, es la Pila Dual (Dual Stack). Le idea es muy simple: cada nodo en la red implementa, al mismo tiempo, la pila de protocolos de IPv4 e IPv6, compartiendo los mismos recursos a nivel físico y de enlace, y en las capa superiores (TCP, UDP en capa 4, y los diversos protocolos de la capa 5 o capa de aplicación). En la Figura 1 se ilustra la idea.

Figura 1: Pila Dual IPv4 + IPv6

Los sistemas operativos comunes soportan el mecanismo del Dual Stack desde hace años. En el caso de Microsoft Windows, ya con la versión XP se soportaba Dual Stack con la aplicación de un parche. En adelante, desde la versión Windows Vista, el soporte de Dual Stack para IPv6 viene nativo en el sistema operativo. La evidencia la observamos como ejemplo en la configuración de propiedades del dispositivo de red en el Panel de Control de Microsoft Windows 7, observando la posibilidad de configurar propiedades tanto de IPv4 como de IPv6. Asimismo, al ejecutar el comando ipconfig se observa el soporte del Dual Stack, verificando direcciones tanto IPv4 como la correspondiente IPv6 de enlace local (fe80::), que, como comentamos en artículo anterior, se autoconfigura tomando como semilla la dirección MAC de la interfaz. Todos estos detalles se resaltan en la figura a continuación.

 Figura 2: Verificación del Soporte de Dual Stack en Microsoft Windows 7

Ahora bien, una pregunta que puede surgir en este momento es: ¿Podemos navegar por Internet con IPv6 solamente al tener activo este mecanismo del Dual Stack? La respuesta es no, puesto que además del soporte para configuración de una dirección IPv6, se debe estar conectado a un router o gateway que nos lleva hacia esta nueva red. Sin embargo destacamos que esta posibilidad no sería tan sencilla sin el soporte del Dual Stack. Incluso, en los mecanismos de transición que veremos más adelante, al menos el nodo de borde de la red debe soportar Dual Stack para dar soporte de conectividad hacia IPv6 a aquellos nodos que solo entiendan IPv4.

Pensemos ahora en las aplicaciones que se ejecutan sobre un nodo con Dual Stack. En general tendremos las siguientes reglas de funcionamiento:

• Para aplicaciones que sólo soporten IPv4 – Sólo usa la pila de IPv4
• Para aplicaciones que soportan IPv6:
  • Si la búsqueda DNS del destino resuelve direcciones IPv4, entonces se usa IPv4
  • Si el DNS resuelve direcciones de destino IPv6, entonces se usa IPv6
  • Se le dará prioridad al uso de IPv6

Algo semejante a lo anterior podríamos mencionar para el caso de un router con Dual Stack. Se pueden programar reglas que envíen tráfico basado en el tipo de IP, dándole prioridad a aquellas rutas alcanzables basadas en IPv6.

Mecanismos Basados en Traducción

Las técnicas de traducción de protocolos y direcciones se describen originalmente en los RFCs 2765 y 2766. El objetivo principal es proveer enrutamiento transparente para que nodos en redes IPv6 se puedan comunicar con nodos en redes IPv4, y viceversa.

Los principales mecanismos de transición a IPv6 basados en traducciones se engloban en los llamados NAT-PT (Network Address Translation—Protocol Translation), haciendo alusión a que se traducen tanto las direcciones como los protocolos. Un Gateway NAT usa un pool de direcciones IPv4 unívocas y mapea éstas con direcciones IPv6. En estos mecanismos no se requiere hacer ningún cambio en los nodos finales, lo cual representa una ventaja frente a otros mecanismos como el Dual Stack o los basados en túneles, en los cuales se requiere soporte de IPv6 en ciertos nodos claves en la red, no solo los gateways. En el RFC 2766 se desglosa esta idea global de los mecanismos de traducción en las siguientes específicas:

• NAT: Network Address Translation – Se traducen direcciones IP, y los checksums de cabecera en IP, TCP, UDP e ICMP.
• NAPT: Network Address Port Translation – Adicional a los campos traducidos en NAT, se traducen además parámetros como los puertos TCP, UDP y los tipos de mensajes  
• NAT-PT: Network Address Translation and Protocol Translation – Se traducen paquetes IPv6 completos en paquetes IPv4 equivamentes, y viceversa.
• NAPT-PT: Network Address Port Translation and Protocol Translation – Permite que host IPv6 se puedan comunicar con hosts IPv4 usando una única dirección IPv4.

La Figura 3 ilustra el flujo de comunicación en el mecanismo NAPT. Como vemos, el elemento clave es el Gateway, que hace todo el proceso transparente para los nodos de los extremos. En este ejemplo Ford es un host IPv6 con la dirección ABCD:BEEF::2228:7001. Del otro lado del NAPT, Marvin tiene la dirección IPv4 120.140.160.101. Al Gateway NAPT se le ha asignado el pool de direcciones IPv4 120.10.40.0/24. Ford inicializa una sesión con Marvin enviando un paquete al prefijo destino.

Figura 3: Flujo de comunicación en NAPT

::120.140.160.101, en el puerto 23 (Telnet). Recordemos que el prefijo ::/96 es un prefijo estándar ideado para escenarios de transición para convivencia de nodos IPv4 e IPv6. Al advertir el prefijo ::/96, el Gateway enruta cualquier paquete enviado  con este prefijo mediante NAPT. Ford utiliza su dirección IPv6 con el número de puerto 3056 (paso 1). El Gateway NAPT ahora asigna una dirección IPv4 y un número de puerto del pool disponible. Supóngase que se usará la dirección 120.10.40.10. El nuevo paquete que sale del Gateway NAPT hacia Marvin tiene la dirección IP origen 120.10.40.10, puerto 1025, y la dirección de destino 120.140.160.101 (Marvin), en el puerto 23 (Telnet).  Cuando Marvin responde, éste envía el paquete con la dirección IP origen 120.140.160.101, puerto 23, a la dirección IP destino 120.10.40.10, puerto 1025. El Gateway NAPT traduce el paquete de acuerdo a los parámetros almacenados en su caché durante la sesión, y lo envía con dirección IPv6 origen ::120.140.160.101, puerto 23, a la dirección IPv6 destino ABCD:BEEF::2228:7001, puerto 3056 .

Mecanismos Basados en Túneles

Los mecanismos basados en túneles, así como los mecanismos vistos anteriormente basados en técnicas de traducción, tienen en común la finalidad de conectar islas IPv6 a través de la nube pública actual basada en IPv4. Si bien podríamos tener el escenario inverso (conectar islas IPv4 a través de la nube IPv6), éste no es tan común hoy día.

Recordemos que un túnel en redes no es más que el envío de un paquete de un protocolo de extremo, encapsulado en un paquete del protocolo de tránsito. Lo nodos de los extremos del túnel deben soportar ambos protocolos, de manera que entienda y procese los paquetes de cada lado, es decir, los dispositivos de borde deben soportar Dual Stack. La Figura 4 ilustra este proceso de encapsulado. Cuando un paquete IPv6 va encapsulado en un paquete IPv4, en la cabecera del paquete IPv4 se codifica el número de protocolo 41 (IPv6).

Figura 4: Encapsulado del paquete IPv6 en un paquete IPv4

La Figura 5 ilustra la situación de conexión de islas IPv6 a través del entunelado por una nube IPv4; R1 y R2 son los extremos del túnel, y por ende deben ser nodos Dual Stack.

Figura 5: Entunelado y encapsulado

A continuación pasamos a describir las técnicas más comunes basadas en túneles para los mecanismos de transición diseñados para IPv6.

Túneles de configuración automática: 6to4

En el RFC 3056 “Connection of IPv6 Domains via IPv4 Clouds” se especifica un mecanismo para la interconexión de islas IPv6 a través de la nube IPv4 sin la configuración explícita de un túnel. Este mecanismo se llama 6to4. La nube IPv4 se trata como un enlace punto a punto, y las islas IPv6 se comunican a través de “enrutadores 6to4”, también conocidos como “gateways 6to4” o “relay 6to4”. Sólo estos gateways necesitan tener soporte 6to4, ningún cambio se necesita en el resto de los nodos en la red. Los paquetes IPv6 se encapsulan en paquetes IPv4 en los gateways. Al menos una dirección IPv4 pública se requiere para la configuración. La IANA asignó el prefijo especial 2002::/16 para la configuración de túneles 6to4.

Para ilustrar cómo funciona, veámoslo directamente con un ejemplo, mostrado en la Figura 6. La figura muestra diferentes caminos posibles de comunicación. Dentro del Site 1 los hosts A y B se pueden comunicar usando IPv6. Para comunicarse con el host C en el Site 2 (otro site 6to4), los paquetes se envían al router R1 del Site 1. R1 encapsula los paquetes en IPv4 y los reenvía al router R2 del Site 2. El router R1 aprende la dirección IPv4 del router R2 a partir de la dirección IPv6 de destino, que al ser del tipo 6to4 tendrá la estructura 2002:<IPv4-R2>:<Subred-Site2>::/64. De ella se puede extraer <IPv4-R2>, que es la dirección IPv4 pública alcanzable de R2, lo cual  hace la red 2002: <IPv4-R2>::/48 una red única. Luego el router R2 desencapsula y re-envía el paquete IPv6 original al host C. Para comunicarse con un hosts sólo-IPv6 en Internet (Internet IPv6), los host A y B envían sus paquetes IPv6 al router R1, este los encapsula en IPv4 y los reenvía al router R3 que se configura como un relay 6to4. R3 desencapsula y reenvía el paquete IPv6 original sobre la estructura de enrutamiento de la nube IPv6 hacia el host D, por ejemplo. El router R1 internamente anuncia el prefijo 6to4 en los mensajes Router Advertisement, RA (previa configuración). Los hosts IPv6 en el Site 1 usan RA como autoconfiguración Stateless de sus direcciones IPv6, lo cual significa que simplemente toman el prefijo de la forma 2002:<IPv4-R1>:<Subred-Site1>::/64 anunciado por R1. Para conectar una red 6to4 con Internet IPv6, es conveniente evaluar y configurar manualmente un 6to4 relay. La configuración manual tiene la ventaja de proveer control sobre los relays usados, pero incrementa el trabajo administrativo. En el caso que un relay preconfigurado no esté disponible, otro relay necesitará ser configurado.

Figura 6: Funcionamiento del túnel 6to4

Conexión a través de Tunnel Broker

Un Tunnel Broker se puede visualizar como un proveedor virtual para acceso a Internet con IPv6 para usuarios que tienen acceso a Internet con IPv4. La modalidad de conexión con Tunnel Broker se especifica en el RFC 3053. La Figura 7 ilustra cómo funciona la modalidad de conexión a través de Tunnel Broker.

Un usuario que desee una conexión a IPv6 se registra con el Tunnel Broker. El Tunnel Broker maneja el establecimiento, mantenimiento o eliminación del túnel en nombre del usuario. El Tunnel Broker puede compartir la carga de datos entre diferentes servidores de túnel (Tunnel Servers). El Tunnel Broker envía la información de la configuración al Tunnel Server  a través del cual desea establecer, cambiar o borrar un túnel. El Tunnel Broker debe ser alcanzable mediante IPv4, aunque también podría ser por IPv6, pero esto último no es mandatorio. La comunicación entre el Tunnel Broker y el Tunnel server puede ejecutarse sobre IPv4 o IPv6.

Un Tunnel Server es un router Dual Stack conectado a la Internet Global. Cuando éste recibe información de configuración desde el Tunnel Broker, éste establece, cambia, o borra el extremo del servidor del túnel.

El cliente es un host o router Dual Stack conectado a Internet con IPv4. El Tunnel Broker provee control de acceso para el uso del servicio de tunneling, para ello exige el registro y la autenticación de los clientes. Una vez el cliente es autorizado, éste provee su dirección IPv4, un nombre para el registro de su dirección IPv6 en DNS, y una indidación de si es un host o un router. Si es un router, debe proveer información adicional, como por ejemplo la cantidad de direcciones IPv6 que desea distribuir o manejar en su red. Con este información el Tunnel Broker asignará un bloque IPv6 con el tamaño de prefijo adecuado.

El Tunnel Broker finalmente realiza las siguientes tareas:

• Selecciona un Tunnel Server como punto de salida del túnel. Podría seleccionar más de uno e implementar algún criterio de carga compartida (load sharing)
• Selecciona un prefijo para el cliente, el cual puede ser de cualquier longitud. Los tamaños de prefijo más comunes son: /48 (site prefix), /64 (subnet prefix) o /128 (single host).
• Definir un tiempo de vida para el túnel.
• Registrar la dirección IPv6 global asignada en el DNS.
• Configurar el Tunnel Server.
• Enviar la configuración al cliente, la cual incluye los parámetros del túnel y los nombres registrados en el DNS.

De esta manera se concluye la configuración del túnel. Desde ese momento los clientes tendrán acceso a todas las redes IPv6 a las cuales el Tunnel Server tiene acceso.

Figura 7: Funcionamiento del Tunnel Broker

El modelo del Tunnel Broker está diseñado para redes IPv6 pequeñas y aisladas, y especialmente para host IPv6 individuales o domésticos. Además para su uso se debe tener una dirección IPv4 pública alcanzable desde el Tunner Server seleccionado.

Existen varios ISPs y operadores de red que dan el servicio de Tunnel Broker para IPv6. Entre los más conocidos especialmente dedicados a IPv6, están SixXS (https://www.sixxs.net), ARRNet (http://broker.aarnet.net.au) y Hurricane Electric (http://he.net). Este último distribuye el prefijo específico 2001:470::/32.  Al final de este artículo se muestra un ejemplo de configuración del túnel con Hurricane Electric, demostrando la posibilidad de acceso a Internet con IPv6 a través de este servicio de Tunnel Broker.

Demostración: Conexión a Internet con IPv6 mediante Tunnel Broker

En este apartado se describe una pequeña demostración de una conexión a Internet con IPv6 mediante la configuración de un túnel con el Tunnel Broker Hurricane Electric. En ésta se verifican los pasos y el modelo de conexión descritos anteriormente sobre los Tunnel Brokers. A continuación los pasos a seguir:

1. Visitar el sitio en Internet del Tunnel Broker Hurricane Electric (http://he.net). Seleccionar la opción Free IPv6 Tunnel Broker en el recuadro Quick Links.

   

2. En el recuadro Tunnelbroker Login seleccionar [Register]. Completar el proceso de registro para tener una cuenta de Hurricane Electric. Una vez se haya completado el registro y validado el correo electrónico, volver a este sitio (Tunnelbroker Login) e iniciar sesión con las credenciales creadas.

   

3. Una vez iniciada la sesión, se visualiza en la parte inferior los túneles que se han creado hasta el momento. Los usuarios comunes pueden crear hasta 5 túneles. Para crear un túnel nuevo seleccione la opción Create Regular Tunnel en el recuadro de la izquierda User Functions.

   

4. Para iniciar el proceso de creación del túnel, el Tunnel Broker debe validar que la dirección IPv4 desde la que nos estamos conectando es alcanzable, y se puede intercambiar tráfico ICMP con ella sin problemas. Para ello se coloca dicha dirección (detectada por el sitio) en el recuadro blanco “IPv4 End Point”. Luego de la verificación, el mensaje en el recuadro verde indica que dicha dirección IP es un potencial extremo para el túnel que nos llevará a la Internet global con IPv6. Luego de un click en el botón [Create Tunnel] se generan los parámetros del mismo, que se describen en el siguiente paso.

5. Se obtienen los parámetros del túnel. Se especifican las direcciones IPv4 e IPv6 de los extremos (cliente o nuestra máquina, y servidor o el Tunnel Server del Tunnel Broker). Adicionalmente se recibe un prefijo para asignación de direcciones IP en nuestra red; en este ejemplo se recibión un /64, más específicamente el prefijo 2001:470:1f11:a63::/64. Dicho prefijo se puede distribuir internamente mediante mecanismos como DHCPv6 o RA (Router Advertisements).

6. Finalmente, para la creación del túnel como tal se deben ejecutar los scripts correspondientes en el cliente. Dichos scripts son provistos por el Tunnel Broker con los parámetros del túnel dados en el paso anterior. En nuestro caso estábamos conectados desde un cliente con sistema operativo Linux, por lo que seleccionó el script correspondiente a este sistema.

   

7. Luego de ejecutar el script, se visualiza la configuración de la red, y se observan las nuevas interfaces virtuales con los parámetros. En la figuras a continuación se muestran el antes y el después de la ejecución del script.

Antes de la ejecución del script:

Después de la ejecución del script: aparece la interfaz nueva interfaz he-ipv6, con la dirección IPv6 2001:470:1f10:a63::2/64

8. Se verifica la conexión a la Internet Global mediante un ping al DNS IPv6 provisto por Hurricane Electric (2001:470:20::2), y navegando por sitios “sólo-IPv6” conocidos en Internet, como lo es http://ipv6.google.com.

Finalmente se verifica el soporte tanto de IPv4 como IPv6 global en nuestra máquina, visitando sitios como ipv6-test.com