La problemática asociada a 6to4 y alternativas para traducción de direcciones
Fuente: Wikipedia Commons
En la transición a IPv6, la solución idónea para terminales de redes debería ser la implementación simultanea de ambas versiones del protocolo IP, técnica denominada Dual-Stack, con lo que el sistema quedaría con conectividad nativa tanto de IPv4 como de IPv6. Sin embargo, si un sistema no puede acceder a conectividad IPv6 nativa, se puede utilizar la red IPv4 para conectarse a la Internet IPv6.
6to4 se encuentra entre las técnicas más usadas para realizar las conversiones, junto con Teredo y los tunel brokers. 6to4 fue diseñado para permitir conectividad IPv6 aún sin la cooperación (soporte) de los proveedores de servicios de Internet, pudiendo operar, por ejemplo, en un router para dar conectividad a toda un red o a una máquina en particular.
La operatoria involucra la utilización de una dirección IP versión 4 pública, con la cual se realizan combinatorias de direcciones IPv6 que contienen embebida la dirección IPv4 pública configurada en el router. Todas estas direcciones IPv6 asociadas tienen el prefijo 2002::/16. De esta manera, cuando es necesario enviar un paquete IPv6 mediante la red IPv4, el router envía el paquete IPv6 dentro de un paquete IPv4 a un router 6to4 conocido como relay.
Lamentablemente, 6to4 presenta problemas serios debido a su diseño ya que se deben utilizar relays públicos que muchas veces presentan errores de configuración. Esto se debe a que los operadoradores de los routers 6to4 no tienen control de cuáles hosts hacen uso del servicio, por lo que proceden a limitar erróneamente el acceso a sus routers con el fin de controlar el tráfico en su red. De esta forma no es posible garantizar que un host 6to4 sea alcanzable por todas las conexiones IPv6 nativas.
Esta problemática ha sido estudiada en los laboratorios de RIPE NCC, (6to4 - How Bad is it Really?) que han logrado mensurar tasas de hasta un 20 por ciento de fallas en la conexión al dominio ripe.net desde redes que implementan 6to4.
Debido a ello, actualmente se desaconseja implementar este tipo de soluciones, y se sugiere optar por alternativas como, 6rd (IPv6 Rapid Deploy), que es una variante o derivación de 6to4, pero que corrige los problemas de arquitectura inherentes a su predecesor.
En 6rd, el proveedor de servicios Internet (ISP) implementa un prefijo IPv6 propio , lo que garantiza que todos los host 6rd serán alcanzables desde todas las direcciones IPv6 nativas, y debido a que no hay otros servidores de reencaminamiento entre medio, el proveedor mantiene toda la responsabilidad y control sobre la calidad de servicio que recibien sus usuarios.
Fuente: Wikipedia Commons
6rd tiene un importante caso de éxito ya en su formulación, a partir de la experiencia en 2007 de Free, el segundo mayor proveedor de acceso a Internet de Francia, que aunque no tenía planes en el corto plazo de ofrecer servicios IPv6, gracias al convencimiento de Rani Assaf, su oficial en jefe de Tecnologías, quien inmediatamente decidió implementar la solución. Cinco semanas después, el ISP estaba ofreciendo servicios IPv6 a sus clientes.
6 Rapid Deploy se convierte en protocolo público en marzo de 2010 ( Standards Track RFC 5969), mientras que en octubre de 2010 es liberado por Comcast una solución de código libre/abierto para dispositivos de redes caseras, basada de Open-WRT.
Fuentes: 6to4, How bad is really? RIPE Labs