Mecanismos de transición

El protocolo de internet de siguiente generación (IPng), como fue llamado inicialmente IPv6, fue desarrollado por el Grupo Especial sobre Ingeniería de Internet (IETF) para reemplazar al actual protocolo de Internet IPv4. Para poder permitir la coexistencia de IPv6 con IPv4 y la compatibilidad con las redes actuales, el Grupo de Trabajo de Transición a IPng de la IETF ha diseñado herramientas, protocolos y mecanismos que pueden ser utilizados para permitir una transición de redes IPv4 hacia IPv6.

Las estrategias diseñadas se pueden dividir en tres clases:

Pila Dual: La computadora, el servidor y el enrutador en la red pueden manejar una pila de IPv4 y una IPv6 de forma simultánea. Cuando las dos pilas son utilizadas en los nodos conectados a las redes en los cuales ambos protocolos están habilitados simultáneamente, el modo de pila dual provee a los nodos la flexibilidad para establecer sesiones extremo a extremo sobre IPv4 o IPv6.

Túneles: Los túneles permiten a un elemento IPv6 aislado, sea computadora, servidor, enrutador y dominio comunicarse con otras redes IPv6 sobre la infraestructura IPv4 existente. Incluso computadoras IPv6 aisladas pueden establecer sesiones IPv6 extremo a extremo usando IPv4 como la capa de transporte. Los túneles consisten en un encapsulamiento de paquetes IPv6 dentro de paquetes IPv4 para posteriormente enviar estos paquetes encapsulados a un nodo destino IPv4 sobre una red IPv4. El nodo destino realiza la desencapsulación para extraer los paquetes IPv6. Existen distintas técnicas para implementar y establecer túneles sobre IPv4. Es importante señalar que para poder hacer túneles de paquetes IPv6 en IPv4 se requiere que los nodos extremos del túnel soporten Pila Dual.

Traducción de Protocolo: Es posible para los nodos que solo soportan IPv6 en la red IPv6 comunicarse con nodos que solo soportan IPv4 en la red IPv4. Sin embargo, estos mecanismos requieren una traducción de protocolo entre IPv4 e IPv6 en la frontera de los dos tipos de redes.

A continuación se presentan algunos de los mecanismos actuales más sobresalientes.

Encapsulación 4-en-6

El RFC 2473 especifica el modelo y los mecanismos genéricos para encapsulación con IPv6. Aquí los paquetes encapsulados pueden ser de IPv6, IPv4 o de cualquier otro protocolo. El punto de entrada del túnel antepone el encabezado de IPv6, y si se requiere, un o dos encabezados de extensión en frente del encabezado de paquete original. Cualquier encabezado que el punto de entrada anteponga, estos son conocidos como encabezados de túnel IPpv6.

Comúnmente estos túneles con conocidos como 4-en-6, y usualmente se configuran de forma manual pero se pueden automatizar utilizando protocolos como TSP (Protocolo de Establecimiento de Túnel) para permitir una conexión sencilla a un proveedor de conexión por túnel.

Encapsulación 6-en-4

Es un método de transición para migrar de IPv4 a IPv6 que utiliza un túnel para encapsular tráfico de IPv6 sobre enlaces configurados con IPv4 tal como lo describe el RFC 4213. El tráfico 6-en-4 es enviado a través del Internet dentro de paquetes IPv4 cuyos encabezados IP tienen el número de protocolo configurado en 41. Este número de protocolo ha sido diseñado específicamente para encapsulación de IPv6.

En 6-en-4, el encabezado del paquete IPv4 es inmediatamente seguido por el paquete IPv6 que está siendo llevado. Esto se traduce en que el incremento de encabezado de encapsulación es solamente el encabezado de IPv4 de 20 bytes. Teniendo en Ethernet una Unidad Máxima de Transmisión (MTU) de 1500 bytes, pueden ser enviados paquetes de IPv6 de 1480 bytes sin fragmentar. Este mecanismo también es conocido como proto-41 estático ya que utiliza los puntos extremos configurados de forma estática. Existen otros métodos similares como 6-a-4 o 6-sobre-4 que presentan algunas variaciones, como por ejemplo, no utilizar configuración estática en los puntos extremos y en sustitución la información de la dirección IPv4 es obtenida de las direcciones de IPv6 dentro del encabezado de paquete de IPv6.

Mecanismo 6-a-4

El RFC 3056, Conexión de dominios IPv6 a través de nubes IPv4, especifica un mecanismo para que sitios IPv6 se comuniquen entre si sobre una red IPv4 sin un establecimiento de túnel. Este mecanismo es llamado 6-a-4, y en él la red IPv4 de área amplia es tratada como un enlace punto-a-punto unicast, y los dominios IPv6 se comunican vía ruteadores 6-a-4.

Se pretende que este mecanismo sea utilizado durante el período de co-existencia de IPv4 e IPv6 y que no sea usado como una solución permanente. 6-a-4 puede ser usado por un host individual, o por una red local IPv6. Cuando es usado por un host, debe tener una dirección global IPv4 conectada, y el host es responsable de encapsular los paquetes salientes de IPv6 y desencapsular los paquetes que llegan de 6-a-4. Si el host está configurado para reenviar paquetes a otros clientes, comúnmente una red local, es entonces un ruteador.

6-a-4 no facilita la interoperación entre hosts que solo utilicen IPv4 y hosts quesolo utilicen IPv6. 6-a-4 es sólo un mecanismo transparente usado como una capa de transporte entre nodos IPv6.

ISATAP

El Protocolo de Direccionamiento de Túnel Automático Intra-Sitio (ISATAP, Intra-Site Automatic Tunnel Addressing Protocol) está diseñado para proveer conectividad IPv6 entre nodos IPv6, dentro de una intra-red basada principalmente en IPv4, que no tiene un ruteador IPv6 en el sitio.

Con ISATAP, se puede implementar IPv6 en la red corporativa, detrás del firewall, incluso si no se tiene un ruteador IPv6. Inclusive ISATAP permite usar un mecanismo de creación de túneles automático si se están utilizando direcciones IPv4 y NAT. Las direcciones ISATAP incluyen una dirección IPv4 en el identificador de la interfaz EUI-64.

Teredo

Distintos mecanismos de transición trabajan con hosts de IPv6 identificados por direcciones IPv4, sin embargo, estos mecanismos no soportan conectividad IPv6 a hosts aislados detrás de un NAT. Las direcciones privadas no pueden ser usadas en redes públicas como un mecanismo 6-a-4. Acoplar un NAT y un mecanismo de túnel no es escalable y puede producir resultados inesperados, como deterioro en la calidad de la transmisión e inclusive el mismo servidor del túnel se puede convertir en un “cuello de botella” en la trayectoria de transmisión.

Tratando de ofrecer una alternativa a los usuarios privados detrás de un NAT, se propone Teredo para proveer conectividad IPv6 a hosts aislados detrás de un NAT. Teredo provee un túnel automático extremo a extremo a sitios Teredo y ofrece trayectorias a hosts de solo IPv6.

Teredo se compone de tres elementos: un servidor Teredo, un retransmisor Teredo y un cliente Teredo.

El servidor provee su dirección IPv4 al cliente; una vez que el cliente aprende la dirección IPv4, automáticamente construirá la dirección IPv6 del servidor donde la dirección de IPv4 está incrustada. El retransmisor ayuda a los clientes a conectarse a hosts de solo IPv6. Las comunicaciones de hosts solo IPv6 en el “backbone” no están soportadas de forma inmediata. En lugar de eso, el servidor Teredo mediará entre los clientes Teredo y los retransmisores Teredo y seleccionará el apropiado, el cual es seleccionado por la distancia entre el cliente y el retransmisor, así como el número de clientes a los cuales les provee servicio el retransmisor.

El cliente Teredo es un nodo que reside detrás de un NAT y que desea tener conectividad IPv6. Para la configuración de la dirección, el cliente obtiene el prefijo del servidor; especialmente, se requiere que el cliente tenga una dirección IPv4 antes del proceso de calificación con el fin de mantener el mapeo de dirección y número de puerto asociado con el puerto de servicio Teredo.

Estándares para Internet (RFCs)

Los estándares técnicos para Internet son escritos en documentos conocidos como RFCs (Request For Comments) y la organización encargada de producirlos y publicitarlos es la IETF.

Los RFCs son documentos técnicos de estándares que nacen como un “proyecto de Internet”, y tienen un tiempo de vida de 6 meses desde el primer día que los publica la IETF, antes de ser borrados. Esta particular manera de trabajar obliga a los autores del documento a enviar dos veces al año, una versión actualizada del documento para que el trabajo realizado al momento no camine en dirección a la obsolescencia y la consecuente eliminación y olvido.

Los trabajos son elaborados por los grupos de trabajo de la IETF y son evaluados por ellos mismos y por el IESG que es el grupo para orientar el trabajo de ingeniería de Internet. Solo una fracción de todos los RFCs se vuelven documentos de estándar. Los demás especifican versiones obsoletas de estándares actuales, protocolos experimentales, evolución de los protocolos y prácticas (son históricos), proveen una guía que se considera “mejor práctica” o solamente proveen información para la comunidad de Internet.

A continuación se presenta una tabla con los estados posibles de un RFC.

Las siguientes son algunas de las propuestas más destacadas que se han hecho sobre IPv6 y sobre su coexistencia con IPv4:

Estos RFCs pueden ser consultados en la página de la IETF: http://www.ietf.org/.