Quizás, la estrategia preferida para la transición hacia las arquitecturas IPv6 es dual-stack: cada nodo opera simultáneamente con IPv4 e IPv6. Esto permite una transición progresiva uno a uno manteniendo la operación de la red y permitiendo administrar las transiciones.
Es particularmente útil sobre todo porque algunas aplicaciones requieren ser modificadas para operar sobre IPv6 y de esta manera al mantener ambos stacks operativos las aplicaciones viejas o que aún están pendientes de ser actualizadas pueden seguir operando sin dificultades, mientras que las aplicaciones nuevas o actualizadas comienzan a operar preferentemente sobre IPv6.
Hay disponible una API (Application Programming Interface) que soporta requerimientos DNS para IPv4 e IPv6 y permite responder a diferentes situaciones:
- Una aplicación que no soporta IPv6 o está forzada a utilizar IPv4, hace una solicitud DNS de un registro tipo A para IPv4.
En consecuencia la aplicación enviará su solicitud de servicio utilizando IPv4 como protocolo de transporte. El servidor DNS responderá enviando exclusivamente la dirección IPv4 correspondiente al nombre que se consulta.
- Una aplicación que soporta solamente IPv6 o prefiere utilizar IPv6 operará sobre IPv6.
La aplicación envía una solicitud exclusivamente de un registro AAAA con lo que obtendrá una dirección IPv6.
En consecuencia la aplicación establecerá la conexión con el servidor utilizando IPv6 como protocolo de transporte en capa de red.
Esto también se aplica cuando el dispositivo solamente tiene una dirección IPv6 configurada.
- Una aplicación que puede operar indistintamente con IPv4 o IPv6. Para cada nombre que debe resolver se envía una solicitud DNS que requiere los registros de ambos versiones de direcciones (IPv4 e IPv6).
El servidor DNS responde enviando todas las direcciones IP disponibles (v4 y/o v6) que están asociadas a ese nombre.
Ya con la información de ambos protocolos, es la aplicación la que elije utilizar una u otra. El comportamiento propuesto por defecto (RFC 3484) es utilizar la dirección IPv6, y por lo tanto operar con paquetes IPv6. Este comportamiento debiera ser posible de modificar a nivel del nodo.
Cisco IOS soporta la operación en modo dual-stack tan pronto como ambos protocolos están configurados en una interfaz. A partir de ese punto puede reenviar ambos tipos de tráfico.
Eso puede realizarse tanto cuando se asignan direcciones estáticas o por un proceso de configuración dinámica o de autoconfiguración.
Enlaces relacionados
¿Por qué insisto tanto en la importancia de ICMPv6 en las redes IPv6?
Básicamente porque hay una cantidad significativa de procedimientos esenciales para la operación de la red que dependen del intercambio de mensajes ICMPv6.
¿Cuáles son esos procedimientos?
Path MTU Discovery (PMTUD)
Una de las innovaciones que introduce ICMPv6 es el reemplazo del procedimiento de fragmentación de paquetes IPv4 por el descubrimiento del MTU de la ruta.
Para realizar este descubrimiento el dispositivo origen de la comunicación genera paquetes utilizando el MTU de su interfaz y si en la ruta hay un enlace con un MTU menor el dispositivo correspondiente le responde con un mensaje ICMPv6 Tipo 2 (packet too big) que incluye el MTU del enlace que causa el descarte de modo tal que la terminal de origen pueda ajustar su MTU al menor MTU de la ruta.
El filtrado de este tipo de mensajes ICMPv6 imposibilita la negociación y potencialmente podría dificultar la operación de aplicaciones sobre rutas que tienen MTUs limitados.
Una posibilidad es activar, cuando es posible, la opción "Guaranteed Not To Be Too Big" que genera paquetes de la longitud mínima soportada por IPv6: 1280 bytes. De este modo no se requiere PMTUD.
Neighbor Discovery (ND)
En redes IPv6 no hay operación de ARP. El descubrimiento de la dirección MAC de las terminales destino, junto a otras operaciones que optimizan la operación de la red ha sido incorporado en el procedimiento para descubrimiento de vecino.
Este procedimiento le permite a una terminal IPv6:
- Obtener la dirección de capa de enlace de un vecino.
- Encontrar los routers presentes en el segmento.
- Detectar vecinos IPv6.
- Desarrollar tareas de renumeración.
Con este propósito se utiliza un conjunto de mensajes ICMPv6:
- Tipo 133 - Router solicitation.
- Tipo 134 - Router advertisement.
- Tipo 135 - Neighbor solicitation.
- Tipo 136 - Neighbor advertisement.
- Tipo 137 - Redirect message.
El procedimiento de descubrimiento de vecinos es esencial para el proceso de elaboración de la comunicación extremo a extremo y se asienta en la utilización de direcciones multicast específicas que reciben la denominación de “solicited-node”.
Estos procesos se corren exclusivamente dentro del segmento de red local (las direcciones solicited-node son multicast de alcance local, no ruteable), por lo que su utilización es crítica solamente en la red local.
Autoconfiguración stateless
El proceso de autoconfiguración stateless es una de las características propias de IPv6 que permite la autoconfiguración IP de los puertos sin necesidad de la presencia de un servidor en la red. Este procedimiento también está basado en la operación de ICMPv6.
Los routers utilizan paquetes ICMPv6 Tipo 134 (Router Advertisement) para anunciar su presencia y los prefijos de red que están disponibles sobre el segmento. Los terminales utilizan estos mensajes para aprender prefijos /64 (tanto globales como locales) y luego derivar automáticamente el ID de nodo de 64 bits para completar la dirección que utilizará el puerto.
Por otra parte los terminales al inicializar su placa de red envían mensajes ICMPv6 Tipo 133 (Router Solicitation) para solicitar información de configuración de algún router disponible en el segmento de red.
Este proceso está diseñado para posibilitar la implementación de IPv6 en redes en las que no hay acceso a un servicio DHCPv6 y están compuestas por nodos tipo thin clients con pocos recursos de memoria y procesamiento.
Por ser una función básica de IPv6, no requiere recursos adicionales en los nodos y permite la implementación masiva de nodos con configuración IPv6 automática.
Duplicated Address Detection (DAD)
Procedimiento que utiliza paquetes ICMPv6 Tipo 135 (Neighbor Solicitation) durante los procesos de autoconfiguración para verificar si otro nodo en la red ya está utilizando la dirección IPv6 que ha definido utilizar antes de hacerla operativa.
Este procedimiento se utiliza en los procesos de autoconfiguración para asegurar que se utilicen IDs de nodo únicos en el segmento de red. Su alcance es exclusivamente el segmento de red local.
Neighbor Redirect
Mensajes utilizados en segmentos de red que cuentan con más un de gateway que son enviados por un router gateway a la terminal origen de tráfico destinado a una red remota que tiene una mejor ruta accesible a través de otro router presente en el mismo segmento.
Para esto el gateway envía mensajes ICMPv6 tipo 137 (Redirect) con el propósito de redirigir los paquetes IPv6 a otro router en el mismo segmento que tiene una mejor ruta de salida.
Como ocurre en el caso de IPv4, esta funcionalidad de redireccionamiento puede poner en riesgo la seguridad de la red por lo que se aconseja desactivarla.
Renumeración
La implementación de mensajes ICMPv6 Tipo 134 (Router Advertisement) permite desarrollar de modo automático procesos de renumeración de los segmentos IPv6 que aplican autoconfiguración stateless ya que permiten anunciar 2 prefijos para el mismo segmento, uno que se denomina válido y otro preferido.
Acotando el período de validez del prefijo que se debe abandonar el segmento progresivamente migra hacia el prefijo preferido.
Mensajes de echo
Como ocurre en redes IPv4, Ping es un programa también disponible en arquitecturas IPv6 que utiliza paquetes ICMPv6.
En este caso se trata de paquetes ICMPv6 Tipo 128 (Echo Request) y Tipo 129 (Echo Reply).
Enlaces de referencia
