Resumen

  • RFC 10028 sustituye el espacio dinámico solapado de RFC 3307 por franjas distintas para MADCAP, asignación SSM desde el host, uso privado, experimentación y Solicited-Node.
  • La nueva tabla evita conflictos entre métodos sólo si el software desplegado la adopta. Un número dentro de su franja no acredita el origen de la asignación, la ausencia de colisión ni el estado de membresía, reenvío o recepción.

La herramienta de cumplimiento inspecciona una dirección multicast y aprueba sus 32 bits inferiores: 0xF0000010 pertenece a la nueva franja para grupos SSM elegidos por el host. El informe declara que la asignación cumple RFC 10028.

El informe no ha preguntado quién más asigna direcciones en ese alcance.

Un controlador MADCAP de reserva conserva el intervalo que aprendió de RFC 3307: desde 0x80000000 hasta 0xFFFFFFFF. Tras un cambio de alimentación vuelve a ser activo y entrega 0xF0000010 a otra aplicación. El asignador nuevo y el antiguo pueden producir registros internamente coherentes. En la red, ambos reclaman los mismos bits bajos.

Ésa es la frontera que convierte RFC 10028, publicado como estándar del IETF en agosto de 2026, en una cuestión de autoridad operativa. El documento corrige una partición defectuosa. La organización todavía debe demostrar que la partición llegó a cada ejecutable, configuración y ruta relevante.

El solapamiento era parte de la regla anterior

RFC 3307 llama identificador de grupo a los 32 bits inferiores de una dirección multicast IPv6 y los relaciona con el destino de capa de enlace. Para la asignación dinámica, reservó el mismo espacio tanto al modelo de servidor como al de host. Además, el tramo 0xFF0000000xFFFFFFFF coincidía con el uso Solicited-Node.

No se trataba únicamente de una probabilidad aleatoria. La propia clasificación permitía que dos mecanismos autónomos buscaran en el mismo dominio. Después de observar la dirección resultante, ya no era posible deducir qué mecanismo la había producido.

La tabla vigente del espacio multicast IPv6 de IANA refleja la reparación de RFC 10028:

  • MADCAP: 0x800000000x8FFFFFFF;
  • sin asignar: 0x900000000xEFFFFFFF;
  • asignación SSM por el host: 0xF00000000xFCFFFFFF;
  • uso privado: 0xFD0000000xFDFFFFFF;
  • uso experimental: 0xFE0000000xFEFFFFFF;
  • Solicited-Node: 0xFF0000000xFFFFFFFF.

La franja libre requiere Standards Action para futuras incorporaciones. RFC 8126 explica esta política y la necesidad de un control de cambios claro. El registro coordina clases y referencias; no concede una dirección de producción a una aplicación concreta.

La distinción importa. “Está en IANA” puede probar que existe una regla común. No prueba que el host la haya ejecutado, que el servidor haya reducido su pool o que un conmutador haya reenviado el flujo correcto.

Actualizar o impedir la coexistencia

RFC 10028 no se limita a dibujar casillas. Indica que las implementaciones MADCAP deben usar el intervalo reducido. Los despliegues existentes deben actualizarse o funcionar en un entorno sin otros protocolos de asignación multicast IPv6.

Es una obligación de migración expresada como dos alternativas operativas: actualización demostrable o aislamiento demostrable.

El RFC señaló, en el momento de redactarse, una implementación MADCAP conocida y ningún despliegue conocido a gran escala. Esa frase no autoriza a declarar vacío el inventario local. Equipos antiguos sobreviven precisamente en funciones de respaldo, sistemas encapsulados y redes que se modifican con poca frecuencia.

RFC 2730 describe MADCAP como un protocolo cliente-servidor. El cliente descubre, solicita y obtiene una oferta o una respuesta; el administrador conserva control sobre la política. Por ello, un ACK acredita una decisión del servidor, pero no la corrección de sus límites de pool bajo RFC 10028.

La evidencia útil incluye versión y compilación del servidor, hash de configuración, límites efectivos, identidad del cliente, alcance solicitado, identificador de arrendamiento, inicio, vencimiento y renovación. También debe cubrir nodos pasivos y configuraciones que sólo aparecen durante una recuperación.

La colisión desciende a Ethernet

RFC 4291 define la forma de las direcciones multicast IPv6, su ámbito y el identificador de grupo. Un grupo transitorio existe dentro de un alcance. Conectar dos alcances administrativos que antes estaban separados cambia el problema.

RFC 2464 transforma el destino multicast IPv6 en una dirección Ethernet 33:33 seguida de los últimos cuatro octetos. Los bits que el asignador eligió llegan así a filtros de interfaz y tablas de conmutación.

RFC 10019 muestra por qué esto importa en redes zeroconf. Una colisión puede obligar a filtrar tráfico no deseado en software, reducir la utilidad del snooping, sobrecargar enlaces lentos o agotar estructuras limitadas de hardware. Una partición de red puede ocultar la duplicidad y la reconexión puede revelarla.

El mismo RFC exige que una futura solución descentralizada detecte y resuelva conflictos, incluso migrando los flujos. No define esa solución terminada. RFC 10028 facilita su coexistencia con otros métodos al reservarle territorio; no ejecuta la detección.

SSM cambia el significado de unicidad

En RFC 4607, un canal SSM se identifica mediante (S,G): una fuente y un grupo. Dos fuentes pueden reutilizar G sin formar el mismo canal. RFC 8815 subraya que esta propiedad elimina la necesidad de unicidad global de G en el rango SSM.

Pero el receptor debe conocer S; la aplicación y la pila deben soportarlo; la membresía tiene que llegar al plano de control; y el camino debe aplicar el estado adecuado. RFC 10028 advierte que SSM no es universal.

RFC 4541 documenta límites de conmutadores con snooping y los errores que surgen cuando las versiones o capacidades no coinciden. RFC 10019 añade que algunos equipos baratos sólo manejan el destino MAC, no la fuente. Una aplicación puede creer que pidió (S,G) mientras un tramo de capa 2 sólo distingue G.

La auditoría debe conservar por separado la solicitud (S,G), el informe MLD o IGMP, la entrada de snooping, el estado de ruta y una sonda que reconozca el contenido o la fuente esperados.

Uso privado y experimento necesitan una puerta de salida

Private Use permite selección local, por ejemplo en una instalación aislada. No garantiza que dos instalaciones elijan valores diferentes. Toda interconexión, adquisición o enlace temporal debe tratarse como una posible colisión y no como una mera modificación física.

Experimental Use permite probar nuevos mecanismos. La etiqueta no certifica seguridad, autorización ni compatibilidad. Un experimento requiere propietario, alcance, fecha de expiración y retirada verificable. La franja no asignada no es una reserva informal del operador, y Solicited-Node no es espacio dinámico sobrante.

Las categorías son límites de coordinación, no sustitutos de gobernanza local.

Conservar la época de la regla

Cada asignación debe registrar la revisión normativa, clase y versión del asignador, hash de configuración y evento de selección. Añadir dirección IPv6 completa, alcance, identificador de grupo, destino Ethernet, aplicación, identidad del flujo y ciclo de vida del arrendamiento. En SSM, la fuente forma parte del identificador.

Después, enlazar la asignación con las pruebas vivas: otros asignadores presentes, sondeos de conflicto, membresía MLD/IGMP, tablas de snooping y reenvío, primer y último paquete, tráfico inesperado, renumeración y retirada de estado antiguo.

No reducir a “correcto” seis hechos distintos: pertenencia a la franja, selección por un asignador identificado, ausencia de conflicto, membresía, reenvío y recepción por la aplicación.

La primacía del código en ejecución de Heng Lu sitúa la prueba en esta cadena. Su diseño de especificación inicial mínima y decisión futura localizada justifica una partición común estrecha sin convertir el registro en operador. Y su análisis de soberanía de datos formal y práctica ayuda a distinguir quién describe el espacio y quién controla la instancia que corre.

El registro ya se movió. La pregunta de producción es si los asignadores también lo hicieron.