Resumen

  • RFC 1469 exigía que los sistemas multicast de un mismo anillo físico Token Ring acordaran un método de dirección de hardware; la elección era configurable por interfaz y los puentes podían traducirla.
  • La dirección funcional común resolvía una selección local bajo escasez. No probaba por sí misma que una trama fuera multicast IP ni que un host perteneciera al grupo, cuestiones que RFC 1112 mantiene separadas.

El grupo IP y la puerta local no eran la misma cosa

Una dirección multicast IP identifica un grupo de hosts, pero no le dice directamente a una tarjeta de red qué trama debe entregar. Según RFC 1112, el grupo es dinámico: los hosts entran y salen, y un host puede enviar a un grupo sin ser miembro. La membresía se mantiene por interfaz. Ese estado de la capa IP necesita una forma de materializarse en la red local, pero no se agota en ella.

RFC 1469 se ocupa de esa materialización para Token Ring. Ofrecía tres maneras de representar el destino multicast IP en una dirección MAC: la difusión a todos los anillos, una dirección funcional Token Ring asignada o las direcciones de grupo multicast IP ya asignadas por IEEE. El centro del documento es una disciplina de coordinación: todos los sistemas que soportan multicast IP en un anillo físico deben utilizar la misma dirección de hardware. Por ello el método debe poder configurarse en una interfaz. Un puente puede traducir entre métodos para los anillos que une.

La dirección seleccionada, entonces, es una convención local para recibir. No es una escritura de propiedad sobre el grupo ni un identificador que obligue a todos los medios a hablar igual. Un anillo podía usar una representación y otro una distinta; el puente mantenía el sentido del tráfico al cruzar el límite. La coordinación estaba en el método compartido de cada anillo, no en una verdad universal inscrita en seis octetos.

Una escasez física dejó una señal común

Las direcciones funcionales Token Ring se reservaban para funciones muy utilizadas, como supervisión del anillo, NetBIOS o puentes. RFC 1469 señala que solo existían 31. Varias funciones no relacionadas debían compartir alguna.

Por esa razón, el método funcional no asignó una dirección distinta a cada grupo multicast IP. Asignó todos los grupos a 03-00-00-20-00-00 en formato canónico, o a C0-00-00-04-00-00 en el formato no canónico habitual para interfaces Token Ring. Era una reducción útil: una señal física permitía a los adaptadores saber que la trama merecía atención. Pero ya no había correspondencia exclusiva entre la dirección MAC y un grupo IP.

La RFC extrae la consecuencia correcta: una trama enviada a esa dirección funcional no es necesariamente una trama multicast IP. Puede haber otro protocolo asignado a la misma dirección. El destino MAC inicia una decisión de recepción; no certifica el contenido de la capa superior. Para conocer el protocolo sigue haciendo falta interpretar el paquete.

El filtro recibía; la membresía se mantenía en otro lugar

RFC 1112 distingue con precisión esas dos tareas. El módulo IP mantiene las membresías y utiliza IGMP para informar su presencia a routers multicast inmediatamente vecinos. El módulo de red local convierte direcciones de grupo IP en direcciones locales para actualizar su filtro de recepción.

No hay equivalencia garantizada entre ambos registros. El módulo local puede ignorar una salida de grupo o entregar paquetes para más direcciones de las solicitadas si su filtro no es suficientemente fino. Por eso, que una interfaz vea una trama no demuestra una membresía correspondiente. Tampoco el envío a un grupo demuestra que el emisor sea miembro. Dirección IP, filtro MAC, estado de membresía y reporte IGMP son piezas conectadas, no pruebas intercambiables.

RFC 1469 recomendaba el método IEEE cuando el controlador podía utilizarlo. Si no podía, prefería la dirección funcional antes que la difusión a todos los anillos. También obligaba a conservar compatibilidad hacia los métodos menos capaces. La historia no es que todos los grupos fueran uno solo; es que un acuerdo de recepción podía preservar interoperabilidad entre capacidades de hardware desiguales.

De ahí la frontera editorial. La dirección funcional compartida no identifica una persona, una máquina concreta ni el número de oyentes. No prueba que la trama contenga multicast IP, ni que un router la haya llevado fuera del anillo, ni que alguien remoto la haya recibido. Describe una regla local de selección. La utilidad de RFC 1469 está en haber hecho visible esa regla sin prometerle una semántica que no poseía.

Fuentes