Resumen

  • La MIB de RFC 3019 mostraba interfaces y cachés de MLD, pero varios objetos eran escribibles: administración podía habilitar el protocolo, crear o destruir una entrada, marcar la pertenencia local, ajustar plazos o configurar un proxy.
  • La fila devuelta demostraba el estado que representaba el agente. No demostraba por sí sola un oyente remoto actual, una intención autenticada, reenvío multicast, entrega de paquetes ni recepción por una aplicación.

En una pantalla de operaciones, una fila verde suele parecer una confirmación. El grupo está ahí. La interfaz está ahí. Hay una dirección bajo “último informante”. Queda tiempo antes de la caducidad.

Pero RFC 3019 había dejado una puerta lateral: el gestor podía escribir parte de esa realidad.

Podía crear o borrar la entrada de caché. Podía indicar que la máquina local pertenecía al grupo. Podía activar o desactivar MLD en la interfaz. Podía modificar intervalos, tolerancia a pérdidas y la interfaz usada como proxy.

La fila no era falsa por ese motivo. Respondía una pregunta concreta: ¿qué estado representa ahora este agente y qué parte deja administrar? El error aparecía al convertir esa respuesta en una afirmación sobre un host remoto o sobre el camino de datos.

Dos tablas reunían tiempos y autoridades distintos

RFC 3019 definió una tabla de interfaces MLD y una tabla de caché. La primera tenía una fila por interfaz con MLD habilitado. La segunda tenía una fila por dirección multicast IPv6 e interfaz para la que el agente conservaba estado de pertenencia.

La tabla de interfaz incluía el intervalo de consultas, el máximo tiempo de respuesta, la versión de MLD, la dirección del Querier, el número acumulado de altas, el número actual de grupos, la variable de robustez, el intervalo de consulta al último oyente, la interfaz proxy y los relojes del Querier.

No eran mediciones equivalentes. El contador de altas resumía el pasado. El gauge de grupos retrataba el presente del agente. El tiempo de expiración del Querier anticipaba una transición si no llegaba nueva evidencia. Una configuración escribible expresaba política.

La caché contenía mldCacheSelf, mldCacheLastReporter, la antigüedad de la fila, el tiempo restante y mldCacheStatus. Un panel podía mostrarlo todo junto; una investigación debía separar cada procedencia.

La última dirección no era la lista de oyentes

mldCacheLastReporter tenía una definición mínima: la dirección IPv6 de origen del último Membership Report recibido para ese grupo en esa interfaz. Si no se había recibido ninguno, debía valer 0::0.

No decía que esa dirección siguiera escuchando. Tampoco decía que fuese el único miembro o que representara a una aplicación concreta.

MLD, en RFC 2710, buscaba saber si existía al menos un oyente en el enlace. Los hosts podían suprimir informes redundantes tras oír la respuesta de otro. Una única dirección podía quedar como último informante mientras varias máquinas mantenían la pertenencia. Esa máquina podía marcharse y la fila seguir viva por otro miembro o por el sistema local.

El tiempo de caducidad era igualmente estrecho. mldCacheExpiryTime daba el mínimo tiempo antes de que la entrada envejeciera. Cero podía indicar que solo mldCacheSelf la mantenía y que desaparecería si el router abandonaba el grupo. Incluso esa representación no era obligatoria si la implementación trataba sus informes locales como los de otros hosts.

Por eso, “último” era una propiedad del historial de observación, no una credencial actual. Para afirmar presencia hacían falta informe, fecha, pertenencia local, época de temporizadores y continuidad del agente. Para afirmar entrega hacían falta además forwarding y medición del receptor.

La administración podía producir el dato consultado

mldCacheStatus llevaba MAX-ACCESS read-create. Permitía crear una entrada nueva o borrar una existente. El grupo básico de conformidad decía expresamente que estaba diseñado para la creación y eliminación de entradas MLD por el gestor.

mldCacheSelf también era read-create y su valor predeterminado era verdadero. Una fila podía existir porque un Report llegó por el enlace, porque la máquina administrada se unió, porque un gestor la instaló o porque un temporizador aún no la había retirado.

La fila presente no guardaba necesariamente esa genealogía.

Pensemos en una automatización que crea una pertenencia local para una prueba y luego lee la caché. La lectura confirma que el agente conserva lo solicitado. No confirma de manera independiente que un oyente remoto haya emitido un Report. Escritura y verificación han usado el mismo registro.

El problema no es que la MIB permita control. Sin control, muchas operaciones serían imposibles. El problema es ocultar el origen y después citar la proyección como testigo exterior.

El control alcanzaba el comportamiento del protocolo

mldInterfaceStatus era algo más que un indicador. Activar la fila habilitaba MLD; destruirla lo deshabilitaba.

Los intervalos escribibles podían cambiar la frecuencia de las Queries, la ventana máxima de respuesta, la robustez frente a pérdidas y la rapidez con que se verificaba la salida del último miembro. Reducir el último intervalo acortaba la latencia de salida, pero también alteraba el plazo durante el cual una respuesta podía conservar el estado.

mldInterfaceProxyIfIndex permitía que pertenencias aprendidas en una interfaz provocasen Reports en otra. Cero significaba que no había proxy. Un valor distinto de cero conectaba una observación local con una acción ascendente.

Un SET aceptado podía así cambiar descubrimiento, expiración y señalización. La respuesta SNMP, sin embargo, solo era prueba de la interacción con el agente. No demostraba que la próxima Query saliera, que un vecino la recibiera, que la tabla de reenvío cambiara o que una aplicación obtuviera datos útiles.

La etiqueta read-create no era un censo de capacidades

La MIB definía varios objetos con permiso de creación. Eso no significaba que todo agente conforme tuviera que ofrecer escritura.

Las declaraciones para hosts y routers permitían que mldInterfaceStatus tuviera acceso mínimo de solo lectura. El esquema describía el acceso máximo y los grupos de conformidad. Una implementación podía exponer menos escritura sin dejar de cumplir la modalidad correspondiente.

Conviene separar cuatro hechos: el objeto fue diseñado como escribible; el agente implementó esa variante; la vista de acceso autorizó al principal; la operación cambió realmente el estado. El primer hecho vive en el RFC. Los otros necesitan evidencias de ejecución.

RFC 2579 explicaba la convención genérica RowStatus, pero un estado active no se convertía por ello en comprobación del plano de datos. Tampoco probaba persistencia tras reinicio ni sincronización correcta con el motor MLD.

La seguridad distinguía revelación y denegación de servicio

RFC 3019 advertía que los objetos legibles podían revelar información sobre sesiones multicast. mldCacheSelf y mldCacheLastReporter podían ayudar a identificar máquinas asociadas a un grupo. El texto consideraba relativamente inocuo el acceso de lectura no autorizado, una valoración histórica que no debe extrapolarse a cualquier grupo o contexto.

Las escrituras no autorizadas podían causar denegación de servicio. El documento calificaba a SNMPv1 por sí solo como entorno inseguro para estas operaciones. Proteger la red, incluso con IPsec, no resolvía quién tenía permiso para acceder o modificar cada objeto.

Por eso recomendaba el modelo de usuario de RFC 2574 y las vistas de RFC 2575. La secuencia importa: protección del canal, identidad del principal, autorización sobre la vista, aceptación del SET y resultado observado son pruebas diferentes.

Un usuario autenticado no obtiene todos los objetos. Una operación permitida no garantiza entrega multicast. Una fila restaurada después de un error no recupera los paquetes que ya se replicaron o se perdieron.

RFC 5519 amplió el modelo sin reescribir 2001

En 2009, RFC 5519 dejó obsoleto RFC 3019. Unificó la gestión de IGMP y MLD, separó tablas de host y router e incorporó listas de fuentes para IGMPv3 y MLDv2.

Ese cambio mostró las limitaciones expresivas de la MIB anterior. No autoriza a leer en una fila de 2001 datos que aún no estaban allí. Tampoco demuestra despliegue, compatibilidad de producto o migración real.

Los documentos prueban un linaje de diseño. No prueban que una red determinada lo ejecutara.

Las ideas de Lu Heng se usan como lentes declaradas. Running-Code Primacy separa módulo y agente. Reality Layers separa fila, Report, política, reenvío y recepción. Minimum Initial Specification permite valorar una primera superficie pequeña sin atribuirle las distinciones posteriores.

Lu Heng no escribió ni respaldó RFC 3019.

La buena pregunta no era “¿existe la fila?”. Era “¿quién pudo producirla y qué decisión puede sostener sin pedir prestada evidencia de otra capa?”.

Sources