Resumen

  • draft-ietf-pim-ipv6-zeroconf-assignment-12 presume que una dirección está disponible cuando la aplicación no recibe señal de que ya esté en uso. El valor de ese silencio depende de quién podía responder y de qué tráfico mDNS consiguió cruzar la red.
  • Guardar el identificador del grupo no elimina la obligación de sondear, anunciar, consultar continuamente y defender el PTR. Tras una partición, quien pierde el conflicto debe cortar el flujo, escoger otro valor y reemplazar el guardado.

La revisión 12 fue publicada el 22 de septiembre de 2026. La ficha congelada de Datatracker la muestra como Internet-Draft activo del grupo PIM, enviado al IESG y en IETF Last Call hasta el 6 de octubre. Aspira a Proposed Standard. No es todavía un RFC, una asignación IANA terminada ni evidencia independiente de interoperabilidad o despliegue.

El procedimiento propone que una aplicación escoja al azar un identificador para un nuevo flujo multicast IPv6 dentro del intervalo 0x90000000–0x9FFFFFFF. Con él y el identificador de la interfaz de origen forma una dirección multicast IPv6 de alcance de enlace y, a partir de esta, la dirección multicast Ethernet. El ejemplo del texto convierte 9abc:def0 en 33:33:9A:BC:DE:F0.

Después transforma esa dirección Ethernet en un nombre bajo .eth-addr.arpa, invirtiendo sus dígitos hexadecimales. Construye un PTR específico de la aplicación y del host; lo sondea con mDNS, lo anuncia, responde a preguntas, mantiene una consulta continua y lo defiende. Así coordina unicidad local sin introducir un asignador central.

La revisión nueva pone nombre al supuesto: disponibilidad implícita. Si la aplicación no recibe indicación de uso, da por libre la dirección. El propio borrador añade que un filtro mDNS en el host o en la red impide la coordinación y puede provocar colisiones.

Por tanto, el silencio necesita contexto. Un sondeo demuestra que no apareció una respuesta contradictoria en determinadas interfaces y rutas durante una ventana. No demuestra que no exista otro emisor detrás de una ACL, un reflector roto o una partición. La estimación n / 2^28 describe la probabilidad de coincidir al seleccionar al azar; no mide la cobertura del sondeo concreto.

Pensemos en un conmutador que cae y divide una instalación. En un lado vuelve un flujo con su identificador persistido. En el otro nace un flujo distinto y selecciona casualmente el mismo. Los dos sondean. Ninguno oye al otro. Ambos pasan a transmitir con una conclusión local aparentemente válida.

Al recuperarse el conmutador, la red vuelve a tener una sola superficie de observación. Para ese momento el borrador exige mantener una consulta PTR continua. Cuando aparece el conflicto, se aplica la resolución de mDNS: el perdedor detiene el flujo, regresa a la selección, elige otro identificador y sobrescribe el anterior en almacenamiento.

La detección puede no ser rápida. El texto advierte que mDNS está diseñado para usar poco ancho de banda y que, tras reparar una partición, puede tardar un tiempo significativo en encontrar la colisión del registro. No ofrece un límite máximo general. La exposición es mayor si los flujos pueden comenzar en cualquier momento.

Ese intervalo invalida una lectura superficial de salud. Dos emisores pueden figurar como correctamente anunciados. En Ethernet puede observarse el mismo destino multicast para destinos IPv6 distintos. Sin registrar el cambio de topología, un panel que solo conoce el PTR no sabe que el significado de su silencio ha cambiado.

El borrador permite una alarma adicional en la pila del host. Si detecta tráfico con la misma dirección multicast Ethernet de destino pero otra dirección multicast IPv6, la aplicación debe parar y reasignar. Basta con que se mueva una parte, aunque ambas pueden hacerlo. No se especifica cómo decidir entre hosts cuál cede.

La infraestructura dispone de un veto determinista. Un componente que detecta una colisión irresoluble crea un PTR cuyo primer rótulo recibe -veto. Así queda siempre después en el orden lexicográfico usado por mDNS y gana el conflicto. Se publica sin sondeo y obliga a la aplicación a abandonar la dirección.

El veto tiene caducidad operativa. Cuando desaparece o expira el PTR que causó el problema, quien emite el veto consulta durante cinco segundos. Si no encuentra respuesta, espera entre 20 y 120 milisegundos al azar y envía un goodbye. No hace falta guardar el veto porque la aplicación ya conserva el nuevo identificador.

Esa autoridad también puede abusarse. Respuestas falsas al sondeo pueden impedir que una aplicación encuentre dirección; vetos fabricados pueden desplazarla una y otra vez. Filtrar mDNS neutraliza la prevención de colisiones. El diseño funciona entre participantes cooperativos, una condición que no puede probar por sí mismo.

La persistencia tampoco sustituye a la observación actual. Reutilizar el valor guardado reduce cambios y ayuda a estabilizar un entorno que no se haya modificado. Pero la revisión 12 dice expresamente que no permite saltarse ningún paso anterior. Hay que sondear otra vez, anunciar, consultar de forma continua y defender. El almacenamiento dice «se usó antes», no «sigue siendo único ahora».

La primacía del código en funcionamiento conduce a exigir recibos del proceso. Selección, cálculo de las dos direcciones, sondeo, anuncio, consulta, defensa, parada y reemplazo deben poder reconstruirse. Un identificador inmutable no representa continuidad si la topología, el filtro o el conjunto de pares cambió mientras el emisor estaba fuera de línea.

También hay que contener el alcance de la afirmación. El PTR coordina una dirección; el borrador no establece cómo se anuncia al receptor la dirección del flujo. DNS-SD con _udp y un TXT aparece como opción natural, nada más. Incluso si el servicio se descubre, queda por probar la afiliación del receptor, el estado multicast, la entrega de paquetes y el resultado de aplicación.

En redes con varias subredes, los PTR deben distribuirse, por ejemplo mediante un reflector mDNS, y el propio texto presenta esa distribución como trabajo aún abierto. Un flujo reenviado necesita una dirección multicast IPv6 basada en prefijo unicast, no la dirección de alcance de enlace. La dependencia de hosts cooperativos lo hace inadecuado para Internet global.

La capa común puede ser mínima y útil: preservar unicidad local cuando los participantes se oyen. No debería transformarse en certificado de servicio. El registro operativo debe incluir identificador, interfaz de origen, direcciones derivadas, época de almacenamiento, interfaces sondeadas, alcance del reflector, filtros, partición, conflicto o veto, parada, nuevo valor y nuevo sondeo. Membresía, reenvío, paquetes y consumo pertenecen a recibos posteriores.

La pregunta decisiva no es si mDNS estaba habilitado, sino quién estaba en condiciones de contradecir la asignación. Sin esa respuesta, «libre» significa únicamente «nadie visible protestó todavía».

Fuentes