Кратко

  • Приложение выбирает случайный group ID, строит IPv6- и Ethernet-адреса, затем заявляет Ethernet-назначение PTR-записью mDNS в .eth-addr.arpa.
  • Сетевое устройство может добавить -veto к первой метке приложения; такая запись всегда выигрывает сравнение mDNS и заставляет проигравшего остановить поток и выбрать адрес заново.
  • Редакция 12 остается Internet-Draft на стадии Last Call; запрошенные значения IANA еще не выделены, а автор записи veto не аутентифицируется.

«Нулевая настройка» звучит как отсутствие центра принятия решений. Этот проект показывает более точную картину: центр исчезает, а полномочия распределяются по этапам.

draft-ietf-pim-ipv6-zeroconf-assignment-12 опубликован 22 сентября 2026 года; Last Call завершится 6 октября. Документ просит IANA выделить диапазон 0x90000000-0x9FFFFFFF, имя eth-addr.arpa и специальный домен 9.3.3.3.3.eth-addr.arpa.. Пока это запросы, а не действующие назначения.

Для нового потока приложение случайно выбирает 28-битный идентификатор. По RFC 4489 оно соединяет его с interface identifier источника и получает link-local multicast-адрес IPv6. RFC 2464 дает Ethernet-назначение.

Разные IPv6-адреса могут свернуться в один Ethernet-суффикс. Поэтому проект координирует именно объект, который фильтруют NIC и switch. Nibble адреса записываются в обратном порядке: 33:33:9A:BC:DE:F0 превращается в 0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa.

Молчание действует только внутри слышимой области

PTR под этим именем указывает на идентификатор приложения и hostname. Приложение выполняет probe по RFC 6762. Проигравший одновременный спор выбирает новое значение. При отсутствии конфликта приложение объявляет PTR, отвечает на запросы и запускает непрерывный запрос. Лишь после этого оно может передавать данные.

Доступность не подтверждается ответом — она выводится из отсутствия возражений. Фильтрация mDNS может скрыть конкурента и дать двум приложениям одинаковое ощущение разрешения.

Выбранный group ID сохраняется, но после перезапуска нельзя пропустить probe и announce. За время простоя могла восстановиться partition или появиться другой владелец. Сохраненное число — историческое предпочтение, не lease.

При позднем конфликте проигравший сначала прекращает поток, затем выбирает новый ID. Сетевой стек также может заметить разные IPv6-назначения на одном Ethernet-адресе. Какая сторона должна уступить между хостами, проект не координирует.

Инфраструктура получает гарантированный перевес

Компонент сети, обнаруживший неразрешимую коллизию таблицы или фильтра, публикует PTR veto под тем же owner name. К первой метке PTRDNAME приложения добавляется -veto. При сравнении RDATA длина метки идет раньше содержимого, поэтому более длинная метка всегда оказывается лексикографически позже и побеждает.

Устройство публикует veto без probe. Приложение останавливается, выбирает новый ID и перезаписывает сохраненное значение. После исчезновения исходного PTR по expiry или goodbye держатель veto спрашивает сеть пять секунд; без ответа ждет случайные 20–120 мс и отзывает запись своим goodbye.

Так возникает явная иерархия: приложение предлагает, peers оспаривают, инфраструктура отменяет, а приемники все еще обязаны проверить результат.

Победа записи не доказывает правдивость

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

Протокол не доказывает, что veto выпустил switch с реальной аппаратной проблемой. Успешный announce не удостоверяет отправителя и не подтверждает подписку приемника, доставку или действие приложения.

Операционный след должен связывать идентичность потока, group ID, source IID, IPv6- и Ethernet-назначения, owner и RDATA, probe, announce, поколение непрерывного запроса, автора конфликта, подтверждение остановки, замену, миграцию приемников и отзыв старой записи.

После восстановления partition непрерывный запрос помогает, но малошумный mDNS может заметить дубликат поздно. Дополнительное обнаружение для потоков, созданных во время изоляции, оставлено будущей работе. Большое случайное пространство снижает вероятность, но не возвращает видимость и не объединяет раздельные истории.

RFC 10019 сформулировал задачу без готового протокола и правила победы. Редакция 12 дает конкретный ответ. В логике Running-Code Primacy PTR остается заявлением, сравнение — действующим контролем, switch — физическим наблюдением, приложение — результатом. Ценность проекта не в отмене власти, а в том, что один акт власти становится наблюдаемым.

Источники