Кратко

  • RFC 3019 открыл состояние интерфейсов и cache MLD для управления, но ряд объектов был одновременно командами: включить или выключить MLD, создать или уничтожить строку, отметить локальное членство, изменить таймеры и выбрать proxy interface.
  • Поэтому строка, адрес последнего отправителя Report или успешный SET доказывали лишь состояние, представленное агентом, — не текущего удалённого слушателя, forwarding, доставку packet или приём приложением.

В таблице было написано: для этой multicast-группы на этом интерфейсе есть участники. Рядом стоял IPv6-адрес последнего отправителя Membership Report и время до истечения записи.

Для оператора это почти готовый ответ. Слушатель существует, сеть о нём знает.

Но RFC 3019 позволял менеджеру создать ту же строку без нового удалённого Report. Он мог удалить её, выставить локальное членство, выключить MLD или изменить таймеры.

Таблица не обманывала. Она просто описывала управляемое состояние агента, а не весь путь от намерения слушателя до полезных данных.

Одна строка соединяла прошлое, настоящее и политику

Документ определил две таблицы. MLD Interface Table содержала строку для каждого интерфейса с включённым MLD. MLD Cache Table — строку для каждой пары IPv6 multicast address и interface, для которой агент представлял membership state. Таблицы предназначались и для hosts, и для routers, хотя часть объектов относилась только к router.

В interface row были Query interval, maximum response delay, версия MLD, адрес Querier, накопленный счётчик joins, текущее число групп, Robustness Variable, last-listener interval, proxy interface и таймеры Querier.

Эти значения не были единым снимком. Счётчик описывал накопленную активность. Gauge — текущие строки. Expiry — условное будущее. Записываемый interval — policy.

Cache row объединяла mldCacheSelf, mldCacheLastReporter, uptime, expiry и mldCacheStatus. Близость колонок не делала их свидетельствами одного происхождения.

Последний отправитель Report мог уже уйти

mldCacheLastReporter означал ровно адрес источника последнего Membership Report, полученного для группы на интерфейсе. Если Report не приходил, значением был 0::0.

Объект не перечислял всех listeners и не подтверждал, что этот адрес продолжает слушать.

MLD из RFC 2710 отвечал на ограниченный вопрос: есть ли на подключённом link хотя бы один listener. Услышав Report другого host для той же группы, host мог подавить собственный ответ. Видимый адрес становился последним голосом, а не реестром участников.

Этот host мог выйти, пока другой сохранял членство. Запись мог поддерживать и локальный system. Значит, “last” описывало порядок наблюдений, а не актуальное присутствие.

mldCacheExpiryTime тоже не был liveness proof. Он показывал минимальное оставшееся время до ageing. Ноль мог означать, что entry сохраняется только благодаря mldCacheSelf и исчезнет сразу после локального leave. Реализация могла обрабатывать собственные Reports как чужие, поэтому ноль не был обязателен.

Для утверждения о remote listener нужны время Report, локальное состояние, timer epoch и непрерывность агента. Для утверждения о доставке дополнительно нужны forwarding и наблюдение receiver.

Менеджер мог записать факт, который потом прочитал

mldCacheStatus имел доступ read-create. Менеджер мог создать новую entry или удалить существующую. Описание базовой compliance group прямо называло целью создание и удаление MLD cache entries менеджером.

mldCacheSelf также был read-create, а его default был true.

Следовательно, строка могла появиться после remote Report, local join, management operation или сохраниться до timer expiry. Текущее значение не обязано было хранить эту цепочку причин.

Если automation создала строку для теста и затем выполнила GET, чтение подтвердило, что агент представляет запрошенное состояние. Оно не стало независимым подтверждением удалённого Report. Запись и проверка использовали одну поверхность.

Контроль полезен. Ошибка возникает, когда его origin теряют, а результат называют внешним наблюдением.

Уничтожение interface row выключало MLD

mldInterfaceStatus был операционным рычагом. Активация строки включала MLD на интерфейсе; уничтожение выключало.

Записываемые параметры меняли частоту Queries, maximum response time, устойчивость к потере packets и скорость проверки последнего участника. Меньший last-listener interval снижал leave latency, но менял окно, в котором новый Report мог сохранить состояние.

mldInterfaceProxyIfIndex связывал интерфейсы. Membership, выученное на одном, могло вызвать MLD Report на другом. Ноль означал отсутствие proxy; ненулевое значение делало локальную cache причиной upstream action.

Успешный SET мог менять протокольное поведение. Но ответ агента не доказывал отправку следующего Query, получение соседом, изменение forwarding или полезный приём приложением.

read-create не означал обязательную запись повсюду

Максимальный доступ в MIB не был переписью возможностей реальных agents.

Compliance statements для hosts и routers разрешали минимум read-only для mldInterfaceStatus. Write access не требовался. Определение schema, capability реализации, VACM view, authorization запроса и фактический effect были разными слоями.

RFC 2579 определял общий lifecycle RowStatus, но active оставался состоянием управления. Он не доказывал persistence после restart, синхронизацию с MLD engine или data-plane outcome.

Нужно отдельно установить: стандарт разрешил запись; агент реализовал её; principal получил право; запрос принят; результат наблюдается. Первая строка MIB отвечает только на первый пункт.

Чтение раскрывало информацию, запись могла вызвать отказ

Security Considerations RFC 3019 говорили, что readable objects могут раскрывать сведения о multicast sessions. mldCacheSelf и mldCacheLastReporter способны помочь определить machines, связанные с group address. Историческая оценка чтения как relatively innocuous не является универсальным privacy rule.

Unauthorized writes могли вызвать denial of service. SET в незащищённой среде угрожал network operations.

SNMPv1 сам по себе был назван такой средой. Даже IPsec не определял, кто внутри сети имеет право менять objects. Поэтому документ рекомендовал USM из RFC 2574 и VACM из RFC 2575.

Защищённый channel, identity principal, разрешённая view, принятый SET, protocol state, forwarding и receiver result — отдельные квитанции.

RFC 5519 добавил различия, но не переписал старые строки

В 2009 году RFC 5519 сделал RFC 3019 obsolete. Он объединил управление IGMP и MLD, разделил host и router tables и добавил source-filter state для IGMPv3 и MLDv2.

Преемник показал ограничения ранней модели. Нельзя читать его новые поля задним числом в row 2001 года. Стандарты также не доказывают deployment, vendor support или migration конкретной сети.

Работы Lu Heng используются как явно раскрытые аналитические линзы. Running-Code Primacy отделяет module от running agent. Reality Layers разделяет row, Report, policy, forwarding и receipt. Minimum Initial Specification помогает видеть ценность ранней узкой поверхности без приписывания ей будущих функций.

Lu Heng не был автором RFC 3019 и не одобрял его.

Строка могла быть точной. Просто её точность относилась к состоянию агента, а не ко всему миру multicast.

Sources