Кратко

  • Канал Source-Specific Multicast задаётся парой адреса источника и группы (S,G).
  • Два частных отправителя могут выбрать одну группу и оставаться различимыми благодаря разным частным адресам источника.
  • При передаче наружу RFC 5135 требует заменить частный адрес источника внешним адресом NAT.
  • Если оба отправителя получают одно публичное представление, разные частные пары могут превратиться в одну публичную пару.
  • RFC прямо предупреждает: такой трафик перестаёт быть однозначно идентифицируемым и способен смешиваться у получателя.
  • Агрегация IGMPv3 предотвращает некорректное чередование изменений состояния разных внутренних участников.
  • Она доказывает согласованность control plane, но не восстанавливает различие источников, исчезнувшее в data plane.
  • Endpoint-Independent Mapping делает преобразование независимым от назначения, а не уникальным для каждого частного отправителя.
  • Ограничения области, TTL и отключение внешней передачи решают вопросы маршрута, а не частной принадлежности разрешённого пакета.
  • Общего решения RFC не даёт; временно приложению советуют позволить пользователю изменить SSM-группу.
  • Новая группа имеет значение только после доказанной доставки сигнализации, смены фильтров и перехода всех нужных получателей.
  • Полная квитанция связывает внутренний источник, преобразование, публичное объявление, выбор получателя и фактический результат.

Зачем прокси обязан агрегировать

У каждого частного хоста есть собственная машина состояния IGMP. Хост вступает в группы, покидает их и меняет фильтр источников независимо от соседей. Внешняя сеть, однако, видит прокси как одного репортёра. Если просто отправлять вверх сообщения всех хостов по мере прихода, полученная последовательность может не соответствовать ни одному допустимому состоянию этого единственного репортёра.

Особенно наглядна одновременная смена: один хост вступает, другой выходит. Наивное чередование state-change reports может временно убрать нужное членство и вызвать blackholing. RFC 5135 требует проксирование и агрегирование, чтобы сначала вычислить совместный downstream-смысл, а потом представить его upstream.

Такой прокси выполняет настоящую координационную работу. Его таблица способна доказать, какие группы и source filters он намеревался представлять. Но она не является копией происхождения каждого пакета. После переписывания адреса данных внешний фильтр может работать только с адресом, который виден снаружи.

Именно поэтому хороший IGMPv3-лог не закрывает расследование смешанного контента. Он исключает одну причину — неверную агрегацию членства. Он не исключает другую — слияние нескольких частных источников в одной публичной паре.

Две внутренние пары становятся одной внешней

Пусть источники A и B отправляют в группу G. Внутри существуют (A,G) и (B,G). Одинаковая группа допустима, поскольку SSM использует полную пару. Узел, который видит частные адреса, может запросить только A или только B.

При выходе NAT переписывает адрес источника. Если оба адреса представлены внешним N, а группа G сохраняется, получатель видит (N,G) в обоих случаях. Частный признак, на котором держался выбор, исчезает из публичного IP-ключа.

Appendix A RFC 5135 называет результат прямо: трафик больше нельзя уникально идентифицировать, и он может перемешиваться. Это не утверждение о каждом продукте и не статистика современных инцидентов. Это граница доказательства при конкретных условиях — одна группа, разные частные источники, один внешний источник.

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

Узкий договор NAT

RFC 5135 опубликован в феврале 2008 года как BCP 135. Он рассматривает IPv4 NAT/NAPT с IGMP-прокси для ASM и SSM. PIM-SM и IPv6 находятся вне рамок. Поэтому соответствие документу нельзя превращать в общую гарантию для всех multicast-механизмов.

Для движения снаружи внутрь адрес multicast-назначения и порт назначения не переводятся. UDP должен быть доставлен подписанным внутренним получателям; поддержку иных протоколов документ также рекомендует. Для движения изнутри наружу переписывается source IP; NAPT может изменить source port и создаёт mapping, если ожидаются ответы.

Endpoint-Independent Mapping означает, что отображение внутреннего endpoint не меняется в зависимости от unicast- или multicast-назначения. При нескольких публичных адресах paired address pooling рекомендует сохранять одну внешнюю адресу для одного endpoint. Это предсказуемость преобразования, но не обещание отдельной публичной личности каждому частному отправителю.

Исходящий UDP multicast должен поддерживаться вместе с возможностью его отключить. Отключение важно для multihomed-топологии, где один поток может выйти через несколько переводчиков и продублироваться. Дублирование одного потока и слияние двух источников — разные изменения кардинальности и требуют разных метрик.

Область действия не отвечает за происхождение

По умолчанию административный диапазон 239.0.0.0/8 не должен передаваться наружу, а Local Network Control Block 224.0.0.0/24 не должен пересекать внешнюю границу. TTL, равный единице, способен остановить поток на локальном маршрутизаторе.

Эти ограничения отвечают, куда пакет имеет право идти. Они не говорят, какой частный источник стоит за разрешённым публичным адресом. Успешное прохождение scope gate не является проверкой идентичности, а срабатывание gate не объясняет автоматически проблему другого получателя.

Стабильный mapping не равен уникальному источнику

Два частных endpoint могут каждый иметь устойчивое отображение и всё же использовать одну внешнюю адресу N. Таблица NAT подтвердит создание, порт, время жизни и переиспользование. Она не покажет потери различия, если её не сопоставить с одновременными внутренними источниками и выбранными ими группами.

Для ASM с RTP RFC 5135 отдельно обсуждает срок mapping. Истечение и новое отображение способны изменить translated transport address и запустить RTP collision detection. Рекомендуются 60 минут и удаление после выхода из группы; при нехватке ресурсов срок можно уменьшать, не опускаясь ниже минимума RFC 4787.

Таймер является квитанцией непрерывности состояния NAT. Он не доказывает, что приложение получателя видело одного и того же логического участника. В случае SSM стабильный N может даже стабильно сохранять неоднозначность между A и B.

Временный выход через смену группы

RFC 5135 оставляет общее решение будущему исследованию. В качестве временной меры SSM-приложению следует разрешить пользователю менять адрес группы. Если A использует G1, а B — G2, то общая внешняя источник N образует разные пары (N,G1) и (N,G2).

Но наличие настройки не означает завершённого перехода. Нужно обнаружить коллизию, выбрать допустимую группу, обновить session description, доставить её, перестроить фильтры и полномочия, перевести каждого получателя и прекратить старый канал. Кэш или автономный клиент может продолжать запрашивать старое (N,G).

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

Прикладная идентичность — ещё один проверяемый слой

RTP предлагает SSRC и CNAME. RFC 5135 рекомендует корректно создавать CNAME, поскольку разные NAT повторно используют одни и те же пространства RFC 1918. Прикладной идентификатор может различить участников, которых IP-адрес снаружи уже не различает.

Но его нужно сгенерировать, передать, проверить, обработать по правилам коллизии и связать с ожидаемым участником. SSRC collision — не то же самое, что слияние SSM (S,G). Наличие одного механизма не служит доказательством исправления другого.

Аудит начинается внутри: операционная идентичность отправителя, частная адреса, группа, поколение настройки, период и наблюдавшаяся пара. На границе сохраняются mapping, внешний адрес, порт, pooling и срок. IGMP-версия, downstream-члены, фильтры и upstream-агрегат остаются отдельными связанными записями.

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

Источники

  1. RFC 5135, HTML
  2. RFC 5135, текст
  3. Запись RFC Editor
  4. Запись IETF Datatracker
  5. История документа
  6. Поиск errata
  7. RFC 4787
  8. RFC 4605
  9. RFC 3376
  10. RFC 4607
  11. RFC 5760
  12. RFC 3550
  13. RFC 2365
  14. RFC 5771
  15. RFC 1918
  16. RFC 8085
  17. Реестр multicast-адресов IANA
  18. Реестр IANA в XML
  19. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  20. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile
  21. Running-Code Primary