Resumen

  • RFC 3307 reservaba 0x80000000-0xFFFFFFFF tanto para asignación dinámica por servidor como por host, e incluía el tramo usado por las direcciones Solicited-Node. Dos mecanismos conformes podían escoger el mismo identificador.
  • RFC 10028 crea un registro IANA con seis franjas: MADCAP, espacio sin asignar, asignación SSM por host, uso privado, uso experimental y Solicited-Node. La partición elimina ese solapamiento, no todas las colisiones multicast.
  • Mike McBride comparte la autoría con Nate Karstens y Dino Farinacci. El valor de su trabajo está en adelgazar la capa común: la tabla coordina el espacio; el software y los operadores deben demostrar que la nueva frontera llegó a la red.

Un registro puede arreglar una colisión sin observar un solo paquete. Basta con descubrir que el propio plano de asignación entregaba la misma parcela a dos formas de uso.

Eso ocurría con los 32 bits inferiores del identificador de grupo multicast IPv6. RFC 3307 permitía que un servidor asignara valores dinámicos y que un host los eligiera por sí mismo. Ambos mecanismos recibían todo el intervalo 0x80000000-0xFFFFFFFF. La parte 0xFF000000-0xFFFFFFFF, además, correspondía a direcciones Solicited-Node usadas por Neighbor Discovery.

La especificación no pedía a nadie que infringiera una regla. El problema era más incómodo: un servidor y un host podían obedecer y aun así producir el mismo número. El sistema común había confundido “dinámico” con “intercambiable”.

RFC 10028, publicada en agosto de 2026 en la vía de estándares del IETF, convierte ese espacio en un registro explícito. Sus autores son Nate Karstens, Dino Farinacci y Mike McBride. Este perfil se centra en McBride porque su trayectoria está ligada al multicast, no porque la solución le pertenezca en exclusiva.

El perfil del IETF capturado el 31 de agosto de 2026 lo muestra como presidente de PIM, delegado en MBONED y ANIMA, revisor del Routing Area Directorate y autor de nueve RFC. La propia RFC 10028 indica Futurewei como afiliación. Un texto histórico de la Open Networking Foundation aporta su relato profesional de 2017. Son datos fechados sobre una persona; no prueban control sobre IANA, un fabricante ni una red concreta.

Cuando la coincidencia viene de la regla

Los 32 bits inferiores de una dirección multicast IPv6 forman el group ID descrito por RFC 3307. En Ethernet, esos bits se proyectan directamente a la dirección multicast de enlace. El identificador no es por tanto un adorno editorial: influye en lo que una interfaz y un conmutador pueden separar.

MADCAP, definido en RFC 2730, usa una relación cliente-servidor. Un host solicita al servidor una dirección o un arrendamiento multicast. El futuro mecanismo zeroconf descrito como necesidad en RFC 10019 persigue otra propiedad: que un host pueda escoger sin depender de ese servidor. La coexistencia exige que ambos sepan qué parte del espacio les corresponde.

Un algoritmo aleatorio no resuelve una superposición normativa. Puede reducir la probabilidad de choque, pero no transforma dos reclamaciones sobre la misma zona en dos zonas diferentes. Tampoco protege el extremo ya ocupado por Solicited-Node, cuyo uso se deriva de la arquitectura IPv6 y no de uno de esos allocators dinámicos.

RFC 10019 amplía el diagnóstico. Las colisiones pueden producir entrega innecesaria a una interfaz, erosión del beneficio de filtrar en la capa de enlace y presión sobre tablas o depósitos hash de un switch. Una solución descentralizada debe detectar y resolver conflictos, incluso después de que particiones temporales de red se reúnan.

RFC 10028 retira una causa anterior a todos esos algoritmos: deja de asignar el mismo intervalo a mecanismos distintos.

Las seis franjas y lo que cada una puede afirmar

El registro Dynamic Multicast Group IDs de IANA parte el espacio de este modo:

  • 0x80000000-0x8FFFFFFF: MADCAP;
  • 0x90000000-0xEFFFFFFF: sin asignar;
  • 0xF0000000-0xFCFFFFFF: elección por host de grupos SSM;
  • 0xFD000000-0xFDFFFFFF: uso privado;
  • 0xFE000000-0xFEFFFFFF: uso experimental;
  • 0xFF000000-0xFFFFFFFF: direcciones Solicited-Node.

El espacio ordinario libre requiere Standards Action para una asignación futura. Cada fila conserva rango, descripción y referencia. No guarda un inventario de productos, no mide tráfico, no declara que una aplicación sea segura y no decide quién puede escuchar un flujo.

Esa estrechez no es una carencia. El dato común indispensable es qué mecanismo puede elegir qué identificadores. La política de la aplicación, la implementación y la operación quedan más cerca de quienes pueden observarlas y asumir sus consecuencias.

Pero la frontera intelectual debe ser tan visible como la frontera hexadecimal. El registro evita que MADCAP y la asignación SSM por host reciban oficialmente la misma franja. No evita que diferencias situadas fuera de los bits proyectados terminen en una misma dirección Ethernet. No amplía una tabla finita del switch. No reconcilia por sí solo dos hosts aislados durante una partición. No impide el uso malicioso de una dirección válida.

Decir “RFC 10028 resolvió las colisiones multicast” borraría justamente la precisión que el documento introdujo. Resolvió una clase: el solapamiento entre dominios de asignación.

SSM no cabe entero en una dirección

La franja de host está reservada a Source-Specific Multicast. En SSM, el canal no se identifica solo por G, sino por el par (S,G): origen y grupo. RFC 4607 explica que dos fuentes distintas pueden reutilizar el mismo valor de grupo sin representar el mismo canal. Así disminuye la necesidad de coordinar globalmente cada G.

El ahorro de coordinación depende de que exista la coordenada S en todo el recorrido. La aplicación debe descubrirla. El sistema operativo necesita la interfaz adecuada. IGMPv3 o MLDv2 deben expresar la suscripción específica. El router designado y el dominio PIM deben mantener esa semántica. RFC 8815 considera SSM la dirección preferida para multicast interdominio, pero identifica el soporte de aplicación y acceso como trabajo real de despliegue.

Por eso RFC 10028 advierte que SSM no cuenta con soporte universal. La franja sirve en entornos que sí lo soportan. Escoger un group ID correcto no instala MLDv2, no enseña el origen a la aplicación y no valida que el emisor sea legítimo.

La idea de Heng Lu de una especificación inicial mínima resulta útil en este punto: la capa común debe contener la distinción necesaria para interoperar, no simular todas las decisiones futuras. La primacía del código en funcionamiento añade la prueba posterior. Una fila registral es una condición de coordinación; la adopción, la telemetría y el comportamiento observado convierten esa condición en realidad operativa.

La deuda de los implementadores de MADCAP

MADCAP pierde gran parte del intervalo que antes podía considerar suyo. RFC 10028 dice que los autores conocían una implementación y ningún despliegue a gran escala. “No conocido” no significa “inexistente”. La frase describe la evidencia disponible al redactar, y por tanto justifica prudencia, no olvido.

Una implementación anterior debe limitarse a 0x80000000-0x8FFFFFFF o funcionar en un entorno donde ningún otro mecanismo de asignación multicast IPv6 pueda chocar con ella. El cambio en IANA no modifica un ejecutable. Tampoco corrige un dispositivo sin mantenimiento ni una configuración copiada durante años.

La prueba de migración debe unir el valor al productor: nombre y versión del allocator, mecanismo, configuración, fecha de la regla y resultado observado. Sin esa procedencia, un incidente puede mostrar dos flujos en la misma dirección de enlace y no revelar si el responsable fue el antiguo intervalo, una compresión de mapeo, una partición o un actor hostil.

También existe una asimetría de percepción. El nuevo protocolo aparece después y suele disponer de mejor telemetría. Si tropieza con un servidor antiguo, puede parecer el causante aunque sea el único que respeta la partición actual. Un registro operativo sin procedencia castiga con facilidad al participante visible y conserva al obsoleto.

Unir declaraciones con observaciones

El RFC demuestra la decisión técnica colectiva. IANA demuestra el estado publicado de la tabla. Una prueba de unidad puede demostrar que cierto software restringe sus elecciones. Una captura de control puede demostrar una unión (S,G). Una observación de paquetes demuestra entrega desde un punto de vista y a una hora. Una política demuestra autorización.

Ninguna de esas evidencias hereda automáticamente las demás.

La tabla no prueba cuota de despliegue. La dirección SSM no prueba capacidad de la ruta. La entrega no autentica por sí sola la fuente. La falta de choque en una prueba no cubre otros scopes, otra topología ni la presión futura de hardware.

El registro local suficiente incluye allocator y versión, mecanismo, group ID, dirección completa, versión de RFC/IANA, requisitos SSM, método y resultado de detección de colisiones, observación de forwarding, validación del origen, autorización del receptor y responsable de reversión. Es una extensión del mismo principio que aplicó RFC 10028: no pedir a un campo que gobierne más realidad de la que puede describir.

McBride, Karstens y Farinacci no publicaron una promesa de que el multicast ya funcionara. Publicaron una frontera que deja de fabricar una colisión desde el plano común. Es una mejora modesta y decisiva.

El registro separó los carriles. Solo la red puede demostrar que los está usando.

Fuentes