Resumen

  • Tener dirección, ruta BGP y conectividad IPv6 ordinaria no demuestra el paso de Fragment, Destination Options, Hop-by-Hop o Routing Header. La capacidad pertenece a una prueba con ruta, dirección, cadena y fecha explícitas.
  • RFC 7872 y mediciones posteriores de APNIC y RIPE registraron pérdidas relevantes, pero dependientes del tipo, tamaño, servidor, población y método. Son evidencia histórica de heterogeneidad, no un porcentaje mundial para 2026.
  • Quien opera el parser, firewall o servicio DDoS posee el poder de admisión real; el fabricante fija su coste. La tendencia puede rechazarse con una matriz multivendor, y la alternativa creíble es un contrato de capacidad acotado con diagnóstico y caducidad.

La grieta entre paneles correctos

IPv6 usa una cabecera base de 40 bytes y una cadena opcional. Cada campo Next Header conduce al siguiente hasta encontrar TCP, UDP u otro protocolo superior. Un equipo que aplica reglas por puerto debe recorrer esa cadena.

La ruta no comparte un único presupuesto. Cada ASIC tiene etapas y memoria de análisis; cada firewall, nube y servicio DDoS fija límites y capacidad de vía lenta. Un paquete básico puede viajar a velocidad de línea y otro del mismo flujo, con la capa 4 a 64 o 128 bytes, puede terminar en CPU, rate limit o descarte.

RFC 7045 dice que un nodo de reenvío no debería descartar por la mera presencia de cabeceras estándar y que un firewall que las inspecciona debe reconocerlas adecuadamente. También conserva la política intencional. La norma coordina el formato; no instala silicio en un tercero ni obliga a asumir carga ilimitada.

RFC 7112 exige que el primer fragmento incluya la cadena completa hasta la capa superior. Eso permite inspeccionar, pero no garantiza que todo equipo llegue a esa profundidad. RFC 9098 explica que, salvo la MTU, no existe un tope común a la cadena; para conocer el puerto hay que analizarla secuencialmente. Por eso “soporta IPv6” no define el producto entero.

Los porcentajes necesitan apellido y fecha

RFC 7872, publicado en 2016, probó servidores web, de correo y de nombres de World IPv6 Launch y Alexa Top 1M. En web World IPv6 Launch, observó 11,88% de pérdida con ocho bytes de Destination Options, 40,70% con ocho bytes Hop-by-Hop y 30,51% en la condición Fragment. En web Alexa: 10,91%, 39,03% y 28,26%. La condición Fragment para servidores de nombres Alexa llegó a 55,23%.

La comparación prueba que la cabecera y el destino importaban. No prueba la tasa actual. La lista de destinos, construcción del paquete, ruta y periodo forman parte del dato; eliminarlos convierte una medición reproducible en decoración estadística.

APNIC cambió la dirección del ensayo y reclutó clientes mediante anuncios. En 2022 describió unos cuatro millones de mediciones diarias. El seguimiento de 2023 probó PadN de Destination Options y Hop-by-Hop de 8, 16, 32, 64 y 128 bytes, además de tamaños Fragment de 1.200 a 1.416 octetos.

El artículo de APNIC de 2023 indicó cerca de 30% de pérdida Destination Options hasta 64 bytes y cerca de 55% a 128, tras un cambio sin causa identificada de aproximadamente 90% a 55% en abril. El mismo artículo de APNIC informó que, entre el 27 de abril y el 15 de mayo de 2023, un servidor de la Universidad de Aberdeen generó 370.742 pruebas Hop-by-Hop para una muestra británica: 99,04% de pérdida total, 98,25% a 8 bytes y 99,99% a 128.

El resultado no señaló automáticamente al culpable. Había variación por ASN de acceso y los autores no resolvieron si el descarte estaba en hosting, red virtual, tránsito o extremo. Esa incertidumbre no debilita el tema: demuestra que hace falta mover de forma controlada la fuente, el servicio y el dispositivo.

RIPE Atlas publicó una referencia vecina sobre tamaño y fragmentación: alrededor del 10% de las sondas IPv6 participantes mostró problemas, pero ya existía cerca de 11% de pérdida total en la prueba de 100 bytes. Participaron unas 1.284–1.292 sondas según tamaño, y RIPE advirtió que no sabía extrapolar al Internet general. Toda tasa EH debe condicionarse a que el control ordinario funcionó en la misma ruta.

Hardware, política y poder práctico

Cisco documenta para plataformas concretas recursos fijos de análisis, un ejemplo de cadena EH de 64 bytes en hardware y paso a software cuando se supera el recurso con filtros superiores. La guía Cisco IOS XR 7.1.1 para NCS 5500 distingue line cards: algunas manejan cabeceras específicas en hardware; en otras condiciones no se admite matching de capa 4 con EH.

Juniper ofrece criterios extension-headers y diferencias de plataforma; en una superficie IDS, si falta allow-ipv6-extension-header, cualquier EH queda bloqueada. Nokia expone modos ipv6-eh max y limited; la versión citada busca hasta seis cabeceras en ciertos filtros.

No es un ranking de marcas. Es prueba de que profundidad, tipos, defaults y vía rápida son atributos de producto. El cliente de una nube puede heredar esa decisión sin conocer siquiera el equipo.

Hay costes de seguridad legítimos. RFC 8504 permite límites de tamaño y número. RFC 8883 define errores ICMPv6 para cabecera demasiado grande, cadena demasiado larga y exceso de cabeceras u opciones. RFC 9288 organiza recomendaciones de filtrado. RFC 9673 actualizó en 2024 el tratamiento Hop-by-Hop para hacerlo selectivo y desplegable. RFC 9740 añadió en 2025 campos IPFIX de tipos, recuentos, longitud y exportación incompleta. RFC 9805 deprecó Router Alert para nuevos protocolos.

Un código ICMP definido no demuestra que exista ni que regrese por el camino inverso. La solución no es exigir procesamiento infinito: es declarar el límite, medir su efecto y evitar el silencio.

Una matriz que puede desmentir la tesis

Durante 90 días: tres familias de acceso, tres de tránsito y tres de cloud/DDoS; tres familias de silicio, tres firewalls y tres stacks; 100 pares de ruta por familia. Comparar control IPv6, Fragment, Destination Options, Hop-by-Hop y Routing/SRH.

Usar 8, 16, 32, 64 y 128 bytes EH agregados; orden recomendado y otro válido; TCP, UDP y UDP tipo QUIC; paquetes de 256, 1.200 y 1.400 bytes; 100 repeticiones por celda. Medir entrega, silencio, p95, throughput, ICMP, fast/slow path y CPU controlada.

Rechazar la tendencia solo si todas las celdas válidas quedan a 0,1 punto de la entrega control, hay como máximo un descarte silencioso específico por 100.000, latencia y throughput dentro de 2%, CPU menos de cinco puntos, ninguna discontinuidad hasta 128 bytes y 99,9% de excesos deliberados devuelven el RFC 8883 esperado. Tipo, bytes, orden, equipo y política no deben predecir más que la conectividad, y nuevos usos deben crecer sin túnel, allowlist, sonda o reemplazo.

La evidencia la refuerza si una EH válida de 8 bytes crea más de cinco puntos de diferencia en 10% de rutas; aparece un corte 64–128; p95 sube 25%; throughput cae 20%; CPU aumenta 15 puntos; más de la mitad de límites no devuelve ICMP; o cambiar solo dispositivo, firmware, DDoS o ruta cambia el resultado. Son umbrales futuros, no cifras globales actuales.

Qué compra el titular de recursos

La asignación IPv6 prueba unicidad y registro. BGP prueba visibilidad de control. Ninguno compra procesamiento opcional en todos los proveedores. El titular debe separar cantidad, ruta, reachability básica y capacidad EH.

Debe pedir tipos y límites, vía rápida/lenta, default del firewall, contadores RFC 8883 y caducidad tras cambios de firmware, chasis, cloud o política; además, probar ambos sentidos. Un SLA que solo dice “IPv6” puede ser cierto y seguir sin contestar la pregunta útil.

IANA coordina identificadores, IETF sintaxis y expectativas, RIR asignación y registro. No operan el parser. El equipo en ruta posee poder material, no mandato global. Proteger la propia infraestructura es legítimo si la política es explícita, proporcional, diagnosticable y sustituible.

El lock-in se alimenta solo: las aplicaciones evitan EH por incertidumbre; el poco tráfico reduce la inversión; el hardware fijo conserva la incertidumbre. Un túnel o dominio SRv6 cerrado puede funcionar, pero cambia dependencia de ruta por dependencia de controlador.