Кратко

  • В истории IETF draft-ietf-pim-gaap-23 датирован 3 сентября 2026 года и переведён в состояние AD Followup; это по-прежнему экспериментальный Internet-Draft, а не утверждённый RFC.
  • Версия 23 предписывает использовать 239.0.0.0/10 для IPv4 и диапазон Experimental Use из RFC 10028 для IPv6, чтобы независимо разработанные реализации вычисляли адреса в общем пространстве.
  • Проект также отмечает: при разделении одна сторона может выбрать кандидат +1, а другая — +2 для одного имени. Адреса различаются, коллизия не возникает, и после восстановления связи группа может остаться разделённой.
  • Отсутствие коллизии — отрицательное наблюдение, а не положительное доказательство того, что имя, адрес и участники сошлись.
  • Локальная квитанция о сходимости сохранила бы нужные свидетельства. Это аналитическое предложение Daniel Kade, а не требование GAAP или IETF.

Один источник расхождения устранён общей настройкой

История документа фиксирует версию 23 Group Address Allocation Protocol 3 сентября. В тот же день подсостояние сменилось с Revised I-D Needed на AD Followup, а проверка IANA вернулась к Version Changed - Review Needed. Это этапы незавершённой работы. Они не означают ни одобрения IESG, ни публикации RFC.

В журнале изменений версии 23 сказано, что она учитывает DISCUSS и комментарии Éric Vyncke. Содержательно редакция проводит полезную границу: одно расхождение ликвидируется едиными исходными параметрами, другое остаётся возможным и после этого.

GAAP предлагает участникам многоадресной рассылки получать групповой адрес без центральной службы распределения. Приложение передаёт имя группы. Протокол вычисляет SHA-256 только для четырёх допустимых строк: самого имени и имени с добавлением +1, +2 или +3. Узел отправляет Claim для первого кандидата и ждёт приблизительно один периодический интервал — около минуты. Если за это время не поступает требование, где другое имя использует тот же сетевой адрес, приложение может начать работу. При коллизии оно переходит к следующему кандидату.

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

Официальное сравнение версий 22 и 23 показывает исправление. Раньше диапазоны для приложений задавались оператором. Теперь проект объясняет, что настраиваемый диапазон будет надёжно совместим только с таким же диапазоном: оператор может выбирать приложения в своём домене, но не в состоянии контролировать, какую независимую реализацию GAAP каждое из них включает.

Для IPv4 обязательным становится 239.0.0.0/10. Текст опирается на RFC 2365, где перечислены блоки для расширения области Organization-Local, и на правила распределения из RFC 5771. Для IPv6 выбран 0xFE000000–0xFEFFFFFF — диапазон Experimental Use, который RFC 10028 отводит для экспериментов с новыми протоколами динамического распределения. GAAP не получает исключительных прав на этот диапазон; им могут пользоваться другие эксперименты.

Фиксированные значения — реальное улучшение совместимости. Две соответствующие проекту реализации больше не начнут расчёт в непересекающихся адресных пространствах. Однако общее поле кандидатов ещё не заставляет их выбрать одного кандидата для конкретного имени.

Восстановленная сеть может сохранить два правильных ответа

Механизм исправления раздела обрабатывает заметный случай. Если обе стороны используют один адрес для группового имени, после возвращения связи их Claims встречаются, и процедура может сопоставить состояние и устранить конфликт.

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

После восстановления связи одна сторона объявляет адрес A, другая — адрес B. Определённой в GAAP коллизии — один адрес у разных имён — нет. Ничего не сталкивается. Версия 23 прямо говорит, что группа остаётся разделённой, и оставляет решение открытым вопросом эксперимента.

Vyncke задал именно этот вопрос в своей позиции IESG: будет ли обнаружена ситуация, когда разделённые сети выбрали +1 и +2, и сойдутся ли все участники? Новый текст переносит вопрос в явную границу спецификации, но пока не определяет механизм сходимости.

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

RFC 10019, на который ссылается GAAP, требует, чтобы децентрализованное распределение обнаруживало и корректно разрешало адресные коллизии после временного разделения. Эта задача сохраняется. Новая граница находится рядом, но относится к другому объекту: двум отображениям одного имени. «Коллизия устранена» и «имя сошлось» должны стать отдельными результатами опыта.

Эксперименту нужна положительная проверка встречи

Проект не преувеличивает зрелость протокола. В нём сказано, что децентрализованное распределение по хешу пока не развёртывалось. Эксперимент должен выяснить, достаточны ли обнаружение и исправление коллизий в практических сетях, какие частоты коллизий возникают при разном масштабе и как растёт периодический трафик Claim. Он будет завершён, если эксплуатационные данные поддержат будущий переход к Standards Track либо выявят фундаментальный недостаток, требующий новой редакции.

Тихий раздел теперь входит в этот предмет. Счётчик показывает, сколько раз разные имена попали на один адрес и сколько раз процедура отреагировала. Он не показывает, сколько раз одно имя осталось на двух адресах: такое состояние не поступает на вход счётчика. Нужно наблюдать само отображение и проверять, смогли ли предполагаемые участники после восстановления обмениваться данными в одной группе.

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

Эта квитанция — моё редакционное предложение. Её нет в GAAP, и она не является политикой IETF, IANA или рабочей группы PIM. Она нужна, чтобы отсутствие плохого сигнала не превращалось в доказательство хорошего свойства, которое никто не измерял.

Идея Lu Heng из Minimum Initial Specification, Localized Future Decision помогает не отказываться от децентрализации. Фиксированный диапазон — небольшое общее правило, без которого независимые реализации не встретятся. Методы наблюдения, хранения и исправления редкого расхождения могут развиваться локально, если результаты остаются сопоставимыми и не исчезают.

Running Code Primary задаёт порядок доказательства. Новый статус документа, распределение IANA или снятие DISCUSS меняют институциональную запись. Они не демонстрируют, что две реализации после разных локальных коллизий вернутся к одному отображению. Для этого нужен воспроизводимый тест: создать раздел, вызвать +1 и +2, восстановить путь и сохранить реально использованные адреса.

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

Источники

  1. Карточка GAAP в Datatracker
  2. История документа GAAP
  3. GAAP, версия 23
  4. GAAP, версия 22
  5. Официальное сравнение версий 22 и 23
  6. Бюллетень IESG по GAAP
  7. RFC 10019: проблема zeroconf-распределения многоадресных адресов
  8. RFC 10028: динамические идентификаторы групп IPv6 multicast
  9. RFC 2365: IP multicast с административной областью
  10. RFC 5771: правила IANA для многоадресных IPv4-адресов
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision
  12. Lu Heng — Running Code Primary