Mi interés por IPv6 se remonta a 1997. En ese momento estaba escribiendo mi primer libro técnico, “Resolución de problemas en TCP/IP”. Al llegar al último capítulo, sentí el impulso de salir y ver cómo podría ser el futuro. Fue así que encontré el primer libro de Christian Huitema, “IPv6: el nuevo protocolo de Internet”. Se trataba de un libro pequeño —alrededor de 100 páginas— y en el último capítulo de mi libro lo resumí en dos o tres párrafos, diciendo “hay un nuevo protocolo en el horizonte, uno que eventualmente ayudará a resolver el problema de las direcciones IPv4”. Creo que en aquel entonces era el único libro disponible sobre IPv6. No puedo explicar por qué, pero por alguna razón este tema me fascinó.
Así, cuando O’Reilly me llamó tres años más tarde y me preguntó si podía escribir para ellos un libro sobre IPv6, no dudé en decir que sí. Sabía por experiencia al escribir el primer libro sobre TCP/IP que no hay mejor manera de aprender algo que escribiendo un libro sobre el tema. Y yo estaba convencida de que IPv6 sería el futuro Protocolo de Internet, por lo que bien valía la pena profundizar en él. En aquellos primeros años, no muchos habían oído hablar de IPv6, por lo que fueron principalmente los desarrolladores quienes me apoyaron en mi proceso de escritura. Y así fui aprendiendo de la fuente.
Desafíos en el camino.
El diseño de IPv6 comenzó a principios de la década de 1990. Publicada en 1995, la RFC 1752 fue la primera RFC sobre IPv6. En ese momento se llamaba IPng (next generation). Ya en aquellos primeros días de Internet, los desarrolladores previeron que el espacio de direcciones IPv4 se agotaría en algún momento. Estimaron que sucedería entre 2012 y 2015 (vista en retrospectiva, ¡fue una muy buena predicción!), por lo que decidieron que tenían tiempo suficiente no sólo para ampliar el espacio de direcciones sino también para intentar hacer que el protocolo fuera más escalable para grandes estructuras de Internet.
En cuanto a los desafíos para el desarrollo y el despliegue de IPv6, supongo que fue que NAT (Network Address Translation) se volvió cada vez más popular para resolver los problemas derivados de la limitación de las direcciones antes de que IPv6 estuviera lo suficientemente maduro para su implementación. IPv6 se publicó en 1998 con la RFC 2460, un borrador de RFC, y pasó algún tiempo hasta que los proveedores hicieron sus primeras implementaciones. De modo que, cuando IPv6 estuvo listo para usar, muchos ya habían implementado NAT para “resolver” los problemas urgentes que implicaba la limitación de direcciones y no veían una razón para desplegar IPv6.
Desde una perspectiva a corto plazo, esto es comprensible. Sin embargo, no es compatible con una perspectiva a largo plazo desde el punto de vista de la arquitectura de red y tampoco desde la perspectiva de un caso de negocio. Pensando a largo plazo, NAT se debería reemplazar por la solución creada para resolver el problema de las direcciones, es decir, IPv6.
Si observamos esto a través de la lente de Internet, las empresas deberían entender que todos somos participantes y co-creadores de Internet. El hecho de que ofrezcan o no sus servicios de Internet, por ejemplo, sitios web y tiendas en línea, a través de IPv6, tiene un gran impacto en otros ISP y en los usuarios finales. Para todos los servicios que se ofrecen a través de Internet, la recomendación es ofrecerlos en forma dual-stack o doble pila, lo que significa que son accesibles tanto a través de IPv4 como de IPv6. De esta forma, cada usuario final puede acceder al sitio a través del protocolo con el que obtiene el mejor rendimiento.
Para un ISP, los costos operativos son sustancialmente menores si tiene una ruta IPv6. Es mucho más sencillo mantener y descargar el tráfico de su ruta IPv4 (que suele ser una estructura NAT compleja que genera un alto costo de mantenimiento). Por lo tanto, cada sitio web público que ofrece sus servicios a través de IPv6 descarga tráfico de la ruta IPv4 y lo transporta a través de la ruta IPv6 más eficiente para todos los ISP en la ruta. Según cómo esté conectado a Internet, para el usuario final esto puede suponer una gran ventaja en cuanto a su desempeño: si su ISP tiene una estructura NAT compleja y quizás sobrecargada para IPv4, a través de IPv6 puede acceder a cualquier servicio de Internet dual-stack.
Swisscom, un ISP suizo que ofrece Internet dual-stack a sus usuarios de DSL desde 2012, evaluó sus costos operativos después de cinco años. Los resultados fueron interesantes.
Costo para una tasa de transferencia efectiva de 1 Gb/s:
6rd: CHF 1’650.00
IPv4 CG-NAT: CHF 8’000.00 (sin costo de registro)
Esto significa que, para Swisscom, entregar datos a través de IPv4 es más de cuatro veces más caro que hacerlo a través de IPv6. Más del 35 % del tráfico de su backbone es IPv6 (cifras de 2017). La ruta IPv6 redujo la carga de la ruta IPv4 en 9 Gb/s.
Por lo tanto, sería una mejora importante que los sitios web públicos ofrecieran sus servicios de forma dual-stack (lo que en realidad es una obviedad desde un punto de vista técnico) y que las empresas dieran a sus usuarios acceso dual-stack a Internet. Esto aumentaría sustancialmente el tráfico IPv6 en Internet y reduciría el tráfico IPv4.
IPv6: dificultades en las organizaciones.
El principal problema que veo hoy en día es que es muy común —en especial en las organizaciones grandes— tomar decisiones con una perspectiva a corto plazo. Si algo no genera beneficios en pocos meses, muchas veces se lo elimina del presupuesto. Y el dinero suele ser una buena excusa para no tener que hacer cosas con las que la gente no quiere lidiar. En muchas discusiones con los clientes me doy cuenta de que creen que IPv6 es demasiado complejo y no podrán dominarlo. Puede parecer abrumador, estoy de acuerdo, pero solo si no nos tomamos el tiempo para mirarlo más de cerca. Si lo miramos más de cerca, veremos muchos ejemplos de empresas que han predicado con el ejemplo y han comprobado que es más fácil y menos costoso de lo que esperaban. Por otro lado, es difícil gestionar un proyecto de IPv6 sin apoyo a nivel directivo, ya que es necesario tener prioridades y objetivos compartidos entre los diferentes departamentos.
Otra razón que está ralentizando la implementación de IPv6 es que IPv6 es visto como un proyecto independiente. Así, cada año se analiza como parte de un presupuesto anual y se decide que no hay tiempo y que el dinero se necesita para otros proyectos que parecen más importantes. El hecho es que IPv6 no es un proyecto independiente, sino que debe verse como una parte integral de cualquier otro proyecto. Porque todos los proyectos de TI se ejecutan en la misma red de la cual IPv6 es una parte integral, como lo es la seguridad. Nadie diría “no tenemos tiempo ni dinero para la seguridad”. Ahora tenemos que desplegar nuestro nuevo centro de datos. De la seguridad nos vamos a ocupar más tarde”. Esto no tiene sentido, ¿verdad? ¡Lo mismo pasa con IPv6!
Y cuando consideramos que IPv6 es una parte integral de cualquier proyecto que utilice la red, ya no se trata de algo enorme, super complejo y alucinante, sino que se puede abordar paso a paso, por proyecto. Obviamente, hay algunos aspectos que deben abordarse en todos los proyectos, como la arquitectura general, el plan de direcciones y el concepto de seguridad. Esto debe hacerse al principio y luego servir como marco para cada proyecto individual.
Las organizaciones no son conscientes de costos ocultos del funcionamiento de sus redes IPv4.
Una gran organización con la que trabajé recientemente analizó este tema con más cuidado. Uno de sus costos fue que tuvieron que comprar direcciones IPv4. El precio de mercado de una dirección IPv4 ha aumentado bastante en los últimos años. En 2013, cuando Microsoft compró las direcciones IPv4 de Nortel, pagó alrededor de 12 dólares por cada dirección. Hoy en día, el costo de una dirección IPv4 ha aumentado a entre 50 y 60 dólares (https://www.ipxo.com/blog/ipv4-price-history/). Este cliente pagó alrededor de un millón de dólares por un /16 de direcciones IPv4. Si hubieran incluido IPv6 en su planificación con suficiente antelación, podrían haberse ahorrado estos costos o habrían podido invertir este dinero en el despliegue de IPv6.
Este cliente también descubrió que una gran parte de sus tiempos de inactividad y costos de resolución de problemas eran generados por las complejas estructuras y dispositivos NAT. Por lo tanto, al evaluar el costo de implementar IPv6, estos costos se deben considerar como ahorros.
Otro caso en el que se generaron costos y problemas innecesarios por no implementar IPv6 fue el de la empresa ferroviaria suiza SBB. En 2014 habían empezado a trabajar en el tema al crear un plan de direcciones. En vez de comenzar una implementación paso a paso, el plan de direcciones fue a parar a un cajón y allí permaneció olvidado. Unos años después, el equipo de negocios decidió lanzar un nuevo servicio. La fecha de lanzamiento sería en un año. Querían crear una aplicación para teléfonos inteligentes para que sus clientes en los trenes pudieran obtener información sobre sus asientos, espacio de almacenamiento y otra información relacionada con su viaje. El equipo de negocio se puso en contacto con el equipo responsable de la red y les pidió 1000 direcciones por tren para 1200 trenes. Esta demanda inesperada era imposible de satisfacer con IPv4.
De manera que a los dispositivos del tren tuvieron que asignarles solo IPv6. Y dado que su infraestructura de backend seguía siendo solo IPv4, tuvieron que hacer una traducción para escribir los datos en su backend. Si hubieran empezado a migrar el backbone paso a paso después de 2014, lo más probable es que se pudiera acceder al backend a través de IPv6. Además, como el proveedor Swiss Mobile solo tenía una conexión móvil IPv4, los datos tuvieron que ser canalizados a través de ella. Estamos hablando del año 2018. Si todos los participantes de Internet hicieran sus deberes, estos escenarios podrían ser mucho más simples.
Dado que IPv4 genera costos mucho más altos de operación, mantenimiento y resolución de problemas, los proveedores y los ISP están gradualmente empezando a cobrar más por los servicios IPv4 que por los servicios IPv6.
Azure, por ejemplo, ha anunciado que empezará a cobrar más por las direcciones y prefijos IPv4 en julio de 2022. Una dirección IPv4 estática ahora le cuesta a Microsoft $31,50 por año, mientras que las direcciones IPv6 estáticas son gratuitas. (https://azure.microsoft.com/en-us/updates/azure-public-ipv6-offerings-are-free-as-of-july-31/)
El mensaje después de 20 años.
IPv6 se especificó en la RFC 8200, que data de julio de 2017. Es el protocolo de Internet actual y está en constante optimización y desarrollo.
IPv4 se especificó en la RFC 791, que data de 1981 y ya no está en desarrollo. Llegó al final de su vida útil en 2011, cuando la IANA entregó los últimos cinco bloques de direcciones IPv4.
Los responsables del desarrollo y mantenimiento de una red IPv4 deben tener esto en cuenta. Es un aspecto importante de la protección de las inversiones. IPv4 genera muchos costos innecesarios y en algún momento será necesario migrar a IPv6. Esto significa que cualquier cosa que instalemos sobre o para IPv4 tendrá que ser modificada. Todo lo que podamos implementar sobre IPv6 es una inversión duradera. ¿No es de sentido común invertir en el protocolo de Internet actual en lugar de resolver problemas, arreglar, ampliar y crear soluciones alternativas para un protocolo obsoleto?
El objetivo debería ser crear una red solo IPv6 lo antes posible, ya que esta es la forma más sencilla y segura de operar una red. A partir del 29 de junio de 2021, el Departamento de Defensa de Estados Unidos empezó su transición obligatoria a IPv6, exigiendo que todos los sistemas en red cambien a la versión más actualizada del Protocolo de Internet (IP), el Protocolo de Internet versión 6 (IPv6), antes de fines del año fiscal 2025.
En el otro extremo del mundo, China tiene estrategias similares. Su objetivo es que todos los niveles de la industria y el gobierno implementen redes IPv6 de pila única para 2030. (https://www.theregister.com/2021/07/26/china_single_stack_ipv6_notice/)
