7 desafíos que enfrentó IPv6 y cómo fueron resueltos

¿Alguna vez pensaste que IPv6 no lograría despegar realmente? Si tu respuesta es “sí”, este blog es para ti.

En los últimos 20 años IPv6 pasó por muchos obstáculos que hicieron dudar a más de uno sobre su futuro. Desde el principio tuvo que enfrentar desafíos técnicos importantes: no era compatible con IPv4, muchos equipos antiguos no lo soportaban y, como suele pasar, hubo bastante resistencia al cambio por parte de operadores y empresas. A esto se sumaron varios mitos —como que era demasiado complejo o poco seguro— que también jugaron en su contra.

Pero el tiempo y la tecnología hicieron lo suyo. Gracias a herramientas de transición, mejoras en el enrutamiento y el desarrollo de hardware más preparado, IPv6 no solo demostró que puede escalar (¡estamos hablando de 340 undecillones de direcciones disponibles!), sino que también es más eficiente y seguro que el viejo IPv4.

Hoy, IPv6 ya no es una promesa: es una realidad. Está detrás del 5G, del futuro 6G, del Internet de las Cosas a gran escala y de la nube hiperconectada. Y además, soluciona problemas que arrastramos hace años, como la falta de direcciones y la fragmentación de las redes.

En este artículo vamos a desarmar algunos de los mitos más comunes —como que IPv6 baja el rendimiento o que no se lleva bien con sistemas antiguos— y vamos a mostrarte con datos y ejemplos reales por qué migrar a IPv6 no solo es posible: es necesario si querés que tu red esté preparada para lo que viene.

1. Mejora en la conmutación de paquetes a nivel de hardware

En los últimos 15 años los circuitos integrados de aplicación específica (ASICs) para redes han pasado de un soporte marginal a una implementación nativa y optimizada de IPv6. Antes de 2010, el procesamiento de IPv6 dependía de CPUs generales, generando alta latencia y bajo rendimiento. Entre 2010-2015, fabricantes como Cisco y Broadcom integraron tablas de forwarding IPv6 en hardware (TCAM), soporte para NDP/ICMPv6 y lookup eficiente en chips como el Cisco Nexus 7000 o Broadcom StrataXGS. Para 2015-2020, los ASICs alcanzaron madurez con tablas de routing escalables, offloading de extensiones IPv6 (headers, tunneling) e integración con SDN/NFV, ejemplificado por el Broadcom Tomahawk y Cisco Silicon One.

Desde 2020, IPv6 es prioritario en diseños de ASICs, con capacidades avanzadas como: Segment Routing IPv6 (SRv6) acelerado, seguridad nativa (IPsec en hardware), y optimización para IoT/5G. Chips como el Broadcom Jericho2 (2020), Marvell Octeon 10 (2022) e Intel Tofino 3 (2023) soportan millones de rutas IPv6 y procesamiento programable (P4), consolidando IPv6 como estándar en redes modernas. Esta evolución refleja la transición de IPv6 de un complemento software a un componente crítico en el hardware de red.

Período Soporte IPv6 en ASICs Limitaciones

Pre-2010 Mínimo o por software Alto costo de CPU, baja eficiencia

2010-2015 Primeras implementaciones en TCAM/ASICs Tablas IPv6 limitadas

2015-2020 Madurez en switches/routers empresariales  

2020-Actualidad IPv6 nativo, optimizado para cloud/5G/SRv6  

Comparativa Resumida sobre evolución de las ASICs

2. El dilema del huevo y la gallina en IPv6

El dilema del huevo y la gallina en el contexto de IPv6 se refiere a la paradoja de cómo impulsar la adopción de esta nueva versión del Protocolo de Internet. Es como si nadie quisiera comprar un nuevo tipo de teléfono porque no hay apps para él, pero los desarrolladores no crean apps porque casi nadie tiene ese teléfono.

Por un lado, los proveedores de contenido (como plataformas de streaming y sitios web) necesitan que haya suficientes usuarios que utilicen IPv6 para justificar la inversión en infraestructura y optimización para este protocolo. Por otro lado, los usuarios finales requieren acceso a contenido disponible a través de IPv6 para motivarse a hacer la transición desde IPv4. Sin una base sólida de ambos lados, se crea un ciclo vicioso donde la falta de usuarios limita el contenido disponible y la escasez de contenido desincentiva a los usuarios a adoptar IPv6.

La realidad en 2025 es muy distinta: una larga lista de las principales CDNs (redes de distribución de contenidos) y sitios web a nivel mundial ya soportan IPv6 desde hace varios años. Como resultado, los clientes que aún no implementan IPv6 suelen experimentar un rendimiento de conectividad ligeramente inferior en comparación con aquellos que sí lo utilizan.

Un hecho no menor que ha impulsado considerablemente la adopción de IPv6 entre los proveedores es el impacto del mundo de los videojuegos y la comunidad gamer. Resulta ampliamente conocido el fuerte respaldo que las principales consolas han brindado a IPv6, como es el caso de Xbox (desde 2013) y PlayStation (desde 2020).

CDN/Sitio Web Año de Adopción IPv6  

Cloudflare 2011 Primer CDN en soportar IPv6 globalmente

Google (Búsqueda, YouTube) 2012 Habilitación progresiva

Facebook/Instagram 2013 Adopción completa en 2014

Wikipedia 2013 Uno de los primeros sitios en adoptar

Akamai 2014 Soporte gradual por región

Netflix 2015 Prioriza IPv6 para reducir latencia

Amazon CloudFront 2016 Soporte completo en edge locations

Apple (App Store) 2016 Requisito obligatorio para apps iOS

Microsoft Azure CDN 2017  

Fastly 2018 Soporte nativo en toda su red

Tabla de adopción IPv6 en contenido .Fuente: Deepseek (Mayo 2025)

3. Enrutamiento con Prefix Delegation

Una situación muy interesante, que ocurrió hace 10-15 años, era la dificultad que muchos proveedores de servicios de Internet (ISPs) enfrentaban al implementar DHCPv6-PD (Prefix Delegation). Era común que surgieran problemas de enrutamiento: por ejemplo, un host o una red remota (CPE) podía recibir correctamente un prefijo IPv6, pero las rutas necesarias para alcanzar ese prefijo no estaban configuradas en el ISP. Era como si el cartero supiera tu dirección, pero no tuviera un mapa para encontrar cómo llegar a tu casa.

Hoy os ISPs han actualizado sus infraestructuras para manejar automáticamente el enrutamiento de los prefijos delegados, mientras que los routers modernos (tanto domésticos como empresariales) incluyen soporte robusto para DHCPv6-PD. Ahora, cuando un cliente recibe su bloque IPv6, el ISP inmediatamente propaga las rutas necesarias, y el router local configura automáticamente las subredes internas. Esto ha hecho que la delegación de prefijos IPv6 sea tan confiable como el DHCP tradicional de IPv4, eliminando uno de los dolores de cabeza iniciales de la transición.

Aspecto Hace 10 Años Actualidad (2024)

Asignación de prefijo DHCPv6-PD sin rutas en el core DHCPv6-PD + auto-anuncio BGP/IGP

Comportamiento del CPE Recibía el prefijo o no configuraba rutas Configura automáticamente LAN + rutas

Conectividad Solo tráfico saliente (entrante perdido) Full bidireccional (entrante/saliente)

Soluciones temporales NAT66, túneles manuales, redistribute connected en el CPE Enrutamiento nativo sin hacks

Comparativa: 2014 vs. 2024

4. Formación y aprendizaje colectivo

Hace dos décadas, adoptar IPv6 era un desafío técnico y educativo. La documentación resultaba escasa, dispersa y a menudo demasiado técnica, dejando a muchos administradores de redes aprendiendo mediante ensayo y error. Los primeros cursos disponibles se limitaban principalmente a especificaciones teóricas del protocolo, con poca orientación práctica sobre implementación real en redes operativas. Esta falta de recursos formativos de calidad ralentizó inicialmente la adopción de IPv6, especialmente en entornos empresariales y operadores pequeños.

Hoy en día, diferentes organizaciones, incluyendo LACNIC, han liderado un esfuerzo educativo masivo para reducir las barreras de entrada a IPv6. Ejemplos de esto son el Campus de LACNIC, con cursos que van desde nivel básico hasta avanzado, publicaciones en blogs, videos, podcasts, y otros recursos didácticos.

Además, iniciativas como LACNOG (y otros NOGs regionales) y los ya clásicos talleres prácticos de IPv6 de LACNIC han contribuido a crear espacios de formación y discusión técnica sobre la implementación de IPv6 en redes reales.

A seu vezmuchas empresas privadas han incluido IPv6 como tema obligatorio en sus programas de formación y certificación, tanto en cursos como en exámenes.

La comunidad técnica tampoco se ha quedado atrás: cientos de personas, desde estudiantes hasta ingenieros de redes senior, comparten regularmente recursos en diferentes redes sociales, generando artículos, videos, blogs y notas técnicas que ayudan a cerrar las brechas de conocimiento y a fortalecer el aprendizaje colectivo sobre IPv6.

5. Compatibilidad con aplicaciones

Veinte años atrás, el soporte IPv6 en aplicaciones era una suerte de lotería. Si existía IPv4 e IPv6 en la red era aún más complicado. Por ejemplo, en una red IPv6 Only si la app usaba direcciones IPv4 literales lógicamente iba a fallar. Muchos desarrolladores asumían que en todas las redes había IPv4 de facto. También en los sistemas operativos existían bibliotecas obsoletas que no soportaban el nuevo protocolo. Esto creaba una situación absurda: incluso cuando un usuario o empresa tenía una red IPv6 perfectamente configurada, sus herramientas cotidianas -como lector de correo electrónico- simplemente dejaban de funcionar.

Hoy la situación ha dado un vuelco radical. Grandes plataformas como la App Store de Apple (desde 2016) y Google Play exigen que las aplicaciones nuevas sean IPv6-compatibles (a pesar de esta última no lo coloca de manera explícita) como requisito obligatorio. Adicionalmente mecanismos como Happy Eyeballs apoyan la transición a IPv6 a nivel de software de manera transparente. Las principales bibliotecas de programación (como las de Python, Java y Node.js) incluyen soporte nativo para IPv6 desde hace años, eliminando excusas para los desarrolladores. Empresas como Microsoft, Google y Cloudflare han liderado este cambio, demostrando que el rendimiento en IPv6 puede ser incluso mejor que en IPv4. Lo que antes era un dolor de cabeza ahora es una ventaja competitiva: las aplicaciones que adoptan IPv6 primero disfrutan de menor latencia, mejor seguridad y acceso a la próxima generación de usuarios conectados.

6. Fragmentación y MTU (Maximum Transmission Unit)

A diferencia de IPv4, IPv6 elimina la fragmentación en los routers intermedios, lo que significa que los paquetes deben respetar el MTU (Maximum Transmission Unit) de toda la ruta desde el origen hasta el destino. Esta decisión de diseño mejora la eficiencia general de la red, pero en sus primeros años (hace 10, 15 o 20 años), generó bastantes dolores de cabeza: muchos dispositivos implementaban de forma incorrecta el mecanismo de Path MTU Discovery (PMTUD), lo que provocaba pérdida de conectividad en situaciones comunes.

En particular, routers antiguos y sistemas operativos sin actualizar no sabían manejar bien los mensajes ICMPv6 “Packet Too Big”, que son esenciales para que el emisor ajuste el tamaño de los paquetes. Como resultado, la comunicación se rompía en redes donde el MTU era más bajo de lo esperado.

Actualmentelos sistemas operativos modernos y los equipos de red actuales ya manejan correctamente el PMTUD, respondiendo y ajustando dinámicamente el tamaño de los paquetes en función de los mensajes ICMPv6. Esto ha hecho que estos problemas sean mucho menos frecuentes y que la red funcione de manera más estable y eficiente bajo IPv6.

7. El envío de DNS vía RA

En los primeros años de IPv6 (hasta aproximadamente 2010), configurar servidores DNS en los clientes de red era un proceso más complejo e indirecto. Los routers enviaban mensajes Router Advertisement (RA) con el flag O (Other Configuration) activado, lo que obligaba a los clientes a hacer una solicitud adicional mediante DHCPv6 para obtener la información de los servidores DNS. Este enfoque, heredado del mundo IPv4, traía consigo varios inconvenientes: mayor latencia en la configuración, dependencia de un servicio adicional y mayor complejidad para redes simples o dispositivos con recursos limitados, como muchos equipos IoT.

Esta limitación se resolvió con la introducción de la opción RDNSS (Recursive DNS Server) dentro de los propios mensajes RA de ICMPv6, formalizada en el RFC 6106 (2010). A partir de entonces, los routers pudieron anunciar directamente los servidores DNS a los clientes, simplificando drásticamente la autoconfiguración.

Aunque al principio hubo cierta resistencia por parte de fabricantes de sistemas operativos y routers, entre 2015 y 2017 el soporte para RDNSS se volvió común: Windows 10, Linux (con systemd-networkd), iOS 9+ y la mayoría de los routers empresariales ya lo implementaban.

Hoy esta funcionalidad está prácticamente universalizada en equipos modernos y se considera una mejor práctica en redes IPv6, eliminando la necesidad de usar DHCPv6 solo para DNS y habilitando despliegues mucho más simples, tipo “plug and play”.

Conclusiones

En retrospectiva, tras más de dos décadas de evolución, IPv6 ha superado obstáculos que en su momento parecían insalvables, pasando de ser un protocolo casi teórico a convertirse en la columna vertebral de la Internet moderna.

Los desafíos técnicos que antes generaban incertidumbre hoy cuentan con soluciones estandarizadas, eficientes y ampliamente adoptadas, fruto de la colaboración entre la industria y organismos como el IETF. Mitos como su supuesta “complejidad” o “incompatibilidad” han sido superados por evidencias concretas de mejor rendimiento, mayor seguridad y capacidad de escalado real.

IPv6 es el presente. Con casi el 50% del tráfico global circulando sobre IPv6 (y cerca del 40% en América Latina y el Caribe), soporte nativo en CDNs, sistemas operativos y aplicaciones, y un papel fundamental en tecnologías como 5G, IoT y cloud hiperconectada, la transición total es solo cuestión de tiempo. Seguir postergando su adopción no solo significa perder ventajas técnicas: es avanzar hacia la obsolescencia.

La lección es clara: adoptar IPv6 es un imperativo estratégico. No implementarlo es correr el riesgo de quedar aislado en una Internet que ya ha dado el siguiente paso.

Referencias:

    RFC 6106: https://datatracker.ietf.org/doc/html/rfc6106

    Centro de estadísticas de LACNIC: https://stats.labs.lacnic.net/IPv6/graph-access.html

    https://developer.apple.com/support/downloads/terms/app-review-guidelines/App-Review-Guidelines-20250430-English-UK.pdf

Se viene esta palabra: noiafobia

noiafobia = No Inteligencia Artificial Fobia

o

noaifobia = No Artificial Intelligence Fobia

¿Qué historia hay detrás de las famosas máscaras de red?

Introducción

¿Recuerdas cuando estabas aprendiendo de máscaras de red? Seguro llegaste a pensar: “no sirven para nada”, “no las voy a necesitar”, “¿por qué inventaron esta locura?”. Además de sacarte una sonrisa espero convencerte de la enorme importancia que tienen en el gigantesco ecosistema de Internet.

Objetivo

Este blog post resume la historia y los hitos relacionados detrás de los conceptos de máscara de red en el mundo de IPv4. Comenzamos la historia en un mundo donde no existían las clases (plano-flat), pasamos por un mundo classful y finalizamos en un Internet totalmente classless (CIDR). La información se basa en extractos de los RFC 790, 1338 y 1519, junto con hilos de correo electrónico de la lista de correo ‘Internet-history’.

¿Sabes lo que es la máscara de red?

Asumo que si llegaste a este documento si lo sabes :-) pero aquí va un mini concepto: una máscara de red se utiliza para ubicar y dividir un espacio de dirección de red y una dirección de host, en otras palabras, indica al sistema cuál es el esquema de particionamiento de subred.

¿Cuál es el propósito de la máscara de red?

Enrutamiento: Los enrutadores utilizan la máscara de red para determinar la porción de red y encaminar correctamente los paquetes.

Subnetting: Las máscaras de red se utilizan para crear redes más chicas.

Aggregación: Las máscaras de red permiten la creación de prefijos más grandes.

¿Siempre han existido las máscaras de red?

No, muy interesantemente no siempre existió la máscara de red, al comienzo las redes IP eran planas (flat) y siempre asumían 8 bits para la red y 24 bits para el host. En otras palabras, el primer octeto era la red, y los 3 octetos restantes corresponden al host. Otro aspecto llamativo es que hace muchos años también recibía el nombre de bitmask o solo mask (aún utilizado ampliamente).

Lo anterior conlleva a que no siempre existieron las clases (A, B, C, D)

Las clases no existieron hasta la aparición del RFC (septiembre 1981) de Jon Postel, es decir, incluso era una época antes de classless y classful.

La introducción del sistema classful fue impulsada por la necesidad de acomodar diferentes tamaños de red, ya que el ID de red original de 8 bits era insuficiente (256 redes). El sistema classful fue un intento de abordar las limitaciones de un espacio de direcciones plano, aunque este también tenía limitaciones de escalabilidad. En el mundo de las clases la máscara de red era implícita.

Las clases tampoco solucionaron todo

Si bien el sistema classful fue una mejora sobre el diseño original (plano), no era eficiente. Los tamaños fijos de los espacios de red y hosts de las direcciones IP llevaron al agotamiento del espacio de direcciones, especialmente con el creciente número de redes que eran más grandes que una Clase C, pero más pequeñas que una Clase B. Lo anterior llevó al desarrollo del enrutamiento Inter-Dominio Sin Clases (Classless Interdomain Routing – CIDR), que utiliza máscaras de subred de longitud variable (Variable Length Subnet Mask – VLSM).

Extracto del RFC 790

¿Sabías que no siempre la máscara se escribió con bits continuos encendidos de izquierda a derecha?

Al comienzo en la máscara de red no debía “encenderse” bit a bit de izquierda a derecha, es decir, mascaradas como: 255.255.192.128 era completamente válidas. Esta configuración era aceptada por routers (IMPs -los primeros routers-) y diferentes sistemas operativos, entre ellos los BSDs y SunOSs antiguos. Es decir, hasta comienzos de los 90’s aún era posible tener máscaras de red de bits no continuos.

¿Por qué se decidió que los bits luego fueran obligatoriamente encendidos de izquierda a derecha?

Existieron varias razones, la principal tiene que ver con enrutamiento y el famoso concepto “longest match” que conocemos donde el router selecciona la ruta cuya máscara de subred sea la más larga que coincida con la dirección de destino del paquete. Es decir, si los bits no son continuos se crea una complejidad computacional muy alta. En resumen: eficiencia.

Desde esa época ya se agotaban direcciones IPv4

El agotamiento de recursos IPv4 no es algo nuevo, incluso en la primera sección del RFC 1338 en su numeral uno hace referencia al agotamiento de la Clase B indicando que la Clase C es demasiado pequeña para muchas organizaciones, y la Clase B es demasiado grande. Esto ocasionó una presión sobre el espacio de direcciones Clase B, agotando la misma. Y no solo eso, el mismo RFC en el numeral 3 cita textualmente: “Eventual exhaustion of the 32-bit IP address space” (1992).

CIDR aborda las soluciones de ayer, que se convirtieron en los problemas de ese momento

Al momento de crear las clases se crearon más redes lo que conlleva a más prefijos y a su vez mayor consumo de memoria y CPU. Por ello en septiembre de 1993 en el RFC 1519 apareció el concepto de CIDR, trayendo consigo soluciones a algunas situaciones, entre ellas, poder hacer supernetting (es decir, poder apagar bits de derecha a izquierda) e intentar reducir la cantidad de prefijos de red. Es importante destacar que el RFC 1338 también mantuvo conceptos similares.

Finalmente, la notación de prefijo (/nn) también aparece gracias a CIDR lo que se hace posible una vez más gracias a la continuidad de los bits encendidos y apagados de la máscara de red.

En resumen, el objetivo de CIDR era enlentecer el crecimiento de las tablas de enrutamiento y buscar ser más eficientes en la utilización del espacio de direcciones IP.

Timeline

Conclusiones

El concepto de máscara de red ha evolucionado notablemente desde su origen, desde su no-existencia en un esquema plano (flat), luego rígido a un modelo flexible con CIDR. Inicialmente, las redes classful y las máscaras discontinuas generaban ineficiencia y problemas de escalabilidad a medida que Internet crecía.

Un cambio clave fue la exigencia de continuidad en los bits encendidos, lo que simplificó el proceso de selección de rutas y permitió a los routers operar más eficientemente.

Este documento informativo resalta los hitos clave y las motivaciones detrás de la evolución del direccionamiento IP y enfatiza la importancia de comprender el contexto histórico para apreciar plenamente la arquitectura actual de Internet.

Referencias

RFC https://datatracker.ietf.org/doc/html/rfc1338

RFC https://datatracker.ietf.org/doc/html/rfc1380

RFC https://datatracker.ietf.org/doc/html/rfc1519

RFC https://datatracker.ietf.org/doc/html/rfc790

Hilo de la lista de correo de ISOC “Internet History” llamado “The netmask”: https://elists.isoc.org/pipermail/internet-history/2025-January/010060.html

BGP Dynamic Capabilities / Capacidades Dinámicas en BGP

 

El video muestra el funcionamiento del concepto "BGP Dynamic Capabilities" donde dos peers BGP pueden comunicarse sus capacidades "on the fly" sin interrupción de la sesión. El demo fue contruido con FRR hablando BGP sobre IPv6 y utilizamos como demostración la capacidad extended-nexthop la cual no es anunciada en el mensaje Open inicial. Un video enriquecedor que demuestra una vez más la enorme flexibilidad del protocolo BGP

El Gran Enredo de IPv6 y RPKI

Había una vez, en un mundo digital muy lejano conocido como Netland, un grupo de direcciones IP que estaban hartas de ser ignoradas. Eran las "modernas" direcciones IPv6, que, a pesar de su impresionante capacidad y flexibilidad, siempre se sentían opacadas por su predecesor, el venerable IPv4. Todo el mundo hablaba de él, y los routers lo adoraban. "¡Pero nosotros también somos geniales!", se quejaban las direcciones IPv6. "¡Es hora de mostrarles lo que valemos!"

Así que un día, decidieron organizar una fiesta épica para demostrar su relevancia, la llamaron la YottaFiesta en honor a que las megafiestas ya no son tan grandes 🙂 . Invitaron a todos los routers, switches, firewalls e incluso algunos servidores curiosos. La invitación decía: "¡Ven a la fiesta más grande del ciberespacio! Solo direcciones IPv6, pero no digas nada, ¡es una sorpresa!" Sabían que las loopback no podrían asistir porque no pueden salir de donde están, pero por si acaso, estaban oficialmente invitadas.

El problema fue que, en lugar de sencillamente enviar a los routers a la fiesta, las direcciones IPv6 se dieron cuenta de que no todos sabían cómo llegar. Como los routers estaban tan acostumbrados a trabajar con IPv4, se encontraron totalmente perdidos. "¿Cómo diablos llegamos a esa dirección con 128 bits?" se preguntaban. "¿Dónde está el next-hop para esta dirección?"

Mientras tanto, en otro rincón del mundo cibernético, RPKI intentaba asegurarse de que las rutas IP fueran seguras. Pero cada vez que trataba de verificar una dirección, se encontraba con un caos total. "¿Por qué hay tantas direcciones no válidas flotando por aquí? ¡Esto es un completo lío!" se lamentaba RPKI, mientras sacaba su llave de validación digital.

Sin embargo, NAT64, siempre buscando soluciones creativas, tenía un plan para hacer que IPv6 y IPv4 pudieran convivir. Decidieron crear una puerta secreta entre los dos mundos. Pero, en lugar de simplemente conectarlas, NAT64 y sus amigos decidieron hacer una broma. Se disfrazaron de direcciones IPv4 y comenzaron a enviar mensajes a los routers: "¡Hola! Soy una dirección IPv4, ven a mi fiesta, ¡en la famosa 192.168.1.1!"

Los routers, confiados de que era una dirección conocida, comenzaron a seguir las instrucciones al pie de la letra. Se pusieron sus mejores configuraciones, con el protocolo clásico de IPv4, y comenzaron a enrutar los paquetes hacia ese destino como si nada. Dentro de sí pensaban: "ojalá llegue un paquete IPv4 para enrutarlo de forma nativa en mi red IPv6 only con la elegancia del RFC 8950"

Pero al llegar al lugar, se encontraron con algo muy diferente. En lugar de la fiesta, lo que había era una revisión de seguridad en la puerta. RPKI, que estaba haciendo de portero, tenía instrucciones muy claras: "¡Solo pueden entrar direcciones IPv6 con ROAs válidos!"

Y justo detrás de él, el Firewall, implacable, no dejaba pasar ni a las direcciones bogon. Los pobres routers, que se pensaban que estaban a salvo con una dirección IPv4, fueron redirigidos a un portal que decía: "¡Feliz Día de los Inocentes! ¡Tú eres el verdadero inocente!"

Mientras tanto, RPKI observaba todo el caos y no podía evitar reírse: "Nunca más voy a confiar en estas direcciones traviesas. ¡Son más difíciles de rastrear que una ruta con ASNs descontrolados!" pensó mientras se ajustaba su sombrero de seguridad.

Y así, el mundo digital celebró ese Día de los Inocentes con risas, caos y un recordatorio muy importante: en el ciberespacio, las direcciones IP siempre tienen una sorpresa bajo la manga. ¡Nunca subestimes una IPv6 disfrazada de IPv4!

¡Feliz día de los inocentes!

Una mejora práctica en el Transporte DNS sobre UDP en IPv6

Por Hugo Salgado y Alejandro Acosta

Introducción y planteamiento del problema

En el presente documento queremos discutir sobre un draft (borrador de trabajo para convertirse en un estándar) existente en IETF que llamó nuestra atención, es un documento que involucra dos mundos muy interesantes: IPv6 y DNS. Este draft introduce algunas mejores prácticas para el transporte de DNS sobre IPv6.

El draft se titula “DNS over IPv6 Best Practices” y se puede encontrar aquí.

¿De qué trata el documento y qué busca solucionar?

El documento describe un enfoque sobre cómo el Protocolo de Nombres de Dominio (DNS) debería transmitirse sobre IPv6 [RFC8200].

Se han identificado algunos problemas operativos al enviar paquetes de DNS a través de IPv6, el draft busca solucionar estos problemas.

Contexto técnico

El protocolo IPv6 exige un tamaño mínimo de unidad de transmisión (MTU) de 1280 octetos. Según la Sección 5 “Problemas de tamaño de paquete” del RFC8200, se establece que cada enlace en Internet debe tener un MTU de 1280 octetos o más. Si un enlace no puede transmitir un paquete de 1280 octetos en una sola pieza, se debe proporcionar el servicio de fragmentación y reensamblaje específicos del enlace en una capa inferior a IPv6.

Funcionamiento exitoso de PMTUD en un ejemplo adaptado a MTU de 1280 bytes

Imagen tomada de: https://www.slideshare.net/slideshow/naveguemos-por-internet-con-ipv6/34651833#2

Utilizando el Descubrimiento de MTU de Ruta (PMTUD) y la fragmentación en IPv6 (solo en el origen), se pueden enviar paquetes más grandes. Sin embargo, la experiencia operativa indica que enviar grandes paquetes de DNS sobre UDP en IPv6 resulta en altas tasas de pérdida. Algunos estudios -ya de muchos años, pero sirven de contexto- han encontrado que aproximadamente 10% de los routers en IPv6 descartan todos los fragmentos IPv6, y 40% de ellos bloquean los mensajes “Packet Too Big”, que hacen imposible la negociación de los clientes. (“M. de Boer, J. Bosma, ”Discovering Path MTU black holes on the Internet using RIPE Atlas”)

La mayoría de los protocolos de transporte modernos, como TCP [TCP] y QUIC [QUIC], incluyen técnicas de segmentación que permiten enviar flujos de datos más grandes sobre IPv6.

Un poco de historia

El Sistema de Nombres de Dominio (DNS) fue definido originalmente en los documentos RFC 1034 y RFC 1035. Está diseñado para funcionar sobre diferentes protocolos de transporte, incluyendo UDP y TCP, y más recientemente se ha extendido para operar sobre QUIC. Estos protocolos de transporte pueden utilizarse tanto en IPv4 como en IPv6.

Al diseñar el DNS, se estableció un límite en el tamaño de los paquetes DNS transmitidos por UDP a 512 bytes. Si un mensaje era más largo, se truncaba y se activaba el bit de Truncamiento (TC) para indicar que la respuesta estaba incompleta, permitiendo que el cliente intentara nuevamente con TCP.

Con este comportamiento original, UDP sobre IPv6 no excedía el MTU (unidad máxima de transmisión) del enlace IPv6, evitando problemas operativos por fragmentación. Sin embargo, con la introducción de las extensiones EDNS0 (RFC6891) se amplió el máximo hasta un teórico de 64KB, con lo que algunas respuestas superaban el límite de 512 bytes para UDP, lo que resultó en tamaños que podrían exceder el Path MTU, ocasionando conexiones TCP y afectó la escalabilidad de los servidores DNS.

Encapsulamiento de un paquete DNS en un frame ethernet

Hablemos de DNS sobre IPv6

DNS sobre IPv6 está diseñado para funcionar sobre UDP, así como TCP o QUIC. UDP solo proporciona puertos de origen y destino, un campo de longitud y una suma de verificación simple, y es un protocolo sin conexión. En contraste, TCP y QUIC ofrecen características adicionales como segmentación de paquetes, confiabilidad, corrección de errores y estado de conexión.

El funcionamiento de DNS sobre UDP en IPv6 es adecuado para tamaños de paquete pequeños, pero se vuelve menos confiable con tamaños más grandes, especialmente cuando se requiere fragmentación de datagramas IPv6.

Por otro lado, DNS sobre TCP o QUIC en IPv6 funciona bien con todos los tamaños de paquete. Sin embargo, el uso de un protocolo con estado como TCP o QUIC exige más recursos del servidor DNS (y otros equipos como Firewall, DPIs, IDS, etc), lo que puede afectar la escalabilidad. Esta puede ser una compensación razonable para servidores que necesitan enviar paquetes de respuesta DNS más grandes.

La sugerencia del draft en cuanto a DNS sobre UDP recomienda limitar el tamaño de los paquetes de DNS sobre UDP en IPv6 a 1280 octetos. Esto evita la necesidad de fragmentación IPv6 o el descubrimiento del MTU del camino (Path MTU Discovery), lo que asegura una mayor confiabilidad.

La mayoría de las consultas y respuestas DNS encajarán dentro de este límite de tamaño de paquete y, por lo tanto, se pueden enviar a través de UDP. Los paquetes DNS más grandes no deben enviarse por UDP; en su lugar, deben ser enviados a través de TCP o QUIC, como se menciona en la siguiente sección.

DNS sobre TCP y QUIC

Cuando se necesitan transportar paquetes DNS más grandes, se recomienda utilizar DNS sobre TCP o QUIC. Estos protocolos manejan la segmentación y ajustan de manera confiable su tamaño de segmento para diferentes valores de MTU del enlace y del camino, lo que los hace mucho más fiables que el uso de UDP con fragmentación IPv6.

La sección 4.2.2 del [RFC1035] describe el uso de TCP para transportar mensajes DNS, mientras que el [RFC9250] explica cómo implementar DNS sobre QUIC para proporcionar confidencialidad en el transporte. Además, los requisitos operativos para DNS sobre TCP están descritos en el [RFC9210].

Seguridad

El cambio de UDP a TCP/QUIC para respuestas grandes implica que el servidor DNS debe mantener un estado adicional para cada consulta recibida a través de TCP/QUIC. Esto consumirá recursos adicionales en los servidores y afectará la escalabilidad del sistema DNS. Además, esta situación puede dejar a los servidores vulnerables a ataques de Denegación de Servicio (DoS).

¿Esta es la manera correcta?

A pesar de que sí creemos que esta solución aportará muchos beneficios al ecosistema de IPv6 y DNS, se trata de un parche operativo temporal, pero que no resuelve la solución de raíz.

Creemos que la solución correcta es que la fragmentación en el origen funcione, que PMTUD no se encuentre roto en el camino, y que las cabeceras de fragmentación sean permitidas por los dispositivos de seguridad. Esto requiere de cambios en distintos actores de Internet que puede tomar bastante tiempo, pero no por eso debemos abandonar la educación y los esfuerzos por lograr hacer lo correcto.

Ampliando el Espacio de Documentación en IPv6

Introducción y un poco de historia

Primero hablemos un poco sobre los prefijos IP de documentación, el objetivo de estos prefijos es que sean exclusivamente utilizados en libros, textos, ejemplos, tutoriales, etc y que no sean enrutados en Internet.  Su éxito ha traído consigo también mayores necesidades, esto me recuerda a un dicho muy sabio que reza: los problemas de hoy fueron las soluciones de ayer.

Segundo, por otro lado, algo muy interesante está ocurriendo en el marco de IETF y específicamente dentro del working group v6ops.  Lo que   está ocurriendo es que hace exactamente 10 años un grupo de profesionales (incluido este humilde servidor) intentamos expandir el espacio de documentación en el mundo de IPv6 [1]. Lastimosamente este intento no procedió y quedó en el tintero.

Finalmente, hoy en día existe un ID (Internet Draft) que pensamos lo va a lograr (convertirse en RFC), el mismo tiene como nombre: “Expanding the IPv6 Documentation Space”. Es un documento que apoyamos y creemos que es necesario e importante para la comunidad; claro, a su vez pensamos que era mejor retomar el draft de hace 10 años y rescatarlo, mecanismo perfectamente válido dentro del IETF.

¿Se necesitan prefijos de documentación?  Las direcciones privadas ¿no sirven para lo mismo?

Son conceptos diferentes y cada uno ataca problemas distintos. Ciertamente a veces se tienden a confundir, pero la concepción de cada uno busca diferentes soluciones.

Las direcciones privadas en IPv4 y aprovechamos y hablamos de las ULA -Unique Local Address- en IPv6 sus objetivos es que sean utilizadas en redes internas, es decir, son direcciones IPs que si estarán en uso en la red y configuradas en nuestros equipos (léase desde computadoras, hasta servidores pasando por impresoras y teléfonos móviles).  De hecho, muy probablemente el equipo con el que navegas este artículo tenga una dirección privada en este momento.

Por otro lado, las direcciones o prefijos IP de documentación buscan precisamente que sean utilizadas en documentos, revistas, ejemplos en la web, laboratorios y mucho más. Estos prefijos son muy importantes para garantizar la claridad y coherencia en la documentación topológica, sin  afectar la operatividad de una red. Por ejemplo, en el mundo de IPv6 las probabilidades que leas un documento en la web, un video ejemplo o en alguna revista es muy posible que el direccionamiento utilizado pertenezca al prefijo 2001:db8::/32.

Por último, ninguno de los prefijos privados y/o documentación deben ser enrutados en Internet, ni deben ser aceptados por ejemplo en routers que hablen BGP hacia proveedores de Internet.

Para el resto de este artículo nos enfocaremos en las direcciones IP de documentación que precisamente es el cambio que se avecina en el mundo de IPv6.

Sobre el draft actual “Expanding the IPv6 Documentation Space”

Es un documento de la autoría de Geoff Huston y Nick Buraglio. La primera versión se introdujo en el 2021 y actualmente va por la versión 03 que expira el 30 de noviembre de este año. Sin embargo, ya se encuentra en Last Call y con amplio apoyo por la mayoría de la comunidad. Nuestro pronóstico es que se convertirá en RFC tipo Informational prontamente.

¿Cómo ha sido el progreso del documento dentro de IETF?

¿Qué busca el draft?

Este documento propone reservar un prefijo adicional de direcciones IPv6 para ser utilizado en documentación. Actualmente se tiene el bloque de direcciones 2001:db8::/32 reservado para este fin, pero se sugiere expandirlo con un prefijo más grande, específicamente un /20.

Motivos

Esta ampliación permitirá que los ejemplos documentados reflejen de manera más precisa una gama más amplia de escenarios de implementación realistas y se alineen mejor con los modelos de asignación contemporáneos para grandes redes. Sin ir muy lejos, para aquellos que hemos dado cursos de IPv6, muchas veces nos hemos visto limitados en poder crear topologías y planes de direccionamiento IPv6 que se ajuste a muchas empresas y necesidades.

Argumentos

Se argumenta que con la expansión de la implementación global de IPv6, los escenarios individuales de implementación de redes IPv6 han aumentado en tamaño y diversidad, lo que hace que el prefijo 2001:db8::/32 original sea insuficiente para describir muchas topologías actuales de implementación realistas. La asignación de un /20 solucionará todas las limitaciones anteriores e incluso brindará nuevas posibilidades que se escapan de nuestra imaginación.

Alguna información que sustente lo anterior

Según los datos publicados por los Registros Regionales de Internet en agosto de 2023, aproximadamente el 25.9% de todas las asignaciones IPv6 registradas son mayores que un /32 en tamaño. Se destaca que la mayoría de las asignaciones son /29. Se cree que reservar un /20 cubriría las necesidades de documentación en relación con la amplia gama de despliegues ajustados a la realidad.  Como dato referencial, en un /20 tenemos 4096 /32s. En nuestra región podemos crear entre otros un plan de direccionamiento IPv6 para una multinacional que desee tener /32 en cada país de LATAM (y del mundo) sin ningún inconveniente.

Otros puntos importantes

Se recuerda que los prefijos de documentación no deben usarse para tráfico real, no deben anunciarse globalmente y no deben utilizarse internamente para tráfico productivo o conectividad. Es importante filtrar los prefijos de documentación en las publicaciones de prefijos de enrutamiento según corresponda.

Conclusiones

Creemos que este documento procederá en los próximos meses dentro de IETF, posteriormente contaremos con  un prefijo de documentación /20 que cubrirá a la perfección casi la totalidad del laboratorio de redes pensables y con ello los beneficios para el ecosistema de Internet y la promoción del protocolo IPv6.

Referencias

https://datatracker.ietf.org/doc/draft-ietf-v6ops-rfc3849-update/

https://datatracker.ietf.org/doc/html/draft-moreiras-v6ops-rfc3849bis-01

https://datatracker.ietf.org/doc/html/rfc3849

https://datatracker.ietf.org/doc/html/rfc5737