Resumen

  • La aplicación elige un group ID aleatorio, deriva las direcciones IPv6 y Ethernet y reclama esta última mediante un PTR mDNS bajo .eth-addr.arpa.
  • Un equipo de red puede añadir -veto a la primera etiqueta de la aplicación; ese registro siempre vence en el desempate mDNS y obliga al emisor a parar y elegir de nuevo.
  • La revisión 12 está en Last Call, no es un estándar aprobado, y no autentica ni las respuestas de conflicto ni a quien publica el veto.

En el puente de una embarcación, dos pantallas pueden elegir direcciones IPv6 distintas y aun así empujar al switch hacia el mismo destino Ethernet. El protocolo propuesto no niega esa realidad física. Le da una voz.

draft-ietf-pim-ipv6-zeroconf-assignment-12, publicado el 22 de septiembre de 2026, está en IETF Last Call hasta el 6 de octubre. Busca asignar direcciones multicast sin servidor central. La propuesta de rango 0x90000000-0x9FFFFFFF, el nombre eth-addr.arpa y el dominio especial correspondiente siguen pendientes de IANA.

Para un flujo nuevo, la aplicación sortea un identificador de 28 bits. RFC 4489 lo combina con el identificador de interfaz de la fuente y forma una dirección multicast IPv6 de alcance de enlace. RFC 2464 la reduce a un destino Ethernet. Esa reducción puede hacer que dos direcciones IPv6 terminen en la misma dirección de capa 2.

El borrador invierte cada nibble del destino Ethernet y construye un nombre. Su ejemplo convierte 33:33:9A:BC:DE:F0 en 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa. En ese nombre, un PTR apunta a un identificador único de aplicación seguido por el hostname.

El silencio abre la puerta

La aplicación hace probe del nombre conforme a RFC 6762. Si dos aspirantes coinciden, el perdedor del desempate mDNS vuelve a sortear. Si nadie se opone, anuncia el PTR, responde consultas y mantiene una consulta continua. Solo entonces puede transmitir.

La disponibilidad es implícita: no escuchar una objeción se interpreta como permiso. Pero una red filtrada puede ocultar la objeción. Un silencio observado no demuestra que todos los posibles contendientes recibieron el probe.

El group ID se guarda para reutilizarlo, aunque cada reinicio exige repetir construcción, probe, anuncio y vigilancia. Una red pudo cambiar mientras el equipo estaba apagado. El valor persistente es una preferencia anterior, no un arrendamiento.

Ante un conflicto posterior, la aplicación perdedora detiene el flujo antes de elegir otro ID. La pila del host también puede detectar direcciones IPv6 diferentes que convergen en el mismo destino Ethernet. El borrador exige que alguna aplicación se mueva, pero no coordina cuál entre varios hosts.

El sufijo que siempre gana

Si un componente de infraestructura detecta una colisión que no puede resolver, publica un PTR de veto bajo el mismo owner name. Añade -veto a la primera etiqueta del PTRDNAME original. En la comparación de RDATA, la longitud de la etiqueta aparece primero; la etiqueta más larga queda después en el orden lexicográfico y gana siempre el conflicto mDNS.

El equipo publica sin hacer probe. La aplicación derrotada para, sortea otro ID y sustituye el almacenado. Cuando el PTR original caduca o se despide, el titular del veto consulta durante cinco segundos; si no obtiene respuesta, espera entre 20 y 120 milisegundos al azar y retira el veto con un goodbye.

La configuración cero conserva una estructura de poder: la aplicación propone, los pares disputan, la infraestructura puede anular y el receptor todavía decide si el flujo reemplazado funciona.

Autoridad visible, identidad ausente

El diseño hereda la hipótesis cooperativa de mDNS. Un nodo malicioso puede responder a todos los probes o fabricar vetos, provocando denegación de servicio y cambios constantes. Filtrar mDNS causa el error contrario: varias aplicaciones pueden creer que el recurso está libre.

El registro ganador no prueba que lo emitió un switch con una colisión real. Un anuncio tampoco autentica al productor, autoriza el contenido ni demuestra entrega. La operación debe conservar identidad del flujo, group ID, IID fuente, destinos IPv6 y Ethernet, PTR, probe, anuncio, generación de consulta, emisor del conflicto, confirmación de parada, sustitución, migración del receptor y retirada del registro antiguo.

Las consultas continuas ayudan tras reparar una partición, pero mDNS puede tardar en detectar duplicados. El borrador deja fuera mecanismos suplementarios para redes donde nacen flujos durante el aislamiento. El gran espacio aleatorio reduce la probabilidad; no vuelve visible un paquete filtrado ni fusiona dos historias separadas.

RFC 10019 había formulado el problema sin elegir protocolo o ganador. La revisión 12 aporta una respuesta concreta y auditable. La lectura de Lu Heng sobre la primacía del código obliga a no exagerarla: el PTR expresa una reclamación, el desempate ejecuta control, el switch observa una condición física y la aplicación confirma el resultado. La virtud del veto no es que sea infalible, sino que hace visible una autoridad que antes quedaba escondida.

Fuentes