Resumen

  • RFC 7872 probó tres construcciones concretas —DO8, HBH8 y FH512— contra conjuntos históricos de servidores web, correo y nombres. Sus tasas no describen Internet en 2026.
  • La atribución fuera del AS de destino era una horquilla condicionada a los paquetes ya perdidos. El método no podía demostrar una política intencional, una causa de fabricante ni la responsabilidad de un operador nombrado.

Una decisión del destino puede quedar anulada en tránsito

La observación importante de RFC 7872 es institucional además de técnica. Un destino puede estar preparado para procesar una cabecera de extensión; si otro dominio la descarta antes, la decisión del destino deja de ser efectiva. El tránsito se convierte en una superficie de control sobre una función que no eligió el tránsito.

Ese hallazgo debe leerse con fecha. RFC 7872 se publicó como Informational en junio de 2016 y documenta mediciones realizadas en agosto de 2014, repetidas en junio de 2015 con resultados similares. No es un sensor vivo. Una fecha reciente en Datatracker no vuelve contemporáneas sus muestras.

Los autores partieron de World IPv6 Launch y Alexa Top 1 Million. De cada lista obtuvieron servidores web mediante AAAA, servidores de correo mediante MX y luego AAAA, y servidores de nombres mediante NS y luego AAAA. Eliminaron duplicados, direcciones que no eran global unicast y objetivos considerados inalcanzables.

Después enviaron tres clases de sonda. DO8 incluía una cabecera Destination Options de ocho bytes rellenada con PadN. HBH8 hacía lo propio con Hop-by-Hop Options. FH512 generaba aproximadamente dos fragmentos IPv6 de 512 bytes. Todas usaban TCP y el puerto del servicio, por ejemplo 80 para web.

El alcance importa. No se ensayaron todas las opciones, cadenas, órdenes, tamaños, transportes, redes o políticas. Hablar de una tasa general de “cabeceras de extensión” borra la propia forma del experimento.

Total de pérdidas y lugar de pérdida no son la misma cifra

La primera cifra de cada celda es la tasa observada de pérdida. La horquilla entre paréntesis estima, entre los paquetes que ya se perdieron, qué parte cayó en un AS distinto del destino. Por tanto, la horquilla no comparte denominador con la tasa total.

En el conjunto web derivado de World IPv6 Launch, DO8 perdió el 11,88 %; del subconjunto perdido, el 17,60 % / 20,80 % se atribuyó fuera del destino según los supuestos mejor y peor. HBH8 perdió el 40,70 %, con 31,43 % / 40,00 % fuera de destino. FH512 perdió el 30,51 %, con 5,08 % / 6,78 %.

En los tres servicios de esa fuente, DO8 osciló entre 11,88 % y 17,07 %, HBH8 entre 40,70 % y 48,86 %, y FH512 entre 30,51 % y 39,17 %. En los conjuntos de Alexa, los intervalos fueron 10,91–21,33 %, 39,03–54,12 % y 28,26–55,23 %, respectivamente.

También cambió radicalmente el reparto aparente del control. Entre las pérdidas de web Alexa, la parte estimada fuera del destino fue 46,52 % / 53,23 % para DO8 y 53,64 % / 61,43 % para FH512. Para HBH8 contra servidores de nombres Alexa alcanzó 50,64 % / 81,00 %. FH512 contra correo de World IPv6 Launch, en cambio, dio 2,91 % / 12,73 %.

Estas diferencias desaconsejan tanto una conclusión complaciente como una alarmista. El estudio encontró pérdidas materiales, incluidas pérdidas posiblemente fuera del control del destino. No encontró una constante universal.

La frontera aparente depende de dos hipótesis

El procedimiento emparejó un traceroute con cabecera de extensión y otro sin ella. Llamó M al último salto que respondió en el primero e infirió el siguiente, M+1. Si el filtro se aplica antes de decidir el reenvío, el descarte se atribuye a M+1; si se aplica después, podría estar en M. El estudio adoptó el primer modelo.

Además, asumió que ambos traceroute siguieron la misma ruta. Los autores advierten que quizá no fuera así. La distribución de carga o una variación de enrutamiento puede crear una falsa continuidad entre dos observaciones.

Incluso con el salto correcto, falta la organización. Una dirección de peering puede pertenecer al espacio aportado por cualquiera de los pares. En un IXP puede identificar al exchange. El equipo de M+1 podría ser operado por la organización asociada a ese AS o al siguiente. Una organización puede mantener varios ASN, aunque el análisis trate cada ASN como organización distinta.

Por eso existe una horquilla: el mejor caso asigna la ambigüedad al destino; el peor, al tránsito. La incertidumbre no autoriza a rellenar el hueco con una intención imaginada.

Los RFC posteriores explican mecanismos, no culpables

RFC 7872 no distingue entre política deliberada, valor predeterminado inadecuado, límite de análisis, protección de recursos, error de software u otra causa. Que la pérdida esté en el AS de destino puede facilitar una corrección local; no la vuelve inocua. Que esté en tránsito puede impedir que el destino despliegue la función.

RFC 9098 expone dificultades operativas como análisis variable, camino lento, agotamiento de recursos y evasión. RFC 9288 ofrece recomendaciones de filtrado que dependen de la capacidad del equipo. RFC 9673 actualiza el procesamiento Hop-by-Hop con límites configurables. Ayudan a diseñar hipótesis, pero no revelan qué ocurrió en un paquete de 2014.

RFC 7045 aporta una referencia normativa de reenvío y RFC 8200 la arquitectura actual de IPv6. Ninguno convierte la tabla histórica en una prueba de conformidad de un fabricante. La redacción correcta progresa de “no hubo respuesta” a “la pérdida parece comenzar aquí bajo estos supuestos”; no salta a “este operador bloquea intencionadamente”.

La prueba moderna debe parecerse al servicio moderno

Antes de decidir, hay que fijar bytes y contexto: cadena y orden de cabeceras, opciones, longitudes, transporte, puertos, tamaño y fragmentación. Cada sonda debe tener un control sin cabecera hacia los mismos extremos y en la misma ventana, desde varios puntos autorizados.

Se conservan bytes, horas, respuestas, rutas y estado de enrutamiento. En extremos controlados, las capturas y contadores reducen la incertidumbre. El traceroute sirve para delimitar, siempre que el informe declare la posible diferencia de rutas y la posición desconocida del filtro respecto al reenvío.

Los resultados se separan por sonda y por camino de cliente, peer, tránsito, IXP y destino cuando la muestra lo permite. Cualquier cambio de ruta, política, aplicación o plataforma obliga a repetir. Un supuesto límite de tránsito se comparte primero con el operador como evidencia reproducible.

La decisión final debe ser concreta: esta construcción funcionó o falló para este servicio, desde estos orígenes, por estos caminos y durante este período. Esa precisión permite desplegar, limitar, ofrecer fallback o escalar sin fingir que se ha medido todo Internet.