Кратко

  • RFC 1469 требовала, чтобы multicast-системы в одном физическом кольце Token Ring выбрали один метод аппаратного адреса; метод настраивался для интерфейса, а мост мог переводить между методами.
  • Общий функциональный адрес был локальным способом отбора при дефиците. Сам по себе он не доказывал ни IP multicast в кадре, ни членство хоста в группе — эти состояния RFC 1112 разделяет.

Имя IP-группы не было приказом сетевой карте

IP multicast-адрес обозначает группу хостов, но сам по себе не говорит локальному адаптеру, какие кадры передавать вверх. В RFC 1112 группа динамична: хосты входят и выходят, а хост может послать датаграмму группе, не являясь её членом. Членство ведётся по интерфейсам. Это факт IP-слоя, который нужно представить в локальной сети, но который не превращается в неизменный смысл MAC-адреса.

RFC 1469 описала это представление для Token Ring. Были три варианта: адрес широковещания всех колец, назначенный функциональный адрес Token Ring или уже назначенные IEEE групповые IP multicast-адреса. Главное правило документа — координационное: все системы, поддерживающие IP multicast на одном физическом кольце, должны согласовать одинаковый аппаратный адрес. Поэтому метод должен настраиваться на интерфейсе. Мост может переводить методы на соединяемых им кольцах.

Выбранный адрес, следовательно, является локальной договорённостью о приёме, а не правом собственности на группу и не универсальной материальной идентичностью. Одно кольцо могло использовать одно представление, другое — другое; мост сохранял связь через границу. Унифицировалось правило приёма внутри кольца, а не утверждение, что шесть октетов содержат всю правду о состоянии IP-группы.

Дефицит поместил несколько значений в один сигнал

Функциональные адреса Token Ring предназначались для распространённых функций — мониторинга кольца, NetBIOS, мостов и LAN Manager. RFC 1469 указывает, что таких адресов было только 31. Поэтому несвязанные функции могли пользоваться одним адресом.

В функциональном методе все IP multicast-адреса отображались на 03-00-00-20-00-00 в канонической форме либо на C0-00-00-04-00-00 в неканонической форме, привычной для интерфейсов Token Ring. Такое сжатие было полезно: ограниченный адаптер получал сигнал, что кадр надо проверить дальше. Но оно не создавало исключительного соответствия между MAC-адресом и IP-группой.

Сама RFC устанавливает необходимое отрицательное правило: кадр на этот функциональный адрес не становится только поэтому кадром IP multicast. Тот же адрес может быть назначен другому протоколу. MAC-назначение открывает проверку приёма; оно не выдаёт сертификат о протоколе полезной нагрузки. Интерпретация верхнего уровня остаётся необходимой.

Фильтр принимал, а членство жило в другой книге

RFC 1112 разводит эти задачи. Модуль IP хранит членства групп по интерфейсам и с помощью IGMP сообщает о них непосредственно соседним multicast-маршрутизаторам. Модуль локальной сети имеет более узкую функцию: отобразить IP-групповой адрес на локальный и обновить фильтр приёма.

Эти записи не обязаны совпадать. Если аппаратная фильтрация недостаточно точна, локальный модуль может проигнорировать запрос выхода или передать вверх пакеты для большего числа адресов, чем было запрошено. Поэтому наблюдение кадра на интерфейсе не доказывает соответствующую запись о членстве. И отправка в группу не доказывает членство отправителя. IP-назначение, MAC-фильтр, состояние членства и IGMP-отчёт связаны, но не являются взаимозаменяемыми доказательствами.

RFC 1469 рекомендовала IEEE-метод, если его поддерживал контроллер. Если нет, функциональный адрес предпочитался широковещанию всех колец. Правила совместимости сохраняли и менее мощные методы. История здесь не о слиянии всех групп в одну, а о сохранении общего правила приёма между неравными аппаратными возможностями.

Из общего функционального адреса нельзя вывести человека, конкретную машину или число слушателей. Он не доказывает, что полезная нагрузка была IP multicast, что маршрутизатор переслал её за кольцо, что удалённый получатель её принял или приложение вызвало эффект. Он описывает локальный выбор приёма. Именно это ограничение делает исторический договор RFC понятным и проверяемым.

Источники