Кратко

  • RFC 3956 кодировала длину префикса, unicast-префикс и короткий идентификатор, чтобы маршрутизаторы PIM-SM выводили один Rendezvous Point.
  • Адрес мог предоставить любой пользователь, поэтому правильный вывод не доказывал существование RP, маршрут, полномочия, состояние источника или доставку получателю.

Адрес назначения стал частью конфигурации

Приложение узнаёт multicast-группу из настройки, каталога или страницы. RFC 3956 дала некоторым IPv6-группам вторую функцию: содержать материал для вычисления RP протокола PIM Sparse Mode.

Механизм отвечал на отсутствие IPv6-аналога MSDP для междоменного ASM и на неполную готовность SSM заменить все сценарии. Детерминированная функция устраняла отдельное распространение group-to-RP.

Конфигурация не исчезла. Её источник переместился в адрес, полученный извне.

Полный RP не помещался рядом с группой

В 128 бит нельзя уложить вторые 128 бит и оставить Group ID. Формат опирался на RFC 3306: флаг отмечал embedded-RP, plen и сетевой префикс задавали основу, четырёхбитный RIID дополнял адрес при заданных ограничениях.

Нулевой RIID был зарезервирован. Несколько ненулевых значений могли выбирать разные RP под одним префиксом, однако полный групповой адрес давал одного кандидата. Уникальность Group ID оставалась внешней задачей. Совпавшее вычисление не означало согласованное выделение группы.

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

Недоверенный ввод создавал состояние в маршрутизаторах

Получатель посылал MLD, после чего designated router начинал Join к вычисленному RP. Маршрутизатор источника мог направлять туда первые Register. Пользовательский адрес таким образом управлял направлением контрольного трафика.

RFC прямо называет источник недоверенным: любую группу может предложить любой пользователь Интернета. Требовались проверки не слабее применяемых к RP из других источников, включая исключение fe80::/10, ::/16 и ff00::/8.

Успешная проверка делала адрес допустимым кандидатом. Она не аутентифицировала создателя группы, владельца префикса или источник и не разрешала отправку или приём. Синтаксис стал входом маршрутизации, не удостоверением.

Документ не обещал даже существование

PIM-SM ожидает доменно доступный RP. RFC 3956 отмечает, что доступность в общем случае недоказуема, а иностранный встроенный RP может вообще не существовать.

Маршрут доказывает запись следующего перехода, не PIM-процесс. Join доказывает промежуточное состояние, не источник и не данные. Кэш доказывает прошлое вычисление, не текущую работоспособность. Принятый Register также не подтверждает, что дерево довело поток до получателя.

RP в адресе становится заметнее как единая точка отказа. Заметность помогает диагностике и атаке, но не служит health check. Скрытие объявлений было obscurity, а не доступом; embedded-RP тоже нуждался в scoping и политике границы.

Протоколы не делили один итоговый вердикт

RFC 4601 позже детализировала Join, Register и shared tree PIM-SM, а RFC 3810 определила MLDv2. Локальное членство, PIM-состояние и полученный пакет — разные записи.

RFC 4607 задала SSM, где источник и группа обходятся без RP. RFC 3956 считала его важной альтернативой, а не мгновенной универсальной заменой. Более точное имя пути также не доказывает его работу.

RFC 7371 впоследствии обновила архитектуру IPv6 multicast. Карточка и errata описывают документ, не внедрение в конкретной сети.

Embedded-RP делал кандидата воспроизводимым и уменьшал конфигурационные расхождения. Но адрес лишь называл направление попытки. Маршрут, PIM, состояние источника, счётчики и наблюдение получателя должны были подтвердить продолжение.

Источники