Summary

  • RFC 2375 разрешал использовать одно постоянное значение службы в нескольких областях IPv6, но адреса, различавшиеся только областью, считал разными группами, к которым узел должен был присоединяться отдельно.
  • Назначение доказывало согласование имени и защиту от коллизии, а не наличие слушателя, состояние пересылки, допуск источника или получение пакета приложением.

Первая таблица оставляла место будущему

К 1998 году у IPv6 уже был формат multicast-адреса. Реализациям всё равно требовался общий словарь: адреса всех узлов и всех маршрутизаторов, протоколов маршрутизации, службы времени, конференционных и экспериментальных систем, знакомых по IPv4.

RFC 2375 опубликовал начальную выборку. Авторы перенесли только те назначения IPv4, которые считали применимыми, не конвертировали остальные, запросили замечания и зарезервировали все неуказанные адреса. Это было управляемое открытие пространства имён, а не обещание окончательной классификации.

Общая таблица не позволяла двум протоколам придать одному числу разные значения. Но строка таблицы не сообщала, что названная служба развёрнута или кто-то её слушает.

X не означал «одна группа повсюду»

Адреса с фиксированной областью действовали только в указанной границе. В адресах с переменной областью поле помечалось X: один постоянный номер можно было сочетать с любой допустимой областью.

RFC 2375 сразу ограничивал такую переносимость. Адреса, отличающиеся только областью, представляли разные группы. Узел должен был присоединиться к каждой из них отдельно.

В примере NTP из RFC 2373 один ID мог означать серверы времени на том же узле, канале, сайте или в глобальной области. Значение службы сохранялось, а полный адрес и множество получателей — нет. Номер пересекал границу; членство её не пересекало.

Область формировала адресата

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

Для временных групп разделение было ещё сильнее. Одинаковый временный адрес на другом сайте не имел обязательной связи с первым. То же относилось к совпадающему ID в другой области и к постоянной группе с тем же номером.

Сходство битов не доказывало операционную идентичность. Нужны были полный адрес, область и текущее состояние системы.

В реестре не было слушателей

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

RFC 2710 сделал следующий слой явным с помощью Multicast Listener Discovery. Маршрутизаторы узнавали, какие адреса интересуют узлы на непосредственно подключённых каналах. Хосты хранили состояние по адресу и интерфейсу, отвечали на запросы и сообщали об изменениях членства.

Запись IANA и отчёт слушателя были разными доказательствами. Первая стабилизировала смысл; второй показывал интерес в конкретном месте и времени. После них ещё оставались multicast-маршрут, политика источников, приход пакета и результат приложения.

Постоянство относилось к разным объектам

RFC 3307 впоследствии разделил постоянные multicast-адреса, постоянные групповые ID и динамические адреса. IANA мог зарезервировать полный адрес. Постоянный ID мог обозначать одну службу на нескольких серверах и в нескольких областях. Динамическое назначение обслуживало временную потребность.

Эти классы управляли коллизиями и значением, но не создавали участников. Для работающей службы требовалось выбрать область, сформировать полный адрес, запросить приём, присоединить интерфейс и построить состояние пересылки.

RFC 3306 связал часть multicast-адресов с unicast-префиксами. Область multicast не могла быть шире области встроенного префикса, а срок жизни адреса не должен был переживать срок его действия. Повторно используемая идентичность оставалась привязанной к месту и времени.

Живой реестр не является телеметрией

RFC 4291 сохранил модель групп по областям. RFC 7346 позже определил значение 3 как Realm-Local и уточнил названия. Нынешний реестр IANA по-прежнему разделяет области, адреса с фиксированной и переменной областью, ID на базе unicast-префикса и динамические ID.

Эта эволюция доказывает продолжение координации, но не современный трафик для каждой строки 1998 года. Имя может оставаться зарезервированным после исчезновения реализации, а новая служба может получить назначение десятилетия спустя.

Реестр показывает, что можно назвать без коллизии. Только работающая сеть показывает, кто действительно слушает.

Сила была в ограниченной власти

Идея Lu Heng о минимальной начальной спецификации точно описывает RFC 2375: открыть ровно необходимую часть общего пространства, остальное сохранить и допустить исправление опытом. Приоритет работающего кода переносит следующий уровень авторитета в события join, отчёты, таблицы пересылки и наблюдаемые пакеты.

Слои реальности нельзя сливать: значение службы, ID, область, полный адрес, членство интерфейса, известное маршрутизатору состояние, маршрут, разрешённый источник, полученный пакет и результат приложения — разные квитанции.

RFC 2375 дал ранним группам имена. Он не обещал, что устойчивое имя приведёт с собой слушателей.