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
Ya en otras oportunidades, hablando de la arquitectura IPv6, hice referencia a la importancia que adquiere en la operación de IPv6 la versión correspondiente ICMPv6.
Por esto me ha parecido oportuno, y a sugerencia de un grupo de los seguidores de Facebook, realizar una serie de posts en torno al papel que ocupa ICMPv6 en las redes IPv6.
Por eso, en primer lugar, revisemos los aspectos generales del protocolo:
ICMPv6 es en algunos aspectos semejante a ICMPv4 y en otros incorpora nuevas funcionalidades:
- ICMPv6 es parte de IPv6.
- Permite realizar operaciones de diagnóstico y reporte de problemas.
- Utiliza 2 tipos de mensajes: mensajes de error y mensajes de información.
- El paquete ICMP es transportado como contenido de un paquete IPv6 convencional con un valor de next header = 58.
- El paquete ICMPv6 se transporta al final de la cadena de extensiones de encabezado, si la hay, del mismo modo que la información de capa 4.
- El paquete ICMPv6 tiene 4 campos específicos:
* El campo tipo identifica el tipo de mensaje ICMP que contiene.
* El campo código da detalles más específicos sobre el tipo de mensaje que contiene.
* El campo checksum es el resultado del procesamiento del paquete ICMP completo para que el destino pueda verificar la integridad del paquete que recibe.
* En el campo datos se envía información que el receptor puede aprovechar para tareas de diagnóstico u operación.
- ICMPv4 frecuentemente se encuentra bloqueado por políticas de seguridad en redes corporativas como una contramedida de seguridad. ICMPv6 no es diferente, pero tiene la posibilidad de ser asegurado con la implementación de autenticación y encriptación, lo que reduce la posibilidad de un ataque basado en ICMPv6.
Para revisar la variedad de mensajes ICMPv6, en comparación con ICMP en entornos IPv4, sugiero revisar el post "Reconsiderando ICMP".
Bibliografía: Protocolo IPv6 Básico versión 2
Como mencioné en el post anterior, hay 2 soluciones propuestas para aplicar direccionamiento en enlaces punto a punto:
Si bien el uso solamente de direcciones link local es una solución viable y que no requiere ninguna elaboración adicional, tiene sus limitaciones:
- Las herramientas de diagnóstico (ping, traceroute) no se pueden aplicar utilizando estas direcciones.
- No se puede acceder remotamente a través de estas interfaces utilizando un Telnet o SSH.
- Puede utilizarse en entornos eBGP, pero requiere configuración adicional.
En estos casos es entonces conveniente aplicar direccionamiento global. Y entonces volvemos al planteo inicial de esta serie de posts. ¿No es demasiado utilizar prefijos /64?
Hay quienes responden que no, que hay suficiente espacio disponible y se facilita la configuración ya que se puede apelar a la asignación automática de ID de interfaz, y de hecho se utilizan en esos enlaces prefijos /64.
Ahora bien, más allá de la discusión de la necesidad o no de cuidar desde ahora la disponibilidad de direcciones globales es cierto que se trata de segmentos de red que por su propia naturaleza no están destinados a crecer en cantidad de puertos y que por lo tanto carece de sentido asignarles espacios de direccionamiento tan amplios y que nunca serán utilizados.
Por otra parte, el uso de prefijos /64 o semejantes en enlaces entre routers deja abiertas posibilidades de ataques en diferentes contextos. De allí la recomendación de utilizar prefijos /127 en enlaces punto a punto, cualquiera sea la tecnología de capa 2 utilizada.
¿Por qué /127 y no /126?
Una vez más, si arrastramos nuestros conceptos IPv4 a la arquitectura IPv6, lo lógico parece ser utilizar prefijos /126: para un enlace punto a punto se necesitan 4 direcciones IP: 2 direcciones útiles (una para cada puerto) y 2 reservadas.
Pero... en IPv6 las cosas no son iguales.
En IPv6 no hay broadcast, por lo tanto no existen las direcciones reservadas de broadcast.
Tampoco hay una dirección reservada de red, pero sí existe la dirección subnet-router unicast. Las direcciones subnet-router unicast es la dirección IPv6 con todos los bits correspondientes al ID de nodo en cero. Estas direcciones se utilizan cuando un nodo necesita comunicarse desde cualquier punto de la red global con cualquiera de los routers presentes en un enlace (podríamos llamarla dirección "todos los routers de un enlace"). Está definida en el RFC 4291.
Un ejemplo:
Se asigna a un segmento de red el prefijo 2001:db8:1:1::/64
Dentro de ese segmento, el ID 2001:db8:1:1:0:0:0:0 se utiliza como dirección anycast para identificar todos los puertos de routers con direccionamiento global de ese prefijo conectados a ese segmento.
No es lo mismo que la dirección FF02::2, que es la dirección multicast que identifica todos los routers que implementan IPv6, no un prefijo específico, y que sólo puede utilizarse localmente, no globalmente.
Por este motivo, inicialmente el uso de prefijos /127 en enlaces punto a punto no era posible debido al conflicto que se genera con las direcciones subnet-router anycast, lo que llevaba a utilizar prefijos /126.
Sin embargo, el RFC 6164 de abril de 2011 exige que los routers soporten la asignación de /127 en enlaces punto a punto mediante la supresión en los prefijos /127 de as direcciones subnet-router anycast.
Cisco IOS soporta prefijos /127 en enlaces punto a punto.
Conclusión:
Entonces, ¿cuando necesito tener acceso remoto a interfaces punto a punto entre routers, por ejemplo para conectarme por SSH, puedo utilizar direccionamiento global unicast con prefijos /127?
Es una posibilidad, pero no la única. En un próximo post haré una sugerencia para solucionar este requerimiento.
Donde es conveniente utilizar direccionamiento global unicast con prefijos /127 es sin dudas en enlaces punto a punto que conectan dispositivos de borde ente sistemas autónomos. ¿Por qué?
- Porque de esta manera se simplifica la configuración de vecindades eBGP.
- Porque las interfaces pueden ser identificadas claramente al diagnosticar una ruta utilizando traceroute.
Algunos recursos en línea:
Un tema aparte cuando se trata de redes local (no me siento cómodo diciendo "subredes") en IPv6 es el de los enlaces punto a punto.
Cuando arrastramos nuestra cultura IPv4 al ámbito de redes IPv6 seguimos pensando en la escasez y el desperdicio; y cuando trasladamos esto a enlaces punto a punto inmediatamente surge el modelo de subredes /30 con solamente 4 IPs para cada subred.
Y entonces hay una pregunta de rigor: ¿un prefijo IPv6 /64 para un enlace punto a punto? ¿No es un desperdicio?
En realidad este es un punto más en el que debemos tener presente la variedad de direcciones de unicast que manejan las interfaces IPv6. No sólo tenemos direcciones globales que podrían ser escasas en un futuro hipotético (no hay que olvidar que en este momento IANA ha tomado para su asignación solamente 1/8 del espacio disponible y todavía está lejos de agotarse), sino que también contamos con direcciones unicast link local y unique local.
Por este motivo hay 2 soluciones recomendadas:
- La implementación de direccionamiento global con prefijos IPv6 /127.
Esta solución tiene sus detalles, pero está recomendada en el RFC 6164.
- El aprovechamiento de las direcciones de link local para los enlaces de infraestructura.
Es un recurso completamente válido, aunque tiene algunas limitaciones que deben ser tenidas en cuenta al momento de tomar definiciones.
En este artículo me centraré en el uso de direcciones link local, dejo para un post futuro el uso de direcciones globales con prefijos /127.
Las direcciones link local:
- Son identificadores plenamente operativos y únicos dentro del segmento de red.
- No son ruteables y se asignan automáticamente en el momento en que el protocolo comienza a ser operativo en la interfaz.
- Se generan a partir del prefijo FE80::/10 sin requerir asignación del espacio de direccionamiento unicast global.
- Toda interfaz cuenta con una dirección link local generada automáticamente.
- En los dispositivos de infraestructura esas direcciones se generan utilizando EUI-64, con lo que no varían a lo largo del tiempo y una interfaz mantiene siempre la misma dirección link local a menos que se modifique por configuración.
- Se integran en la tabla de enrutamiento y pueden operar como identificadores del próximo salto.
- Son las utilizadas por los protocolos de enrutamiento como EIGRP y OSPFv3 para identificar los dispositivos vecinos.
La consecuencia inmediata de esto es que todas las interfaces seriales en las que se activa IPv6 cuentan con una dirección de link local y por lo tanto son inmediatamente operativas a nivel de capa 3. De este modo, las interfaces y las redes asociadas se integran inmediatamente en la tabla de enrutamiento.
Por lo tanto no es necesario asignar direccionamiento IPv6 global a las interfaces que se integran en un enlace punto a punto. Para eso es suficiente el direccionamiento link local.
Las interfaces que integran los enlaces punto a punto que son parte de la infraestructura de transporte (no estoy hablando de enlaces de acceso) en general no son origen o destino de tráfico sino que son interfaces de tránsito a través de las cuales en paquete se enruta hacia destinos remotos. Para esto lo que se requiere es que cuenten con direccionamiento operativo, que se integre en el proceso de enrutamiento, y para esto una dirección link local es suficiente.
¿Cuándo estas interfaces necesitan un direccionamiento ruteable (que no sea link local)?
Cuando se convierten en origen o destino de tráfico.
¿Y cuándo esas interfaces son origen o destino de tráfico?
En primer lugar, son origen o destino de actualizaciones de protocolos de automatización tales como los protocolos de enrutamiento. Pero como ya dije, para esto se utiliza la dirección link local no la dirección global aún cuando la haya.
En segundo lugar, cuando se utiliza la dirección de la interfaz para definir el acceso al plano de gestión o para tareas de diagnóstico. Para hacer un telnet o un tracert por ejemplo. Por eso hay otras opciones que no desarrollaré ahora, será objeto de otro post.
Limitaciones de esta implementación:
- No se puede utilizar la dirección de las interfaces para tareas de diagnóstico como ping.
- No se puede utilizar la dirección de las interfaces para acceder remotamente a la gestión utilizando SNMP, Telnet o SSH.
- En sesiones eBGP es más simple utilizar direcciones globales, de lo contrario es necesario sobreescribir el atributo nexthop.
- Al realizar traceo de las rutas no se recibe identificación de los saltos intermedio.
Algunos recursos en línea:
