Кратко

  • RFC 5192 передаёт адреса PAA в порядке предпочтения и требует пробовать записи именно в этом порядке. Он не вкладывает в список проверку доступности, идентичности или результата PANA.
  • Network response, начало PANA и terminal outcome отвечают на разные вопросы. Если низкоуровневый ответ прекращает последовательность кандидатов, локальный алгоритм заменяет нормативный порядок более слабым сигналом.

Успешный ответ всегда соблазняет расширить вывод. Адрес отвечает — значит узел жив. Узел жив — значит PAA работает. PAA работает — значит discovery завершён. Каждая стрелка кажется разумной, пока не спросить, что именно было измерено.

RFC 5192 определяет более узкий объект: DHCPv4 или DHCPv6 доставляет упорядоченный список адресов PANA Authentication Agent. PaC обязан пробовать записи в полученном порядке. В option нет PANA result, identity receipt, service health, load или гарантии ответа.

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

У каждого слоя свой terminal state

Попытка начинается с list version и ordinal. Далее могут появиться route/neighbor observation, transport event, первое PANA message, validation peer/session и terminal result. Эти стадии не следует хранить в одном enum reachable.

Timeout до любого ответа отличается от malformed PANA message. Корректный протокольный ответ с отказом отличается от сетевой недоступности. Успех следующего кандидата не стирает прежний отказ.

Операционный отчёт должен сказать: «кандидат 1 ответил на сетевом уровне, PANA завершился причиной X; по policy был запущен кандидат 2». Если policy прекращает поиск после IP response, её версия тоже сохраняется. RFC 5192 такого сокращения не предписывает.

Этот предел не повторяет статью RFC 5191. Та статья владеет разделением authentication, authorization, Enforcement Point и data plane. Здесь вопрос предшествует им: что доказывает попытка адреса из discovery list?

Порядок — команда, а не прогноз

DHCPv4 option 136 содержит 32-битные адреса, а длина должна делиться на четыре. DHCPv6 option 40 содержит 128-битные адреса с длиной, кратной шестнадцати. В обоих случаях адреса перечислены по предпочтению.

Предпочтение даёт server authority над последовательностью. Оно не даёт ему способности предсказывать runtime. Первый адрес может отвечать хуже второго или перестать работать после формирования response.

Клиент должен сохранить точный порядок. Сортировка для UI, unordered set или дедупликация без ordinal могут изменить поведение. Должны существовать immutable raw list и отдельный attempt ledger.

Если локальная система использует health cache для пропуска кандидата, это дополнительная policy. Её источник, freshness и decision должны быть видимы; нельзя выдавать её за содержимое option.

Получение не доказывает запрос

PaC следует запросить option в DHCPv4 Parameter Request List или DHCPv6 Option Request Option. Но настроенный server должен отправить её даже без явного запроса клиента.

Response может содержать список, которого request не просил. Следовательно, нельзя говорить, что клиент «выбрал PANA discovery», только увидев option.

Записываются оба набора: requested codes и delivered codes. Они связываются transaction, family, interface, server и relay. Затем отдельно фиксируются validation и решение selector.

Так возникает проверяемая линия: сервер предложил список; parser принял; policy запустила попытку. Ни один шаг не приписывается предыдущему.

Молчание не отменяет требование безопасности

RFC 5192 запрещает использовать присутствие или отсутствие option как negotiation о применении PANA. Иначе удаление поля позволило бы downgrade до более слабой защиты или её отсутствия.

Option absent остаётся свойством конкретного response. PANA required приходит из отдельной policy surface. При отсутствии списка клиент может применить иной discovery, закрыть доступ или выполнить другую явно настроенную ветку.

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

Так же и failure PANA не доказывает, что server preference была неправильной: она могла выражать административный приоритет, а не доступность.

Неверную длину нельзя превращать в адрес

Кратность длины — условие однозначного разбиения. Остаток означает structural failure. RFC 5192 не задаёт алгоритм дополнения нулями или молчаливого усечения.

Receipt хранит option code, declared/captured lengths, raw bytes, validator и результат. Если продукт применяет recovery, это отдельная transformation с собственной версией и разрешением.

Absent, invalid и valid — разные состояния. Если invalid записывается как absent, расследование теряет данные о том, что сообщение пришло, но не прошло контракт.

Регистрация codepoint в IANA подтверждает назначение номера. Она не подтверждает корректность packet, поддержку client или работу endpoint.

Список живёт внутри DHCP-контекста

DHCP несёт transaction, server, relay, interface, lease, Renew и Rebind. Они дают списку время и место. Новый response с другим порядком создаёт новую version вместо перезаписи.

Выполняющаяся попытка остаётся связанной со старой version. Локальная policy может отменить её после обновления, но cancellation должен иметь собственную запись.

IPv4 и IPv6 дают отдельные списки. RFC 5192 не определяет общий racing algorithm. Family priority, parallelism, timeout и cache — локальные решения, которые нужно документировать.

Глобальное поле primary_paa не может объяснить, из какой семьи, транзакции и версии пришёл выбор.

Защита доказывается для конкретного обмена

RFC 5192 предупреждает: в большинстве сетей DHCP до access authentication не имеет integrity protection и origin authentication. Изменённый или вставленный response может направить PaC к rogue PAA, который перехватывает authentication requests или отказывает в доступе.

Стандарты DHCP описывают механизмы authentication. Их наличие в библиотеке ссылок не доказывает использование. Receipt должен назвать фактически проверенный mechanism, identity и result.

Даже защищённая доставка списка не означает, что адрес отвечает или PANA пройдёт. Она подтверждает provenance и integrity в своей области. Runtime observation остаётся последующим событием.

Нельзя и расширять source claim до конкретной атаки или текущей распространённости: fact packet таких данных не содержит.

Полная квитанция попытки

Сначала сохраняются DHCP request/response, interface, family, server, relay, protection и raw option. После validation появляется list hash, version и ordinals.

Selector сохраняет policy version и расписание. Каждый candidate получает network observation, PANA evidence и terminal reason. Победитель связывается с session; проигравшие не удаляются.

Тогда зелёный сетевой ответ занимает правильное место. Он полезен: показывает, что определённая часть пути дала сигнал. Он недостаточен: не может говорить от имени PANA.

Принцип Heng Lu о слоях реальности требует именно такого ограничения символической власти. Чем дешевле и раньше сигнал, тем сильнее соблазн сделать его общим verdict. Зрелая система сохраняет его точность, не расширяя смысл.

Sources

  1. RFC 5192 HTML
  2. RFC 5192 text
  3. RFC 5192 record
  4. Datatracker RFC 5192
  5. RFC 5192 history
  6. RFC 5192 references
  7. RFC 5192 errata
  8. RFC 2131
  9. RFC 2131 record
  10. RFC 2132
  11. RFC 8415
  12. RFC 8415 record
  13. RFC 3315
  14. RFC 5191
  15. RFC 3748
  16. RFC 3118
  17. IANA BOOTP/DHCP parameters
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy