Resumen

  • RFC 9947 obliga a mantener el TLV SRH experimental de Alternate Marking dentro de un dominio SR controlado, pero prevé compartir con el Independent Submissions Editor o el grupo IETF SPRING resultados obtenidos por operadores dispuestos a probarlo en redes vivas. Contener paquetes y autorizar evidencia son decisiones diferentes.
  • Un resultado público necesita un recibo de salida que una autoridad de divulgación, versiones, código experimental, cobertura de implementación, comparación con RFC 9343, cohortes de equipos, muestra, incertidumbre, resultados adversos, reglas de agregación, huellas y correcciones, sin exponer tráfico bruto, clientes ni topología aprovechable por un atacante.

Un experimento encerrado busca una decisión abierta

RFC 9947 apareció en marzo de 2026 como RFC Experimental del Independent Stream. La extensión se desarrolló fuera de la IETF, no tiene consenso de la IETF y no es candidata a ningún nivel de Internet Standard. Tampoco asigna un valor permanente mediante IANA.

Su propuesta es concreta. Para redes SRv6, coloca los datos de Alternate Marking en un TLV del Segment Routing Header. RFC 9343, que sí pertenece al Standards Track, los transporta mediante opciones IPv6 Hop-by-Hop o Destination. Ambos mecanismos pueden coexistir; el documento experimental no invalida al anterior.

La comparación pretende averiguar si el TLV SRH atraviesa mejor o peor una red, si su procesamiento mejora o perjudica el rendimiento frente a Destination Option, si las arquitecturas de dispositivo reaccionan de manera distinta, si la función convive con la programación SRv6 y el control de funciones SID, y qué utilidad operativa ofrecen sus campos ampliados ante otras formas de telemetría en el camino.

Esas respuestas no estaban disponibles al publicar el RFC. Por eso el texto espera que los resultados se reúnan y se compartan como Internet-Drafts con el Independent Submissions Editor o SPRING. Calcula que habrá resultados iniciales dentro de dos años. Ese horizonte sigue abierto y no autoriza a acusar a nadie de incumplimiento.

La paradoja productiva está en el lugar de la prueba. El RFC anticipa una sola red de proveedor de servicios porque así se respeta el dominio SR y porque existen límites reales para compartir datos de rendimiento recogidos a lo largo del trayecto de los paquetes. El experimento necesita confidencialidad para realizarse y publicidad para ser evaluado.

El control del dominio termina antes que el control editorial

La exigencia técnica es inequívoca: el experimento debe desplegarse únicamente en un dominio controlado. Un operador decide si usa Alternate Marking y cómo lo configura. Los nodos se administran localmente y los paquetes con el TLV experimental no deben entrar ni salir.

El tipo TLV se elige entre 124 y 126, valores experimentales. Las implementaciones participantes coordinan el número y conviene que el operador pueda configurarlo para evitar choques entre ensayos simultáneos. Se trata de una coordinación local, no de una licencia de despliegue.

Una regla de borde puede reconocer ese TLV. No puede evaluar un histograma exportado. No sabe si la combinación de hora, clase de tráfico y pocos dispositivos permite deducir una ruta; si una comparación por arquitectura divulga una debilidad comercial; ni si la ausencia de nombres protege a un cliente identificable por contexto.

Por eso la prueba de contención no es prueba de autorización. Que ningún paquete experimental abandone el dominio no indica quién aprobó la recogida, quién aprobó publicar la estadística, qué atributos se eliminaron ni cuánto valor probatorio se perdió al eliminarlos.

La palabra «implementado» es demasiado gruesa

El TLV básico contiene FlowMonID de 20 bits y marcas de pérdida y demora. La versión ampliada puede añadir otro identificador, modo por segmentos o de extremo a extremo, estado de fragmentación, dirección, marca temporal, instrucciones para vigilar el flujo inverso y número de secuencia. Esas instrucciones pueden considerar máscaras de origen y destino, protocolo, puertos, DSCP, alcance del túnel y periodo.

Activar todos esos campos no equivale a activar sólo los básicos. Cambian el trabajo del equipo y el alcance de la observación. También importa qué comportamiento SID decide procesar el TLV y qué nodos no admiten la función. Un nodo que lo ignora puede estar cumpliendo las reglas de SRH, no fallando.

La rama comparativa de RFC 9343 debe describirse con idéntico cuidado. Si se usan otros campos, otro tamaño de paquete, otra carga u otro camino, la diferencia observada no puede atribuirse sólo a SRH frente a Destination Option. Un promedio exacto puede responder a la pregunta equivocada.

Incluso el valor experimental debe quedar en la procedencia. Un emisor configurado con 124 y un receptor que espera 126 producen un vacío que parece incompatibilidad. Una colisión con otro experimento puede mezclar muestras. Registrar el número no lo convierte en permanente: conecta la medida con su configuración real.

Los metadatos pueden conservar una identidad

RFC 9343 señala que Alternate Marking no libera datos de usuario, pero eso no elimina la privacidad. FlowMonID puede facilitar seguimiento de flujos y varios puntos de observación pueden revelar rendimiento o camino. Los canales que llevan estadísticas al sistema de gestión deben estar protegidos.

RFC 9341 añade amenazas contra la integridad: manipulación del marcado o del tiempo, interferencia con la recogida y un posible canal encubierto de muy baja tasa. Un reporte que no explica sus relojes, contadores y controles de integridad puede atribuir al protocolo una distorsión de la medición.

RFC 8799 distingue la confidencialidad de los parámetros operativos que protege un limited domain de la privacidad de los usuarios. Ambas pueden afectarse en la salida. Borrar nombres y direcciones exactas no garantiza seguridad si quedan intervalos precisos, cohortes diminutas y una forma de topología reconocible.

Pero «confidencial» tampoco puede ser una goma que borre todo salvo la conclusión favorable. Sin denominadores, exclusiones y pruebas abortadas, un lector no puede saber si el resultado depende de una sola arquitectura o de seleccionar el mejor periodo. La salida correcta conserva relaciones metodológicas, no necesariamente observaciones individuales.

Qué debería certificar la salida

Primero, la autoridad. El registro debe nombrar al operador o patrocinador, el cargo que autorizó divulgar, el destino y la fecha de presentación, y cualquier relación material de financiación o suministro. Que ISE reciba un texto o SPRING lo discuta no significa aval, consenso ni ascenso al Standards Track.

Segundo, la identidad técnica. Debe unir la revisión del RFC o borrador, la compilación de cada implementación, el valor TLV, el subconjunto de campos, los comportamientos SID y la configuración equivalente de RFC 9343. Las huellas criptográficas pueden fijar artefactos protegidos sin publicarlos.

Tercero, la población. Conviene agrupar arquitecturas, software y firmware con suficiente detalle para explicar variaciones, pero sin crear un inventario vulnerable. Debe describirse la forma del camino sin revelar ubicaciones, además del intervalo, tráfico elegible, exclusiones, tratamiento de muestra, hipótesis de reloj y contador, y definiciones de pérdida, demora, jitter, supervivencia y coste de procesamiento.

Cuarto, el resultado y su transformación. Los éxitos deben aparecer junto a fallos, casos ambiguos y pruebas que activaron reversión. El registro explica qué atributos de flujo, camino, tiempo o proveedor se agregaron, redactaron o suprimieron; qué reproducción externa ya no es posible; qué material protegido podría someterse a revisión restringida; y cómo una corrección limita o sustituye una afirmación anterior.

Este recibo es una propuesta editorial de Daniel Kade, no una obligación escrita en RFC 9947. No es el conjunto de datos. Es el objeto mínimo que permite seguir la transformación entre una observación reservada y una afirmación pública.

El código que funciona no cambia el origen del RFC

RFC 7942 ofrece un modelo parcial. Su sección voluntaria Implementation Status permite indicar quién mantiene una implementación, su nombre, madurez y cobertura. Advierte que listarla no es un respaldo de la IETF y reconoce que la información cambia con el tiempo.

Sin embargo, RFC 7942 excluye expresamente el Independent Stream. No se puede imponer su procedimiento a RFC 9947. Sólo deja una disciplina útil: toda evidencia de implementación tiene fecha, alcance y responsable.

RFC 7841 protege la otra separación. Un RFC del Independent Stream no se convierte retroactivamente en consenso IETF aunque los resultados sean excelentes. La evidencia puede motivar trabajo, orientar un nuevo borrador o cambiar el juicio del grupo. Su fuerza no debe confundirse con la autoridad institucional del documento que inició el ensayo.

Límite de lo conocido

Las fuentes prueban el estatus de RFC 9947, sus campos, el dominio controlado, las preguntas comparativas y la expectativa de compartir resultados. También documentan los riesgos de privacidad e integridad y el contexto SRv6. No aportan un inventario de despliegues, resultados de operador ni datos públicos.

Este análisis no decide cuál técnica es superior. No afirma que falten resultados ni que estén atrasados. Tampoco pide paquetes brutos, identidades, topología exacta o secretos de proveedor.

Pide que, cuando una conclusión cruce la frontera, se pueda leer de dónde viene y hasta dónde alcanza. El tráfico protegido puede quedarse dentro. Afuera debe llegar una evidencia limitada, versionada y corregible. Así, el dominio controlado contiene el riesgo sin contener también la posibilidad de escrutinio.

Fuentes

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. Ficha de RFC 9947 en RFC Editor
  5. RFC 9947 — Alternate-Marking Method en Segment Routing Header
  6. RFC 9341 — Alternate-Marking Method
  7. RFC 9342 — Clustered Alternate-Marking Method
  8. RFC 9343 — Aplicación IPv6 de Alternate-Marking Method
  9. RFC 8799 — Limited Domains and Internet Protocols
  10. RFC 8402 — Segment Routing Architecture
  11. RFC 8754 — IPv6 Segment Routing Header
  12. RFC 8986 — SRv6 Network Programming
  13. RFC 7841 — RFC Streams, Headers, and Boilerplates
  14. RFC 7942 — Improving Awareness of Running Code