Кратко

  • PvD — граница согласованности для исходного адреса, DNS, первого маршрутизатора и остальных параметров. FQDN, флаги и номер последовательности обозначают и обновляют эту границу, но не задают приоритет пути.
  • Доверие складывается поэтапно: дополнительные сведения получают через тот же PvD, проверяют имя, сертификат, идентификатор, срок и префиксы, затем применяют локальную политику. Фактический выбор доказывают источник, резолвер, следующий переход и результат соединения.

Известное имя не стало выбранным выходом

Хост получает два явных PvD по одному каналу. Первый использует FQDN знакомого оператора, выставляет флаг H и содержит номер последовательности новее вчерашнего. Панель мониторинга подсвечивает его и объявляет выбранным.

Однако полученный по аутентифицированному HTTPS объект содержит noInternet: true. Этот домен исправно обслуживает ограниченные локальные ресурсы. Для обращения браузера в открытый Интернет политика хоста выбирает второй PvD. Внутреннее приложение одновременно может пользоваться первым.

Протокол не противоречит сам себе. Имя, свежесть, пригодность для цели и исполненное решение — четыре разных факта. Ошиблась панель, сведя их к одному статусу.

В многосетевом хосте подобное упрощение скрывает опасное смешение. Исходный адрес одной сети можно случайно соединить с DNS другой и шлюзом третьей. Каждый элемент выглядит корректно, но обратный маршрут или область имён ломаются. RFC 7556 вводит Provisioning Domain именно для сохранения происхождения конфигурации.

Домен не равен интерфейсу

RFC 7556 определяет PvD как согласованный набор сетевой конфигурации. В него могут входить исходные префиксы, DNS-серверы, поисковые суффиксы, прокси и шлюзы по умолчанию.

Несколько PvD способны существовать на одном канале, а один PvD — охватывать несколько каналов. Поэтому граница не совпадает с физическим портом. Интерфейс показывает место получения, PvD — какие сведения разрешено использовать совместно.

Архитектура различает неявные домены, выведенные из источника конфигурации, и явные домены с идентификатором. В обоих случаях хост сохраняет связь каждого параметра с его контекстом. Для конкретного соединения система, пользователь или приложение выбирают PvD по безопасности, стоимости, доступности и назначению, а затем берут внутри него совместимые адрес, DNS и маршрутизатор.

Единого рейтинга стандарт не задаёт. Закрытая производственная сеть может идеально подходить для управления оборудованием и не подходить браузеру. Разные приложения на одном устройстве вправе одновременно выбирать разные домены.

Router Advertisement называет контекст

RFC 8801 определяет PvD Option как тип 21 Neighbor Discovery в IPv6 Router Advertisement. Опция содержит PvD ID в форме FQDN, флаги H/L/R, 16-битный номер последовательности, Delay и при необходимости вложенные сведения RA.

Объявляющий оператор должен владеть FQDN и управлять им. Один ID предназначен только для в конечном счёте одинаковой услуги; разные услуги должны иметь разные имена. Это даёт устойчивое пространство имён, но не аутентифицирует локальный маршрутизатор автоматически. Злоумышленник в канале тоже способен вписать известный FQDN в поддельную RA.

Полномочия флагов узки. H сообщает о дополнительных данных по HTTPS. L связывает унаследованные сведения DHCPv4. R обозначает внутренний заголовок и опции RA для PvD-aware хостов. H не доказывает успешную загрузку или принятие объекта, а R не означает предпочтение.

Номер последовательности отражает поколение данных одного домена. Его изменение устаревает сохранённый объект и может запустить повторный запрос со случайной задержкой. Значение 42 в одном PvD не выше 7 в другом. Delay распределяет нагрузку, а не выражает срочность.

Проверочный запрос нельзя выносить в другой PvD

При установленном H хост может обратиться к https://<PvD-ID>/.well-known/pvd. Без H такой механизм использовать нельзя. Ответ имеет тип application/pvd+json.

DNS-разрешение PvD ID, проверка сертификата, HTTPS, выбор исходного адреса и следующего перехода должны опираться исключительно на конфигурацию рассматриваемого PvD. Разрешить имя через вторую сеть и скачать объект через третью — значит разрушить проверяемую связь.

Ограничение защищает и приватность. Split DNS может отвечать по-разному в разных контекстах, а исходный префикс влияет на правильный первый маршрутизатор. Запрос корпоративного PvD-имени через чужую сеть раскрывает факт знакомства устройства с этой организацией. Одной конечной ссылки в журнале недостаточно.

TLS-сертификат должен содержать DNS-ID, равный PvD ID. При ошибке хост закрывает соединение и считает, что у домена нет дополнительных сведений. Это подтверждает разрешение владельца FQDN на информационный сервис, но не удостоверяет само локальное объявление и все заявленные префиксы.

JSON замыкает связь с префиксами

Корректный объект включает identifier, expires и prefixes. Идентификатор совпадает с объявленным именем, срок находится в будущем, а список префиксов покрывает все Prefix Information Options связанной RA. Отсутствующее или неверное обязательное поле заставляет игнорировать объект; непокрытый префикс делает сведения непригодными.

Сопоставляются два утверждения. Локальный маршрутизатор говорит, что конфигурация принадлежит имени. Аутентифицированный сервис заявляет, что имя признаёт определённые префиксы. Контроль только над одной поверхностью не создаёт полной власти над связью.

dnsZones может описывать области DNS, доступные в домене. noInternet: true означает ограниченную услугу, а не поломку. Для завода, больницы или предприятия отсутствие общего Интернета может быть требуемым свойством.

Неизвестные ключи игнорируются. Общий реестр ведёт IANA, а частные расширения помещаются в организационные или vendor-* подсловари. Регистрация создаёт совместимое значение, но не подтверждает правдивость конкретного объявления или массовое внедрение.

У свежести есть пределы и остановка

Смена последовательности или истечение срока устаревают сохранённые данные. Delay и случайные окна обновления не позволяют множеству хостов одновременно нагрузить сервер. Абсолютное время зависит от часов устройства и не может в одиночку служить основой чувствительного решения безопасности.

Вредоносный маршрутизатор способен разослать множество ID и вызвать DNS-, TLS- и HTTP-запросы к сторонним серверам. Хост ограничивает частоту, после ошибки сертификата, HTTP или JSON больше не запрашивает этот ID в текущем подключении, а после десяти и более сбоев прекращает все запросы PvD-информации для данного подключения.

Установив H, оператор берёт и обязательство доступности. Даже captive portal должен до входа пропускать нужные DNS, проверку сертификата и HTTPS. Хосту следует применять временный IPv6-адрес из этого PvD и не передавать cookie либо идентифицирующие заголовки.

Решение видно только в работе хоста

После проверки остаётся выбор для конкретной цели. Оператор именует и предоставляет согласованный контекст. Владелец FQDN удостоверяет информационный сервис. JSON описывает границы. Хост решает, подходят ли они приложению.

Доказательством служат реально использованные исходный адрес, DNS, первый маршрутизатор, назначение и результат. Running-Code Primacy здесь не отменяет общий стандарт: он требует показать, что исполняемая реализация сохранила установленные стандартом минимальные связи.

Источники