Кратко

  • RFC 9872 рекомендует получать PREF64 из опции Router Advertisement по RFC 8781, если она доступна; DNS-механизм RFC 7050 остаётся резервом для отсутствующего сигнала и старых узлов.
  • Рабочее состояние в multihoming — это ограниченная по времени связь префикса, объявившего маршрутизатора, исходного адреса, следующего перехода и результата трансляции.

Сбой может состоять только из правильных элементов. DNS64 провайдера A сообщает действительный PREF64. Узел синтезирует адрес, но выбирает исходный IPv6 и шлюз провайдера B. Пакет сформирован корректно, однако транслятор A не лежит на выбранном пути.

RFC 9872, информационный документ IETF, опубликованный в сентябре 2025 года, задаёт предпочтение для устранения этой ошибки композиции. Конечные узлы должны сначала пробовать опцию PREF64 из RFC 8781, а операторы NAT64 — передавать её. DNS-метод RFC 7050 остаётся допустимым при отсутствии опции или ради устаревших реализаций.

PREF64 — IPv6-префикс для синтеза адресов, форматы которого определены RFC 6052. Он нужен локальному DNS64 по RFC 6147, клиентскому CLAT в RFC 6877 и преобразованию литералов IPv4 из RFC 8305. Способность синтезировать не доказывает достижимость транслятора.

RFC 7050 выводит префикс из синтетического ответа AAAA для ipv4only.arpa.; RFC 8880 закрепляет особую обработку этого имени. Требуется DNS64 данной сети или специальная логика узла. Сторонний рекурсивный сервер либо split-tunnel VPN, заменивший DNS, но не весь маршрут, может лишить значение локального контекста.

При двух провайдерах два DNS64 способны вернуть разные PREF64. Ответ DNS не связывает каждый из них надёжно с конкретным аплинком, исходным префиксом и шлюзом. Узел получает набор верных фактов, но не правило их совместимости. Именно поэтому отметка «префикс найден» недостаточна.

Router Advertisement сохраняет близость к первому переходу. RFC 4861 уже переносит сведения о маршрутизаторе и параметрах IPv6-канала. RFC 8781 добавляет PREF64 и срок действия. Узел может помнить источник объявления и прекратить применение после нулевого срока. Это ограниченное свидетельство, а не удостоверение подлинности или здоровья маршрута.

Отличается и отзыв. DNS-обнаружение выполняется после настройки стека и кэшируется до TTL; при внешнем DNS64 оператор доступа может не управлять этим временем. Новое RA способно немедленно обновить или отозвать префикс. Значение имеет не только задержка подключения, но и продолжительность ошибочного состояния.

Убрав зависимость от DNS-ответа, система переносит доверие к первому переходу. RFC 6105 описывает RA-Guard, но разрешённое объявление всё равно может быть неверным. RFC 9463 позволяет сообщать назначенные сетью защищённые резолверы; шифрование обмена не создаёт привязки PREF64 к каналу.

Переход требует учёта парка. Современные соответствующие узлы предпочитают RFC 8781, старые могут нуждаться в RFC 7050. RFC 9872 также отмечает разрыв: мобильные ОС умеют читать опцию, тогда как оборудование мобильной сети не всегда умеет помещать её в RA. Официальная карточка подтверждает публикацию, а не внедрение конкретным оператором.

Принцип Heng Lu о первичности работающего кода требует воспроизводимого результата пути. Его минимальная начальная спецификация оставляет общий сигнал узким, а решение — локальным. Тезис о постоянном налоге dual-stack возвращает руководству полную стоимость DNS, RA, защиты, трансляции и совместимости.

RFC 9872 не объявляет PREF64 истинной маршрутизацией. Он сохраняет происхождение, после чего выбор пути, доступ к транслятору и завершение приложения всё ещё требуют отдельных доказательств.

Источники