Summary

  • RFC 2375 reutilizó significados permanentes en varios ámbitos IPv6, pero estableció que dos direcciones que sólo diferían en el ámbito representaban grupos distintos y debían unirse por separado.
  • La asignación resolvía una cuestión de nombre y colisión; no demostraba oyentes, estado de reenvío, aceptación de una fuente ni recepción por la aplicación.

La primera lista no pretendía cerrar el futuro

El formato multicast de IPv6 necesitaba un vocabulario compartido. Los nodos y routers básicos, los protocolos de enrutamiento, NTP, las herramientas de conferencia y muchos experimentos ya dependían de números reconocibles en IPv4.

RFC 2375 publicó una selección inicial. Adaptó sólo las asignaciones IPv4 que parecían pertinentes, dejó fuera las que no lo eran, pidió comentarios y reservó todas las demás direcciones IPv6 multicast. La decisión importante no fue llenar una tabla, sino abrir el espacio de forma limitada y revisable.

Ese registro impedía que dos usos reclamaran el mismo valor. No afirmaba que el servicio nombrado estuviera encendido, desplegado o escuchado en ningún lugar.

Una X no convertía el alcance en infinito

Las asignaciones de ámbito fijo sólo valían en el ámbito indicado. Las de ámbito variable usaban X: el mismo significado permanente podía expresarse con cualquier valor legal de ámbito.

La especificación añadió la restricción que daba sentido al mecanismo. Las direcciones que sólo variaban en el ámbito eran grupos diferentes. Un nodo debía incorporarse a cada uno de ellos individualmente.

Así, un identificador podía seguir significando NTP en la interfaz, el enlace, el sitio o el ámbito global. Pero esas direcciones no compartían automáticamente oyentes. Cambiar el nibble de ámbito cambiaba la población a la que se dirigía el paquete.

El límite estaba dentro de la dirección

RFC 2373 definía el ámbito como el límite topológico del grupo y prohibía que los routers reenviaran más allá de él. «Todos los routers» no era un conjunto universal: todos los routers de una interfaz, de un enlace o de un sitio eran destinos distintos.

Con grupos transitorios, la identidad era todavía más local. La misma dirección temporal en otro sitio no guardaba relación necesaria con la primera. Tampoco la tenía el mismo identificador bajo otro ámbito ni un grupo permanente con igual valor.

La semejanza gráfica de dos direcciones no era una cadena de custodia. Sólo la dirección completa y su contexto operativo identificaban el grupo del que se hablaba.

La audiencia aparecía después

Una entrada permanente en la tabla acreditaba que un significado había sido reservado. No hacía que una aplicación pidiera recepción, no escogía una interfaz y no enseñaba al router que había un oyente vecino.

RFC 2710 introdujo esa segunda capa con Multicast Listener Discovery. Los routers podían descubrir qué direcciones interesaban en los enlaces conectados. Los hosts mantenían estado por dirección e interfaz, respondían a consultas y notificaban incorporaciones o salidas.

El registro y MLD eran recibos diferentes. Uno evitaba ambigüedad en el espacio común. El otro producía evidencia temporal y local de que alguien escuchaba. Incluso ambos juntos quedaban antes del estado de enrutamiento, la política de fuentes y el resultado de la aplicación.

Permanencia no significaba presencia

RFC 3307 separó más tarde tres objetos: direcciones multicast permanentes, identificadores permanentes de grupo y asignaciones dinámicas. IANA podía reservar una dirección completa; un identificador permanente podía nombrar el mismo servicio en varios servidores y ámbitos; una asignación dinámica servía a una necesidad temporal.

Las tres categorías administraban colisiones y significado. Ninguna creaba miembros. Para convertirse en servicio, el identificador aún debía combinarse con un ámbito, ser solicitado por una aplicación, unido en una interfaz y sostenido por el plano de reenvío.

RFC 3306 reforzó el contexto al incrustar prefijos unicast en ciertas direcciones multicast. El ámbito multicast no podía exceder el del prefijo, y su vida no debía prolongarse más allá de la validez de éste. Hasta un identificador reutilizable dependía de tiempo y autoridad de asignación.

El registro actual cuenta otra clase de historia

RFC 4291 conservó la arquitectura por ámbitos. RFC 7346 asignó posteriormente el valor 3 al ámbito local de dominio y precisó el vocabulario. El registro IANA actual mantiene tablas distintas para ámbitos, direcciones fijas, direcciones variables, identificadores basados en prefijos unicast e identificadores dinámicos.

Esa evolución prueba que el libro mayor sigue vivo. No prueba que una fila histórica tenga tráfico. Un nombre puede permanecer reservado después de desaparecer su implementación. Un servicio nuevo puede incorporarse décadas más tarde. El registro describe coordinación; el tráfico exige observación.

Una autoridad deliberadamente limitada

La especificación inicial mínima de Lu Heng explica el valor de RFC 2375: fijó lo suficiente para arrancar, reservó el resto y permitió correcciones. La primacía del código en funcionamiento sitúa el siguiente nivel de autoridad en las adhesiones, informes, rutas y paquetes realmente observados.

Las capas de realidad mantienen separado cada recibo: significado registrado, identificador, ámbito, dirección completa, membresía de interfaz, conocimiento del router, ruta multicast, fuente admitida, paquete recibido y resultado de aplicación.

El número podía conservar su significado a través de los ámbitos. Lo que nunca podía transportar consigo era la audiencia.