Кратко

  • RFC 9762 добавляет в PIO положительное предпочтение для конкретного префикса: поддерживающему механизм клиенту следует попробовать DHCPv6 Prefix Delegation до создания новых индивидуальных адресов из общего SLAAC-префикса.
  • P=1 не является арендой. Доказуемая цепочка раздельно фиксирует RA, решение клиента, DHCP Reply, пригодность длины, binding и маршрут relay, входной фильтр, выбор исходного адреса и первого перехода, передачу пакета и результат приложения.
  • Отсутствие P не означает отсутствия DHCPv6-PD. Полученный P, в свою очередь, наследует границу доверия Router Advertisements; поддельные или колеблющиеся объявления могут задержать адресацию и вызвать лишние REBIND.

Два резервных relay вернули клиенту один и тот же делегированный префикс. Клиент сохранил оба link-local адреса как связанные с ответом. На одном первом маршрутизаторе binding превратился в маршрут, на другом — нет. Состояние DHCP выглядело успешным, а результат зависел от выбранного первого перехода.

Флаг P ничего не мог сказать об этой развилке. В RFC 9762 он появляется раньше: помогает выбрать способ получения адресов до того, как приложения привяжутся к SLAAC-адресу, который потом пришлось бы убирать. Ответ сервера, состояние relay и фактический путь принадлежат следующим слоям.

Название DHCPv6-PD Preferred Flag располагает к слишком широкому индикатору «делегирование доступно». Затем зелёный цвет заимствуют для утверждений «префикс выдан», «маршрут установлен» и «сервис работает». Наблюдение уже: конкретный интерфейс получил RA, конкретный PIO содержал P, а совместимый клиент получил причину запустить другой протокол.

Сигнал должен опередить дорогой выбор адреса

Если узел сначала сформирует адреса SLAAC из общего on-link префикса, приложения могут немедленно начать их использовать. После получения отдельного префикса сохранение обоих наборов уменьшит выигрыш в масштабировании, а удаление первого набора может оборвать действующие соединения.

Поэтому P=1 передаёт предпочтение до этой точки. Для совместимого клиента сеть предлагает модель отдельного префикса на устройство из RFC 9663. Предпочтение относится к конкретному PIO. Глобальный префикс может направлять клиента к PD, а другой ULA-префикс в том же RA — оставаться для SLAAC. В multihoming разные upstream могут объявлять разные решения.

P не зависит от битов M и O в RA. Некоторые старые устройства начинают PD только при установленном M или O, поэтому сети для них может понадобиться дополнительный сигнал. Маршрутизатор также обязан позволять независимую настройку P и Autonomous A. Изменение P не должно автоматически менять A.

Разделение сохраняет fallback. P и A могут быть установлены одновременно. Пока клиент исполняет предпочтение, он рассматривает A как сброшенный и не создаёт новые SLAAC-адреса из этого PIO. Если подходящего делегирования нет, он может прекратить обработку P на интерфейсе и вернуться к SLAAC или IA_NA. RFC 4862 задаёт обновлённые правила автоконфигурации, а RFC 4861 — основу Neighbor Discovery и RA. Новый бит меняет одну ветвь выбора, а не отменяет прежние механизмы.

Предпочтение живёт в списке со своим временем

Клиент ведёт для каждого интерфейса список всех префиксов, полученных в PIO с P=1 и ненулевым preferred lifetime. Когда длина списка вырастает с нуля до одного, следует начать запрос PD, если он ещё не выполняется. Истечение preferred lifetime или новый PIO с нулевым временем удаляет запись.

Обратный переход условен. Когда список пустеет, клиент должен прекратить запросы или renew только при отсутствии иной причины продолжать PD. Время уже делегированных префиксов не меняется. Отправитель RA отзывает приглашение, но не отменяет действующую аренду DHCP-сервера.

Изменение списка при существующих делегированиях обычно считается новой конфигурационной информацией и вызывает REBIND, кроме случая, когда список стал пуст. RFC 8415 определяет DHCPv6 state machine. Rebind, Reply, сервер, transaction и IA_PD — новые события, а не скрытая часть предыдущего объявления.

Операционный журнал должен хранить источник RA, интерфейс, PIO, P/A/L, preferred и valid lifetime и поколение списка. Отдельно фиксируется, действительно ли клиент отправил Solicit или Rebind и какое локальное правило сработало. Текущее значение P не различает естественное истечение, явный отзыв, потерю пакетов и осцилляцию.

В Reply может не оказаться пригодного префикса

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

Исходный RA не гарантирует ни один вариант. Сервер может быть недоступен, пул исчерпан, policy может отклонить клиента, а Reply — содержать ошибку. Длина или lifetimes могут не подходить. После ограниченной неудачной попытки клиент вправе отключить P на интерфейсе и применить другой доступный способ адресации.

Следовательно, доказательство делегирования соединяет request и length hint с фактически выбранным сервером или relay, Reply, IAPREFIX, preferred и valid lifetime и решением клиента принять результат. Факт P подтверждает только более раннее предпочтение.

Нельзя делать и обратный вывод. P — исключительно положительный индикатор. Отсутствие PIO с P не доказывает, что PD отсутствует. CE-маршрутизатор по RFC 7084 или явно настроенный узел может продолжать PD независимо от объявления. Не наблюдалось приглашение — не значит не существует сервис.

Relay превращает lease в маршрут

В модели RFC 9663 сервер делегирует префикс, а первый маршрутизатор устанавливает к нему маршрут через link-local адрес клиента. Для инфраструктуры префикс становится off-link. Вместо Neighbor Cache для каждого глобального адреса она может держать один маршрут на устройство, даже если узел использует множество адресов, контейнеров или внутренних интерфейсов.

Эту проекцию не делает P. RFC 8987 требует от delegating relay вести leases, next hops и локальные маршруты, обновлять входные фильтры, сохранять или удалять состояние по временам DHCP и предоставлять операционные данные. Reply у клиента не доказывает маршрут. Маршрут на одном резервном устройстве не доказывает состояние другого. Запись RIB не доказывает forwarding.

Клиент тоже несёт ответственность. Делегированный префикс является off-link на интерфейсе получения. Пакет к адресу внутри этого префикса нельзя отправлять обратно через тот же интерфейс: получится петля. Один вариант защиты — discard route с высокой метрикой. Адреса из делегирования следует считать связанными с интерфейсом для выбора источника по RFC 6724.

В multihoming к префиксу нужно привязать link-local адрес сервера или relay, от которого пришёл Reply. При одинаковом префиксе от резервных систем связей может быть несколько. RFC 8028 объясняет, почему исходный префикс и первый маршрутизатор должны соответствовать друг другу. Правильный адрес через неправильный upstream остаётся ошибкой.

Полная цепочка выглядит так: RA; поколение P-list; DHCP request; принятый Reply; lease; relay binding; маршрут и фильтр; адрес; выбор источника; первый переход; доставка пакета; завершение приложения. Соседство событий не передаёт им полномочия друг друга.

Трафик на одном канале тоже меняет путь

При отдельном префиксе на клиента глобальный адрес соседнего клиента считается off-link. Первый пакет между двумя устройствами одной broadcast domain идёт на default router. ICMPv6 Redirect может предложить прямой путь. RFC 9762 рекомендует поддерживающим хостам обрабатывать Redirect, если локальная политика не запрещает. Иначе локальный обмен может получить дополнительную задержку.

Проверка до внешнего адреса не покрывает этот сценарий. Делегирование и upstream могут работать, а peer-to-peer трафик, локальное обнаружение или lateral ACL — идти неожиданно. Приёмка должна различать внешний и локальный путь, прямое и обратное направления.

Меняется и стоимость состояния. RFC 9663 обменивает больше адресного пространства и маршрутов на клиента на меньше записей ND на адрес и единый fate-sharing для адресов устройства. Это может помочь крупной Wi-Fi сети и быстро исчерпать /64 в доме с небольшим upstream-префиксом. P сообщает предпочтение модели, но не удостоверяет расчёт пула.

Реестр IANA не удостоверяет отправителя

Реестр IANA для флагов IPv6 Neighbor Discovery PIO закрепляет bit 3 за P и ссылается на RFC 9762. Он устраняет неоднозначность синтаксиса. Он не подтверждает полномочия устройства, пославшего RA в конкретный порт.

Без защиты RFC 6105 локальный атакующий может послать похожий PIO с P=1 и заставить совместимые хосты игнорировать A. При отсутствии рабочей PD-инфраструктуры адресация задержится или сорвётся. RFC 7113 дополнительно показывает, что надпись «RA-Guard включён» не доказывает отсутствие обходов через фрагментацию и extension headers.

DHCP образует отдельную границу. Без DHCPv6-Shield из RFC 7610 ложный сервер может вернуть неверный префикс или конфигурацию. Даже если RA и DHCP принадлежат одному оператору, это разные сообщения и точки исполнения. Доверие к одному не аутентифицирует другое.

Ошибочная или враждебная система может чередовать P=1 и P=0. Изменения списка вызывают REBIND и нагрузку. Rate limiting из RFC 8415 ограничивает сообщения клиента, но не доказывает нулевой эффект. Входы, переходы и downstream-работу нужно считать отдельно.

Небольшие полномочия — достоинство протокола

От P не требуется удостоверять всю цепочку. Он координирует порядок первого выбора, оставляя allocation, routing, filters, fallback и результат их собственным владельцам. Принцип Heng Lu о минимальной исходной спецификации, локальном будущем решении и добровольном принятии описывает такую тонкую общую поверхность. Первенство работающего кода требует проверить исполненное состояние. Слои реальности не позволяют склеить норму, пакет, lease, маршрут и пользовательский итог.

Бит сохраняет ценность, пока утверждение не становится шире его полномочий.