Кратко

  • Multicast Receiver RLOC допустим лишь при поддержке IP multicast в underlay ядра LISP; выбор группы, к которой ETR способен присоединиться, RFC 9798 оставляет локальному решению ETR.
  • Корневой ITR выделяет запись outgoing-interface-list для каждого уникального underlay-отображения. Для учёта ETR, приславших joins, используется IP-источник Join/Prune, который обязан быть адресом ETR RLOC.
  • Аутентификация может подтвердить происхождение и целостность запроса, но не право на группу, возможности пути, наличие участников или доставку.

Адрес назначения не отвечает на вопрос об отправителе

При Transport=0 multicast Receiver RLOC обозначает группу, на которой ETR хочет получить инкапсулированный поток. В значении нет перечня ETR и тем более конечных узлов. Если ITR необходимо отслеживать ETR, от которых пришли PIM joins, RFC 9798 требует использовать исходный IP сообщения; этот адрес должен быть ETR RLOC.

Группа и источник находятся рядом, но обладают разной доказательной силой. Первая выражает запрошенную поверхность доставки. Второй указывает заявителя при корректной обработке и, возможно, проверке сообщения. Ни тот ни другой не сообщает, что пакет дошёл до приложения.

RFC 9798 опубликован в июне 2025 года как Experimental и обновляет RFC 8059. Синтаксис и семантика Transport Attribute не меняются, обновление действует только для значения multicast. Unicast-адрес Receiver RLOC используется для unicast-инкапсуляции, multicast-адрес — для multicast-инкапсуляции, причём последний разрешён только при поддержке multicast транспортом underlay ядра LISP.

Такое требование не создаёт удалённой аттестации. ETR, решивший применить multicast underlay, выбирает группу, к которой может присоединиться, определяет восходящий LISP-сайт для корня дерева и формирует Join/Prune по RFC 8059. Выбор группы прямо назван локальным решением вне области RFC. Его основание нужно искать в тесте возможностей, конфигурации, политике диапазонов и их версии.

Кардинальность переносит цену между состоянием и копиями

RFC 6831 разводит (S-EID,G) внутри сайтов и (S-RLOC,G) в ядре. ITR инкапсулирует трафик, multicast-дерево underlay выполняет разветвление, а принимающий ETR декапсулирует и сверяет внутреннее состояние.

RFC 9798 допускает три отношения: многие overlay-потоки в одном underlay-потоке; один overlay-поток в нескольких underlay-потоках; и уникальное соответствие. Many-to-one экономит деревья ядра, но RFC 6831 показывает побочный эффект: сайт может получить инкапсулированный трафик источника, на который не подписывался, и отбросить его лишь после декапсуляции. One-to-many разделяет ограничения разных xTR ценой дополнительных копий у корня. One-to-one усиливает изоляцию ценой состояния.

Ответственность корневого ITR измерима: новое состояние в списке выходных интерфейсов создаётся для каждого уникального multicast-отображения underlay. ITR может локально ограничивать количество копий. Универсальной квоты RFC не задаёт. Для анализа нужны ключ отображения, OIF, запрошенное и разрешённое число копий и причина ограничения.

Разные диапазоны могут требоваться на границе PxTR между интерфейсами сайта и внешним LISP core. Возможности аппаратуры могут ещё сильнее сузить допустимые multicast-адреса. Пригодность группы определяется границей, платформой и эпохой политики, а не самим числом адреса.

Принятый атрибут не является согласованием возможностей

RFC 5384 задаёт оболочку PIM Join Attribute. Атрибуты, влияющие на построение дерева, полезны в сотрудничающем домене, где заранее известно, что маршрутизаторы понимают кодирование и конкретный тип. Обычный PIM применяет Hello option, чтобы не отправлять специальное кодирование несовместимому соседу.

Для LISP RFC 8059 фиксирует иной стык: xTR не обмениваются PIM Hello, согласование этих атрибутов отсутствует, а поддержка предполагается у систем с unicast head-end replication. Transport и Receiver RLOC нетранзитивны. RFC 9798 расширяет применение на multicast underlay, не вводя общего discovery или глобального распределителя групп.

Отсюда следует многоуровневый журнал. Успешный parse относится к представлению. Загруженная политика диапазона — к намерению. OIF — к управляющему состоянию. Таблица и счётчики — к работающему forwarding. След на стороне получателя — к результату. Спецификация связывает части цепочки, но не позволяет подменять одну другой.

Аутентифицированный запрос остаётся запросом

RFC 8059 говорит, что безопасность атрибута определяется безопасностью PIM-пакета. RFC 9798 рассматривает множество joins с разными или пересекающимися группами как источник помех и исчерпания ресурсов репликации. В документе сказано, что механизмы RFC 5796 могли бы проверять запросы; также возможны учёт и лимиты групп для каждого исходного ETR RLOC.

RFC 5796 описывает IPsec-защиту link-local сообщений PIM-SM, security associations, ключи и аутентификацию соседей. При правильной эксплуатации это подтверждает источник и целостность в рамках указанной SA. Но не доказывает выделение группы, multicast-возможности всего пути, наличие членов или доставку данных.

Полный receipt связывает сырые Join/Prune, разобранные атрибуты, результат аутентификации и SA, исходный ETR RLOC, локальное решение ETR, корень, кардинальность, OIF, rate-limit, состояние ядра, счётчики, декапсуляцию, внутренний forwarding и результат приложения. Для каждого перехода нужны время и correlation ID.

Источники