Resumen

  • RFC 9778 aplica Standards Action a los Types y Codes de IGMP y a los registros de flags de extensión; ofrece revisión y publicidad, no una prueba de soporte instalado.
  • Un analizador antiguo puede rechazar el valor desconocido y romper conectividad, o reenviarlo sin comprenderlo y perder cobertura de seguridad.
  • La preparación exige comprobantes separados de autoridad, publicación, implementación, decisión del analizador, interoperabilidad escalonada, efecto sobre el tráfico y reversión.

El problema aparece cuando una organización intenta convertir una propiedad del espacio de nombres en una propiedad de su red. IANA puede confirmar que el número fue asignado correctamente. No puede observar la rama que ejecutará un firewall concreto al leerlo.

RFC 9778, publicado en marzo de 2025 como BCP 57 y sustituto de RFC 3228, cambia a Standards Action la política del registro IGMP Type. Los campos Code de IGMP usan también Standards Action, y el documento que cree un Type nuevo debe fijar la política para su Code. Además crea registros para el mecanismo de extensión: en Query flags, el bit 0 es E y los bits 1 a 3 siguen sin asignar; en Report flags, el bit 0 es E y los bits 1 a 15 quedan sin asignar. Ambos requieren Standards Action.

No ocurre lo mismo con MLD Type y Code. Esos valores siguen dentro de ICMPv6 Parameters y bajo IETF Review. La diferencia impide hablar de una aprobación genérica para todo el control multicast: cada campo conserva su autoridad registral.

La revisión pública no ejecuta el código

RFC 8126 reserva Standards Action para documentos Standards Track o BCP aprobados por el IESG. El mecanismo mejora la coordinación: hace visible la propuesta, fuerza una referencia estable y abre la semántica a revisión. Pero su recibo termina en la asignación.

En producción comienza otra cadena. ¿Reconoce el valor la versión instalada? ¿Lo muestra el decodificador o lo reduce a “desconocido”? ¿La política de seguridad tiene una regla deliberada o cae en un valor por defecto? ¿Un dispositivo intermedio valida la longitud y la extensión completa? ¿Puede desactivarse la emisión sin alterar tráfico ajeno?

El propio RFC 9778 formula los dos extremos. Un firewall o NIDS puede declinar el tráfico que contiene un valor nuevo y desconocido, con pérdida de conectividad. También puede reenviarlo como parte de un ataque, con pérdida de seguridad. La primera conducta llama la atención; la segunda puede parecer disponibilidad perfecta precisamente porque nadie comprobó la nueva semántica.

RFC 6709 recuerda que extensiones desconocidas, campos antes reservados, implementaciones parciales y descartes silenciosos son fuentes conocidas de fallos. RFC 9279 separa extensiones bien formadas pero no soportadas de estructuras mal formadas. Esa regla normativa solo se vuelve comportamiento cuando cada parser y motor de políticas la implementa.

Un expediente que no mezcla capas

La autoridad prueba el documento y el procedimiento. La publicación conserva el estado de IANA y su fecha. La implementación identifica la versión exacta del software, firmware, decoder o ruleset. El analizador registra qué hizo ante casos conocidos, desconocidos y malformados. La interoperabilidad prueba combinaciones de emisores, receptores y controles viejos y nuevos. El impacto mide informes de pertenencia, pérdida, latencia, alarmas y recursos. La reversión demuestra tiempo y alcance de recuperación.

Si se funden estas siete piezas, un resultado legítimo contamina a los demás. El alta en IANA pasa a significar “soportado”; una captura posterior al firewall pasa a significar “inspeccionado”; un laboratorio con dos equipos nuevos pasa a significar “red mixta preparada”. Ninguna equivalencia es válida.

La distinción de Heng Lu entre registro coordinador y realidad en ejecución permite conservar el valor de ambos. El símbolo común organiza a la comunidad. El código en marcha decide el paquete. El control serio exige observar de nuevo cuando se cruza esa frontera.

Ensayar el valor y también el desconocimiento

Un ensayo hipotético debería comenzar con inventario y versión de cada lector de IGMP o MLD: host, switch, router, firewall, sensor, broker, colector y herramienta de diagnóstico. Tras fijar un tráfico base, introducir por separado el valor propuesto, otro no asignado, una extensión desconocida bien formada, casos de longitud o checksum erróneos y pares de generaciones distintas.

No basta con guardar paquetes. En cada salto hay que anotar si el campo fue reconocido, ignorado por regla expresa, rechazado, alertado o reenviado sin veredicto semántico. Después se relaciona la decisión con el estado multicast y con el tráfico real. Un canario limitado debe tener umbrales previos: rechazos, informes ausentes, modo fallback, presión de CPU, divergencia de estado o pérdida inexplicada. La emisión anterior y la política anterior deben poder restaurarse de forma independiente.

Fuentes

  1. RFC 9778
  2. RFC 3228
  3. RFC 8126
  4. RFC 6709
  5. RFC 9279
  6. RFC 9776
  7. RFC 9777
  8. RFC 4443
  9. IANA — IGMP Type Numbers
  10. IANA — ICMPv6 Parameters
  11. Heng Lu — Running-code primacy
  12. Heng Lu — Minimum initial specification
  13. Heng Lu — Reality layers