¿IPv6 con Dual Stack implica más trabajo?

Introducción

He escuchado comunmente por parte de los administradores de red que al implementar IPv6 con Dual Stack les significa duplicar su trabajo, lo que analizaré de manera objetiva, aunque sin pretender tener la última palabra.

En la presente estimación se presume que los Equipos y/o Software soportan plenamente IPv6, y el esfuerzo necesario para validar su funcionalidad no es considerado, así como tampoco la curva de aprendizaje general de IPv6 ni particular para cada sistema, en un entorno de oficina de tipo Pequeña o Mediana Empresa, excluyendo el caso del proveedor de servicios (ISP) dado que no se abarca el caso de asignación de recursos a terceros.

Repaso: ¿Qué es Dual Stack?

Dual Stack es un mecanismo de transición de IPv6 que consiste en operar simultáneamente con IPv4. Dado que son protocolos diferentes se manejan de forma independiente, una configuración para IPv4 y otra para IPv6, lo que directamente nos hace sospechar que el trabajo se duplicará en tareas como:

• Asignar direcciones a nuevos equipos
• Agregar/Modificar reglas de firewall
• Habilitar un servicio
• Inscribir registro DNS
• Creación de VPN

Análisis de algunas tareas

Revisemos algunas de las actividades generales de un administrador de red (y/o Sistemas)

Agregar un servidor en la Red

Al agregar un nuevo servidor, deberemos asignar a lo menos 1 dirección IP estática, tanto en versión 4 como versión 6, aunque siendo justos generalmente será mucho más fácil encontrar una dirección disponible en IPv6.

Tenemos una complicación adicional en IPv4, en ocaciones se acostumbra a dejar el servidor con una red "Interna", la que a su vez requiere un NAT hacia una IPv4 pública, además de las reglas de firewall necesarias según los servicios prestados. Aquí IPv6 tiene la ventaja que la dirección utilizada es Global, debiendo definir solo reglas de firewall para los servicios.

Para ésta actividad existe un trabajo adicional, pero no creo que sea exactamente el doble, más bien creo que estaría entre 1,5 a 1,75 veces, a pesar que la direción IPv6 el 4 veces más extensa que IPv4

Agregar un Switch en la Red

Debemos recordar que un Switch propiamente tal es un dispositivo de capa 2, que a lo sumo podría contar con IPv6 con fines administrativos, pero no veo que afecte en la definición de VLANs por ejemplo.

Para ésta actividad considero que el trabajo necesario es prácticamente el mismo que al trabajar en IPv4

Agregar un AP (Access Point)

Al igual que un Switch, un Access Point (AP) es un dispositivo capa 2, por lo que podemos aplicar el mismo criterio, y el esfuerzo para incluirlo en la red es prácticamente el mismo que solo con IPv4, siendo generosos podemos estimar en 1,25 de esfuerzo.

Agregar un Router (o Switch Capa 3)

Pensando en Dual Stack, se necesitará asignar direcciiones IPv4 e IPv6 en sus conexiones, lo que implica duplicar el trabajo. Es común además definir rutas dependiendo de las dimensiones del Data Center puede implicar varias redes IPv4, lo que IPv6 con un buen diseño de distribución puede reducir enormemente la cantidad de redes. Sin ir más lejos, al día de hoy un ISP mediano puede contar con unas 6 redes "/22" y 3 "/24" debido al "goteo" en que se le han entregado, en cambio para IPv6 solo utiliza 1 ruta "/32", "/48" o incluso "/29" con ISP de gran magnitud.

Respecto a los protocolos de enrutamiento, debemos utilizar OSPF versión 3 que opera de manera independiente para IPv6, es decir, debemos repetir su configuración. Por su parte, BGP Versión 4 es multiprotocolo, por lo que solo basta agregar el protocolo IPv6 y las redes IPv6, donde el direccionamiento de los peers puede ser en IPv4 o IPv6 siempre y cuando sea de la misma familia en ambos extremos.

Considerando lo anterior, podemos evaluar el esfuerzo para incluir un nuevo router entre 1,5 a 2 en el peor de los casos.

Agregar un Firewall

Al incorporar un nuevo firewall, deberemos replicar todas sus reglas IPv4 hacia IPv6, en el mejor de los casos podría reducirse por la sumarización de redes, pero igualmente la escritura de las redes es más larga.

Sin mucho que contrarias, se estima el doble de esfuerzo al agregar un Firewall (factor 2).

Habilitar un servicio

En éste caso consideraré los servicios más generales, como HTTP, SMTP y DNS, los que permiten incluir IPv6 en su configuración de "Listen", por lo que no es necesario repetir toda la configuración.

Es interesante destacar que IPv6 permite utilizar múltiples direcciones sobre una misma interface, evitando conflictos entre aplicaciones de forma natural, así por ejemplo podemos tener Nginx y Apache HTTP Server con los mismos puertos sobre IPv6 diferentes. Aunque no implica ninguna novedad dado que IPv4 también lo permite, pero con IPv6 es más simple y existe capacidad de IP para asignar.

Donde si podemos tener algún esfuerzo mayor es en la configuración de restricción de acceso por IP, dende deberemos agregar las Redes IPv6 de la misma forma que las de IPv4, aunque gracias a la sumarización podrín ser menos redes que en IPv4. Para restringir a equipos individuales podría haber una dificultad mayor, dado que las implementaciones DHCPv6 (DHCP para IPv6) donde asigne un IPv6 fijo a un equipo puede ser dependiente del fabricante del servidor y del cliente. Como último recurso queda definir IPv6 estática en el cliente, pero perdemos movilidad del mismo. Se trata de una situación conocida que podrá ser mejorada en algún próximo RFC.

Con ello, el esfuerzo adicional podremos situarlo entre 1,25 a 1,5 veces respecto a su implementación con IPv4.

Habilitar equipos Cliente

Los típicos equipos cliente, con sus IP asignados con DHCP, para IPv6 existen 2 alternativas para la autoconfiguración:

• SLAAC: De tipo Stateless (sin estado), el router indica solo el prefijo de la red (Router Advertisements, abreviado como RA) y el equipo final completa su dirección mediante una convención a partir de la MAC Address de la Interface (EUI-64), donde se acostumbra también agregar una dirección temporal que cambia periódicamente (Generalmente cada 1 hora). Lo malo de éste mecanismo es que no queda registro de la IP utilizada por el cliente, por lo que se dificulta el seguimiento. Por medio de configuración en el sistema operativo del cliente (Microsoft Windows a lo menos) se puede evitar el uso de la dirección temporal conservando una dirección fija EUI-64.
• DHCPv6: El protocolo DHCP para IPv6 provee un mecanismo para asignar un IP específico a un dispositivo, lo que se llama asignación Statefull (Con estado). A diferencia de su simil en IPv4, DHCPv6 no especifica el prefijo de Red ni su default Gateway, lo que se obtiene con el protocolo Router Advertisements al igual que con SLAAC

La habilitación del protocolo Router Advertisements (RA) es suficiente para el uso de SLAAC, incorporar DHCPv6 igualmente requiere utilizar RA.

Considerando que en general los equipos clientes ya vienen configurados para utilizar IPv6 (Microsoft Windows 7 en adelante, Mac OSX, Linux, Android, iOS) y el esfuerzo radica solo en la configuración del mecanismo de autoconfiguración tenemos que el factor de comparación es a lo menos de 2. Aquí si implica duplicar el trabajo "en el mejor de los casos", o más si se requiere utilizar DHCPv6 para los equipos finales, lo que muchas veces es requerido en redes corporativas.

Diagnóstico de Fallas

Es claro, podemos desgastarnos mucho rato tratando de comprobar por que una conexión falla en IPv4, para finalmente darnos cuenta que el problema es en IPv6. Aunque podrá darse el caso de un problema de rutas en IPv4 pase desapercibido dado que en IPv6 opera normalmente (otras rutas), lo cual, aunque reduce el impacto, puede estorbarnos para encontrar la falta de dichas rutas IPv4.

Podremos estimar el esfuerzo adicional entonces del doble, dado que se deberá validar conectividad en ambos protocolos.

Monitoreo de equipos y servicios

Aunque puede ser considerado como parte de la instalación de un equipo, prefiero detallarlo de manera independiente.

En terminos generales, si instalamos un nuevo servidor deberemos duplicar los check de monitoreo de servicios para IPv4 e IPv6, y solo se excluye el caso de las interfaces de red, que al pertenecer a la capa 2, su estado UP o DOWN es independiente de la pila IP utilizada, como así tambié la gráfica de la tasa de transferencia de una NIC, aunque si queremos medir de forma separada el tráfico IPv6 deberemos crear un nuevo gráfico (Siempre y cuando el equipo provea una MIB con tráfico IPv6 excluyente).

Con éstos datos, estimo un esfuerzo adicional de 50% para éstas actividades (factor de 1.5)

Inscripciones en DNS

Al agregar algún registro DNS, deberemos contemplar la inscripción del registro A, para IPv4 y el registro AAAA, y en caso necesario el registro PTR para el "reverso"

No hay mucho más que discutir para éste punto, el esfuerzo necesario es el Doble, sin contemplar que el registro para IPv6 requiere escribir bastante más texto.

Habilitación de VPN

Debo reconocer que aun me falta por estudiar algo más respecto a las VPN con IPv6, a primera vista hay que considerar los siguientes puntos:

• No todas las VPN soportarían IPv6, aunque si la VPN es capa 2, fácilmente se le puede agregar IPv6
• se debiera asignar un diereccionamiento para la Inter-Red (o red de enlace) y el direccionamiento del Remoto, lo que en rigor es duplicar el trabajo de solo IPv4

Conclusión

Como vemos, en la mayor parte de las actividades consideradas las acciones a realizar prácticamente se duplican, o a ojo podemos estimar un 85% de carga adicional, claro que todo ello dependerá de las actividades que realicemos con mayor frecuencia

El hecho que implementar IPv6 con Dual Stack nos implica más trabajo nos hace evitar su implemetación, pero habrá un momento en que ya no se pueda evitar más y para ese momento tendríamos que implementar de forma apresurada y con mayores riesgos que los errores cometidos sean más notorios.

Probablemente sea momento de darse un tiempo y empezar a analizar lo que significa, en mayor o menor medida, la implementación de IPv6, no necesariamente en toda la red, pero al menos contar con un diseño primario, poder evaluar y comprobar su funcionamiento, comenzando desde ya a ganar experiencia.

Opciones para reducir las tareas

En rigor no está todo perdido, debemos tomar en cuenta que el objetivo final es operar totalmente con IPv6 y eliminar IPv4, lo que puede tomarnos unos 10 o 20 años más probablemente. Tenemos el ejemplo de Facebook que cambió toda su estructura interna a IPv6 Only, brindando la conectividad a los usuarios IPv4 mediante "Proxy Reverso" desde el Borde en sus POP, con lo que podemos tener alguna idea donde podemos ahorrar trabajo.

Utilizar solo IPv6 hasta donde se pueda

Existen casos en que tenemos implementaciones Internas, como un sistema comercial, o control de inventario, donde podríamos dejarlos, operando solo en IPv6. Las estaciones cliente pueden operar solo con IPv6 o Dual Stack.

Similarmente, al conectar oficinas remotas o integrarse con algún proveedor, donde se presentan problemas de conflictos de IP, definir NAT en ambos sentidos que complica el diagnóstico de las fallas. Podemos hacer una implementación limpia solo IPv6 con una VPN capa 2 (puede ser con extremos IPv4) sobre la cual transita IPv6, definimos las rutas en y sus reglas de Firewall en ambos extremos.

Proxy reverso con Nginx

Tenemos toda nuestra red en IPv6, pero tenemos algunos equipos con IPv4 que no podemos configurar, pues bien, podemos recurrir al bien conocido Nginx que nos permite definir proxy reverso desde IPv4 a IPv6 para servicios HTTP, SMTP, POP, IMAP y otros.

Mecanismos de transición

Aunque la discución se basa en una implementación Dual Stack, es necesario mencionar que existen otros mecanismos de transición que nos permiten comunicar entre el mundo IPv4 e IPv6, que pueden ser de gran ayuda para una implementación IPv6 Only sin perder acceso con IPv4. Entre éstos mecanismos se detacan:

• 464-XLAT
• NAT64 / DNS64
• 6RD
• DS-Lite

Generado por Sistema y almacenado en cache