Кратко

  • RFC 10028 заменяет общий динамический диапазон RFC 3307 отдельными блоками для MADCAP, назначения SSM хостом, Private Use, Experimental Use и Solicited-Node.
  • Разделение предотвращает межпротокольный конфликт только тогда, когда все распределители в одной области исполняют актуальное правило. Попадание ID в нужный блок не доказывает источник назначения, отсутствие коллизии, подписку получателя, пересылку или приём нужного (S,G).

После объединения двух производственных сегментов новый хост выбирает 0xF0000050 для SSM-канала. Значение находится в диапазоне, который RFC 10028 выделил для назначения хостом. В соседнем сегменте старый сервер MADCAP всё ещё считает своим пулом 0x800000000xFFFFFFFF по RFC 3307 и выдаёт тот же ID другому приложению.

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

RFC 10028, опубликованный в августе 2026 года как документ IETF Standards Track, исправляет исходную геометрию диапазонов. Но стандарт не перепрошивает оборудование, не запускает холодный резерв и не очищает старые аренды. Реестр устанавливает границу; оператор доказывает, что работающие системы её приняли.

В RFC 3307 два метода искали в одном пространстве

RFC 3307 определял младшие 32 бита адреса IPv6 multicast как идентификатор группы и использовал их в отображении на канальный уровень. Серверное и хостовое динамическое назначение получали один диапазон. Его верхняя часть также пересекалась с Solicited-Node.

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

RFC 10028 и действующий реестр IANA IPv6 Multicast Address Space вводят разделение:

  • 0x800000000x8FFFFFFF — MADCAP;
  • 0x900000000xEFFFFFFF — не назначено;
  • 0xF00000000xFCFFFFFF — хостовое назначение групп SSM;
  • 0xFD0000000xFDFFFFFF — Private Use;
  • 0xFE0000000xFEFFFFFF — Experimental Use;
  • 0xFF0000000xFFFFFFFF — Solicited-Node.

Будущие назначения в свободном блоке требуют Standards Action. RFC 8126 задаёт терминологию политики и контроля изменений. Такая таблица — минимальное общее правило, позволяющее разным методам не занимать одну территорию.

IANA при этом не выдаёт ID конкретной локальной службе. Запись реестра доказывает классификацию, а не версию программы, конфигурацию пула или состояние пакетов.

Для старого MADCAP остаётся обновление либо изоляция

RFC 10028 сокращает диапазон MADCAP и рекомендует обновить реализации. Существующее развёртывание должно либо работать на обновлённой версии, либо находиться в среде без других протоколов назначения IPv6 multicast.

На момент подготовки RFC авторам была известна одна реализация MADCAP и не были известны крупные развёртывания. Это ограниченное по времени наблюдение, а не современная инвентаризация. Встроенный контроллер, резервный образ или долгоживущая система могут отсутствовать в публичной статистике и оставаться в сети.

RFC 2730 описывает MADCAP как клиент-серверный механизм. Клиент обнаруживает серверы, запрашивает адрес и получает OFFER, ACK либо NAK; администратор задаёт локальную политику. ACK доказывает решение сервера, но не актуальность его границ.

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

Младшие биты становятся состоянием Ethernet

RFC 4291 определяет формат, область и ID группы IPv6 multicast. Временная группа имеет смысл внутри области. Соединение двух ранее изолированных областей меняет условия уникальности.

RFC 2464 отображает IPv6 multicast на Ethernet: 33:33 и последние четыре октета адреса назначения. Выбранный ID попадает в фильтры интерфейсов и таблицы коммутаторов. Правильное отображение не гарантирует уникальность.

RFC 10019 перечисляет последствия в zeroconf-сетях: лишняя фильтрация в ПО, потеря выгоды от snooping, перегрузка медленных линий и ограниченных аппаратных таблиц. Разделённые части сети могут независимо выбрать один адрес и обнаружить конфликт лишь после воссоединения.

Будущее децентрализованное решение должно находить коллизию и переносить потоки. RFC 10019 формулирует требования, но не поставляет готовый распределитель. RFC 10028 выделяет для такого метода отдельный блок.

SSM уменьшает координацию G, но не число наблюдений

RFC 4607 задаёт канал SSM парой (S,G). Разные источники могут повторно использовать G. RFC 8815 поэтому отмечает, что глобальная уникальность G в пространстве SSM не требуется.

Но источник, поддержка приложения, членство и пересылка остаются. RFC 10028 прямо говорит, что SSM поддерживается не везде. Некоторые недорогие коммутаторы хранят только MAC назначения. RFC 4541 показывает, как несовпадение версий и возможностей IGMP/MLD snooping может ошибочно отсечь нужный поток или разлить незарегистрированный.

Корректный SSM-адрес следует сопоставить с S, отчётом MLD/IGMP, записью snooping, маршрутом и прикладным контрольным пакетом.

Частный и экспериментальный блоки не снимают ответственность

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

Experimental Use допускает испытание новых протоколов, причём RFC 10028 не ограничивает эксперименты закрытой сетью. Метка не гарантирует безопасность, разрешение или совместимость. Нужны владелец, область, срок и подтверждение удаления.

Неназначенный блок не является местным резервом. Solicited-Node выполняет отдельную функцию IPv6 и не служит свободным динамическим пулом.

В запись назначения нужно включить поколение правила

Хранить ревизию стандарта, класс и версию распределителя, хеш конфигурации, событие выбора или аренды, полный IPv6-адрес, область, ID, Ethernet-назначение, приложение и жизненный цикл. В SSM источник входит в идентичность канала.

Далее связать все распределители в области, пробы коллизий, MLD/IGMP, snooping и forwarding, первый и последний пакет, неожиданный источник, перенумерацию и удаление старого состояния.

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

Принцип Heng Lu о первенстве работающего кода помещает доказательство в эту исполненную цепочку. Его минимальная исходная спецификация и локальные будущие решения объясняют узкую общую границу и локальное принятие. Различие между формальным и практическим контролем данных показывает, почему IETF и IANA описывают пространство, но не управляют локальным бинарником и получателем.

Карта уже обновлена. Работающая инфраструктура ещё должна доказать свою миграцию.