Usted se conecta empleando IPv4 [18.208.202.194] ¿Que tal si prueba el acceso utilizando IPv6?

INICIO INTRODUCCION A IPV6 BIBLIOTECA TECNICA IPV6 EN CUBA CONTACTENOS
   
 
EVENTOS IPV6
DOCTOR IPV6
PREGUNTAS FRECUENTES
ENLACES DE INTERES
 
 

Introducción

Agotamiento direcciones IPv4
Características generales
Direccionamiento
Operación
Cabeceras extensibles
IPSec
ICMPv6
Multicast
Soporte a movilidad
IPv6 en sistemas operativos
Tecnologías de transición
Lecturas recomendadas

Tecnologías de Transición IPv4- IPv6

Desde que se desarrollaron las especificaciones de IPv6, motivadas por el posible agotamiento de las direcciones IPv4 (según tempranas predicciones por parte de IETF), se suponía que la red iba a evolucionar al nuevo protocolo de una manera rápida y ordenada, para lo cual bastaría que cada dispositivo conectado a Internet, tuviera de forma simultánea una dirección IPv4 y otra IPv6. De esta forma, se garantizaba una  transición sencilla y rápida. Sin embargo, esto no sucedio, producto de diversos factores; y lo que parecia un tema simple, derivo en múltiples mecanismos "temporales" para pretender llegar a IPv6. A estos mecanismos se les conoce como tecnologías de transición.

Las tecnologías de transición se clasifican en 3 grupos:

1- Dual stack: En esta red, operan de forma simultanea IPv4 e IPv6. En una red dual stack, ambos protocolos son desplegados completamente y los protocolos de enrutamiento deben llevar los prefijos correspondientes a cada tecnología, de manera transparente. La mayor desventaja de esta aproximación ideal, es que requiere que todo el equipamiento soporte ambos protocolos, lo cual no es la situación real.

2- Túneles: Por medio de esta técnica, se pueden enviar paquetes IPv6 dentro de paquetes IPv4, y viceversa. En la actualidad, Internet es básicamente una red IPv4 con algunas islas IPv6; por tanto, lo mas frecuente es que el trafico IPv6 viaje encapsulado en paquetes IPv4.

La figura anterior muestra el encapsulamiento de paquetes IPv6 en IP4, para conectar 2 hosts IPv6 empleando la infraestructura IPv4 de Internet. Nótese que los routers que enlazan el mundo IPv4 con el mundo IPv6 tienen que ser Dual stack.

Tipos de túneles empleados como tecnologías de transición

4in6: Encapsula tráfico IPv4 en IPv6 (RFC2473)
6in4: Encapsula tráfico IPv6 en IPv4 (RFC4213)
6over4: permite transmitir paquetes IPv6 entre 2 nodos dual stack empleando una red IPv4 que permita multidifusión
6to4: Permite tráfico IPv6 sobre una red IPv4 sin la necesidad de configurar túneles de forma explícita, aunque se mantiene la función de encapsulamiento de IPv6 en IPv4. Servidores especialmente diseñados actúan como relay, permitiendo la comunicación. 6to4 puede ser empleada por un host (el cual requiere dirección IP pública) o por una red (RFC3056)
6rd: Se deriva de 6to4, y propone realizar el despliegue de relays 6rd dentro de la infraestructura de un ISP, empleando para ello el bloque IPv6 unicast del ISP, en lugar del prefijo especial (2001::/16) de 6to4 (RFC5969)
ISATAP: Mecanismo que permite intercambio de tráfico entre nodos dual stack empleando una red IPv4. Es similar a 6over4, pero sin el requerimiento del empleo de multidifusión sobre la red IPv4. Incluye soporte en Windows XP, Windows Vista, Windows 7, Windows Mobile, Linux y algunas versiones de Cisco IOS. (RFC4214)
Teredo: Ofrece conectividad IPv6 total a nodos IPv4 que no tienen conexión directa con una red IPv6. Funciona eficientemente detras de NATs. Emplea protocolo UDP. (RFC4380)
Dual Stack Lite (DS-Lite): Mecanismo que permite a un ISP no asignar direcciones IPv4 a sus clientes, y solamente entregarles direcciones IPv6. El cliente puede escoger un rango privado cualquiera y su trafico viaja hacia la red del proveedor, encapsulado en IPv6 (RFC6333)
Tunnel Setup Protocol (TSP): permite negociar los parámetros de conexión de un cliente y un servidor tunnel-broker (RFC5572)
IPv6 Tunnel Broker: proveen conectividad IPv6 a usuarios finales o redes. Encapsula IPv6 en IPv4, indicandolo por medio del identificador 41 en el campo tipo de protocolo de IPv4 (RFC3053)
Softwires: Mecanismo que permite el uso de algunos de los protocolos existentes (como 6rd o DS-Lite) para proveer conectividad IPv6 en redes IPv4 puras. Se basa en L2TPv2 y L2TPv3. Puede encapsular IPv6 en IPv4, IPv6 en IPv6, IPv4 en IPv6 y IPv4 en IPv4. Puede funcionar detrás de NATs, permite la delegación de prefijos IPv6 y puede crear túneles seguros. Para su funcionamiento, requiere de un iniciador softwires (cliente) y un concentrador softwires (servidor de tunel) (RFC5571)

3- Traducción: Aunque esta no es una técnica deseable a largo plazo, es muy efectiva, pues trabaja realizando traducción de IPv6 a IPv4 y viceversa.

Las técnicas de traducción mas empleadas son:

Stateless IP/ICMP Translation (SIIT): Realiza traducción de encabezados IPv6 a IPv4 y vicersa
DNS64: Mecanismo que entrega a los clientes IPv6 un registro AAAA (aunque solamente exista un registro A. El cliente típico de estas solicitudes es un servidor NAT64 (RFC6147)
NAT64: Mecanismo que permite a los hosts IPv6 comunicar con hosts IPv4. Puede implementarse en modo stateless (siguiendo la RFC6145) o stateful (según la RFC6146)
Stateless NAT64 (Stateless NAT46, IVI): Mecanismo de traslación de direcciones IPv6-IPv4, pero garantizando correspondencia 1:1, en lugar de usar correspondencia 1:muchos como en el NAT stateful. Implementado para la Red China de avanzada (CERNET2)
Transport Relay Translator (TRT): es el mecanismo tradicional de trabajo de NAT-PT, pero requiere de traducciones de DNS de registros AAAA a registros A (RFC 3142)
NAT-PT (eliminado por RFC 4966)
 

Consultas recomendadas en la Biblioteca Técnica:

  • RFC6146 Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers M. Bagnulo, P. Matthews, I. van Beijnum (April 2011) (sección RFC)

  • RFC6147 DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers M. Bagnulo, A. Sullivan, P. Matthews, I. van Beijnum (April 2011) (sección RFC)

  • RFC2473 Generic Packet Tunneling in IPv6 Specification A. Conta, S. Deering (December 1998) (sección RFC)

  • RFC4213 Basic Transition Mechanisms for IPv6 Hosts and Routers E. Nordmark, R. Gilligan (October 2005) (sección RFC)

  • RFC5969 IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification W. Townsley, O. Troan (August 2010) (sección RFC)

  • RFC6081 Teredo Extensions D. Thaler (January 2011)(sección RFC)

  • RFC4380 Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs) C. Huitema (February 2006)(sección RFC)

  • RFC6144 Framework for IPv4/IPv6 Translation F. Baker, X. Li, C. Bao, K. Yin (April 2011)(sección RFC)

  • RFC6052 IPv6 Addressing of IPv4/IPv6 Translators C. Bao, C. Huitema, M. Bagnulo, M. Boucadair, X. Li (October 2010)(sección RFC)

  • RFC4291 IP Version 6 Addressing Architecture R. Hinden, S. Deering (February 2006) (sección RFC)

  • RFC5572 IPv6 Tunnel Broker with the Tunnel Setup Protocol (TSP) M. Blanchet, F. Parent (February 2010) (sección RFC)

  • RFC3053 IPv6 Tunnel Broker A. Durand, P. Fasano, I. Guardini, D. Lento (January 2001)(sección RFC)

  • RFC2473 Generic Packet Tunneling in IPv6 Specification A. Conta, S. Deering (December 1998)(sección RFC)

  • RFC3142 An IPv6-to-IPv4 Transport Relay Translator J. Hagino, K. Yamamoto (June 2001)(sección RFC)

  • RFC6144 Framework for IPv4/IPv6 Translation F. Baker, X. Li, C. Bao, K. Yin (April 2011)(sección RFC)

  • RFC4966 Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status C. Aoun, E. Davies (July 2007)(sección RFC)

  • RFC5571 Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2 (L2TPv2) B. Storer, C. Pignataro, Ed., M. Dos Santos, B. Stevant, Ed., L. Toutain, J. Tremblay (June 2009) (sección RFC)

Lecturas recomendadas en la Biblioteca Técnica