Кратко

  • draft-ietf-pim-ipv6-zeroconf-assignment-12 позволяет приложению считать адрес доступным, если оно не получило признаков его использования. Такая отрицательная информация действительна только в реально наблюдаемой области mDNS.
  • Сохранённый идентификатор группы уменьшает число изменений, но не отменяет проверку, объявление, постоянный запрос и защиту PTR. После восстановления разделённой сети проигравшая сторона должна остановить поток, выбрать новое значение и сохранить его.

Редакция 12 датирована 22 сентября 2026 года. В зафиксированной карточке Datatracker это активный Internet-Draft рабочей группы PIM, переданный в IESG и находящийся на IETF Last Call до 6 октября. Целевой статус — Proposed Standard. Документ ещё не является RFC, завершённым решением IANA, отчётом о совместимости или подтверждением внедрения.

Для нового потока либо после конфликта приложение случайно выбирает ID из предлагаемого диапазона 0x90000000–0x9FFFFFFF. Совместно с идентификатором исходного интерфейса он образует source-specific IPv6 multicast-адрес области канала. Из него выводится Ethernet multicast-адрес. В примере ID 9abc:def0 даёт 33:33:9A:BC:DE:F0.

Полубайты Ethernet-адреса записываются в обратном порядке под .eth-addr.arpa. Приложение создаёт уникальный PTR, проверяет его по mDNS, объявляет, отвечает на запросы, запускает постоянный запрос и защищает запись. Так локальная уникальность координируется без центрального распределителя.

Ключевое допущение редакция называет implicit availability. Если признака занятости не получено, адрес считается доступным. Следующая фраза предупреждает: фильтрация mDNS на хосте или в сети препятствует координации и может привести к коллизии.

Молчание поэтому имеет географию и время. Оно говорит лишь о том, что на определённых интерфейсах и путях за данный интервал не появился противоречащий PTR. Оно ничего не говорит об отправителе за фильтром, сломанным reflector или временно изолированным сегментом. Формула n / 2^28 оценивает случайное совпадение, а не полноту конкретного наблюдения.

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

После ремонта связи два утверждения встречаются. Именно поэтому проект требует постоянного запроса PTR. При обнаружении конфликта применяются правила mDNS: проигравшее приложение прекращает передачу, возвращается к выбору, получает другой ID и перезаписывает сохранённое значение.

Обнаружение не обязано быть быстрым. Авторы отмечают, что mDNS рассчитан на низкую полосу и после ремонта разделения может потребоваться значительное время, чтобы заметить конфликт записей. Универсального предельного срока нет. Особенно важен этот интервал там, где новые потоки могут появляться в любой момент.

В этот период оба отправителя могут выглядеть исправными. Один Ethernet multicast-адрес может нести пакеты для разных IPv6 multicast-назначений. Панель с единственным признаком «PTR объявлен» не отличает уникальность от временной невидимости соперника.

Есть дополнительный, необязательный датчик. Сетевой стек хоста может заметить трафик с тем же Ethernet multicast-назначением, но иным IPv6-назначением. Тогда приложение обязано остановиться и выбрать другой ID. Достаточно изменения одной стороны, однако измениться могут обе; координация того, кто уступает, не задана.

У инфраструктуры предусмотрен veto. Компонент, который обнаружил неразрешимую коллизию, добавляет -veto к первой метке цели PTR. Такая запись всегда оказывается позже в лексикографическом сравнении mDNS и выигрывает. Она публикуется без предварительной проверки и заставляет приложение сменить ID.

Veto не хранится вечно. Когда исходный PTR исчез или истёк, издатель опрашивает сеть пять секунд. При отсутствии ответа он ждёт случайные 20–120 миллисекунд и отправляет goodbye. Перемещённое приложение уже сохранило замену, поэтому постоянная блокировка не нужна.

Механизм создаёт и поверхность отказа в обслуживании. Злоумышленник может отвечать ложным конфликтом на каждую пробу либо публиковать veto для уже занятых адресов. Фильтрация mDNS способна полностью нейтрализовать предотвращение коллизий. Протокол предполагает сотрудничество участников, но не удостоверяет его.

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

В логике Running-Code Primacy авторитет принадлежит выполненной последовательности: выбору, вычислению, проверке, объявлению, наблюдению, защите, остановке и замене. Статичная строка «выделен» подтверждает прошлое использование, но не текущую область видимости. Стабильность идентификатора способна скрыть нестабильность работающего потока.

Адресная координация также не равна обнаружению сервиса. Проект не задаёт, как сообщить получателю IPv6-адрес потока. DNS-SD с _udp и TXT назван лишь естественным вариантом. Даже успешное обнаружение не доказывает членство получателя, состояние multicast-пересылки, доставку пакетов или результат приложения.

Для нескольких подсетей PTR должны распространяться между ними, например через mDNS reflector; проект называет это продолжающейся областью исследований. Пересылаемый поток должен использовать IPv6 multicast на основе unicast-префикса, а не адрес области канала. Из-за требования сотрудничества хостов схема не подходит для глобального Интернета.

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

Главный вопрос — не был ли включён mDNS, а кто мог возразить. Пока ответ не записан, слово «свободен» означает только отсутствие видимого возражения.

Источники