Summary

  • Десятая версия проекта IETF предлагает представлять частные и общие IPv4-адреса через известный префикс NAT64. Обсуждение IESG Last Call продлится до 23 ноября 2026 года.
  • Неуправляемый клиентский CLAT должен будет преобразовывать такой трафик по умолчанию. Управляемому PLAT потребуется выключатель; при обновлении существующих устройств проект советует сохранять прежнее отбрасывание.
  • Один префикс упрощает архитектуру, но судьбу каждого пакета к внутреннему сервису должны решать маршрут и явные правила доступа.

У внутреннего сервера может быть охранник, о котором никто не писал в инструкции для охраны. В RFC 6052 сказано: известный префикс NAT64 64:ff9b::/96 нельзя сочетать с неглобальным IPv4-адресом, а преобразователь обязан отбросить такой пакет. Отдельного правила на межсетевом экране нет, но доступ всё равно закрыт. Новый проект IETF собирается убрать этот универсальный запрет. Теперь решение нельзя будет оставлять на совести формата адреса.

Старое ограничение появилось не случайно. Адреса RFC 1918 уникальны только внутри конкретной сети. Два филиала могут использовать 10.0.0.1 для разных машин. Общий префикс IPv6 не расскажет, какой филиал имелся в виду. Однако тотальный отказ перекрывает и нужную связь: устройство только с IPv6 может обращаться к внутреннему приложению, у которого до сих пор лишь IPv4. Проект затрагивает также общее адресное пространство RFC 6598.

Красивая схема с двумя префиксами

Предложить два префикса легко: известный для публичного IPv4, собственный для частного. DNS64, создающий ответ, может выбрать правильный вариант. Но приложение часто передает числовой IPv4-адрес напрямую, и клиентский CLAT сам строит IPv6-адрес назначения. В этом случае DNS64 ничего не выбирает.

По объяснению авторов проекта, механизмы из RFC 7050 и RFC 8781 сообщают клиенту префиксы, но не таблицу соответствия между диапазонами IPv4 и нужным префиксом. Узнав оба, клиент может построить два IPv6-адреса для одного публичного назначения. Фильтры, журналы и диагностика должны тогда разбирать два возможных пути. Префикс локального применения из RFC 8215 при совместном использовании с известным тоже не создает недостающую таблицу.

Поэтому версия 10 меняет саму формулу RFC 6052. Из «запрещено использовать» получается «допускается использовать». Неуправляемый CLAT будет преобразовывать такие пакеты по умолчанию. Управляемый PLAT будет делать это, если администратор не настроит отказ, и обязан предоставить такую настройку. Право сказать «нет» переходит от общей нормы к тому, кто управляет конкретной сетью.

Обновление программы не должно выдавать пропуск

В разделе о безопасности проект прямо говорит, что администраторы могли полагаться на прежнее обязательное отбрасывание как на неявную защиту частной инфраструктуры. Поэтому существующим управляемым PLAT рекомендуется сохранять блокировку по умолчанию при обновлении. Намеренное открытие пути требует маршрута в нужную частную сеть и ACL, межсетевого экрана либо фильтра NAT, где указаны источник, назначение и сервис. Потребуется проверить и обратный путь.

После объединения двух компаний одинаковый 10.0.0.1 может жить в разных частях общей сети. Преобразователь безупречно сменит формат пакета и отправит его не тому компьютеру. Успех преобразования ничего не говорит о праве пользователя на доступ. Значение частного номера задают административная область и маршрут; разрешение задает организация, которая отвечает за сервис.

Авторы проекта отмечают неодинаковое поведение уже работающих CLAT: одни отбрасывают частные назначения, другие их преобразуют. Численность этих групп не приведена. Оператору нужны собственные факты: какие клиенты строят адрес локально, какие PLAT отбрасывают пакеты, какой сервис стоит за каждым частным номером и в какой области маршрутизации. Без такой карты один удобный префикс превращается в универсальный ключ без подписи на дверях.

Документ пока проходит Last Call; опубликованной нормой остается RFC 6052. Но предмет решения уже понятен. Упрощение IPv6-сети ценно лишь тогда, когда оператор берет на себя определение границы, которую стандарт раньше проводил за него.

Проект IETF · RFC 6052 · RFC 1918 · RFC 6598