Кратко

  • IPv4 как услуга не устраняет зависимость от IPv4, а переносит её в DNS64, обнаружение префикса, CLAT, состояние PLAT и общие порты.
  • Нативный IPv6 может работать, когда отказывают только IPv4-имена, буквальные адреса или уже открытые транслируемые сеансы.
  • Операционное доказательство должно связывать резолвер, Pref64, путь CLAT, состояние и переключение PLAT, временную атрибуцию и ограничения входящего доступа.

Абонент меняет DNS на домашнем маршрутизаторе. Сервисы с нативным IPv6 продолжают открываться. Узел, публикующий только A-запись, больше не получает синтетический AAAA и исчезает. На другом устройстве он доступен: CLAT принимает IPv4-пакет и узнаёт префикс трансляции иным способом. Оба подключения показывают «онлайн», но их совместимость собрана по-разному.

Так выглядит операционная сторона IPv4-as-a-Service, или IPv4aaS. Оператор может убрать нативный IPv4 из доступа или ядра и сохранить связь с IPv4-серверами через трансляцию. Совместимость перестаёт быть адресом, выданным одному абоненту от края до края, и становится результатом работы резолвера, устройства, домашнего шлюза, маршрутизации и операторского транслятора.

Синтетический адрес обещает маршрут

RFC 6147 определяет DNS64. Если запрос AAAA находит только A-запись, DNS64 может встроить IPv4-адрес в префикс IPv6 Pref64::/n и вернуть синтетический AAAA. Клиент отправляет IPv6-пакет к этому представлению.

Префикс должен вести к NAT64 с тем же правилом преобразования. Резолвер и транслятор не согласуют его заново для каждого запроса. Успешный DNS доказывает синтез, но не ёмкость PLAT, совпадение префиксов или сохранение сеанса.

DNSSEC обнажает границу: синтез меняет ответ, а DNSSEC выявляет несанкционированные изменения. Проверка и синтез совместимы при осознанном размещении. В квитанции нужны резолвер, наборы A/AAAA, результат DNSSEC и фактический Pref64.

CLAT спасает буквальные адреса, но не восстанавливает весь IPv4

RFC 6877 описывает 464XLAT. Не хранящий состояние CLAT на устройстве или клиентском маршрутизаторе переводит IPv4 в IPv6. Операторский PLAT с состоянием возвращает трафик в IPv4. Приложение с именем может использовать DNS64 и одну трансляцию с состоянием; буквальному IPv4 или старому API нужен CLAT как первый шаг.

Поэтому смена резолвера даёт разные симптомы. RFC 8683 объясняет: NAT64 без CLAT может потерять IPv4-only-узлы, если внешний DNS не синтезирует адреса. 464XLAT может работать без DNS64, если CLAT узнает правильный Pref64. Но если резолвер синтезирует иной префикс, пакет не попадёт к нужному PLAT.

464XLAT не заменяет полный нативный IPv4. Базовая модель RFC 6877 — клиент к серверу с глобальным IPv4. Она сама по себе не предоставляет универсальный входящий IPv4 или любой peer-to-peer. Эти ограничения должны быть частью продукта и поддержки.

Pref64 имеет область и срок жизни

RFC 8781 задаёт опцию PREF64 в объявлениях IPv6-маршрутизатора. В ней есть длина префикса и срок; ноль означает прекращение использования. Хост должен связывать префикс с интерфейсом и, если поддерживается, с Provisioning Domain. Маршрутизаторам следует обнаруживать и журналировать несовместимые объявления на одном канале.

Поэтому запись «Pref64 известен» недостаточна. Нужны метод обнаружения, значение, оставшийся срок, интерфейс или PvD и согласованность объявлений. Старый префикс может пережить выведенный транслятор, а короткий срок — закончиться раньше следующего полезного объявления.

Переключение устройства не равно переносу состояния

RFC 6146 определяет NAT64 с состоянием. PLAT хранит привязки и сеансы, чтобы обратный пакет нашёл IPv6-клиента. Ресурсы для фрагментов должны быть ограничены. Но RFC не заставляет два транслятора автоматически делиться активными сеансами.

После переключения новые соединения могут работать, а прежняя загрузка, платёж или туннель — оборваться. Проверка, открывающая новый TCP после события, объявит восстановление. Настоящий тест проводит один сеанс через переключение и фиксирует активный PLAT, запас состояния, событие и ожидаемую судьбу существующих привязок.

RFC 9099 добавляет угрозу исчерпания состояния, взаимодействие DNS64 с DNSSEC и проблемы большинства сценариев IPsec без UDP-инкапсуляции. 464XLAT без DNS64 убирает синтез, но не остальные границы.

Экономия адресов переносит учёт

RFC 9313 сравнивает пять технологий IPv4aaS. В 464XLAT операторский NAT64 хранит состояние потоков и динамически выдаёт публичные порты. Это эффективно делит IPv4, но концентрирует ёмкость, восстановление и журналирование.

Если публичный адрес общий, привязка адреса и порта к абоненту требует точного времени. Запись каждого сеанса подробна и дорога. Выдача блока портов на период уменьшает журнал и снижает эффективность пула. Влияет и право; RFC не задаёт мирового срока хранения.

Состояние у оператора также не выдаёт клиенту публичный входящий порт. Серверу могут понадобиться PCP или явное отображение. Это архитектурное ограничение, а не загадочная неисправность.

Источники не устанавливают мировую долю использования в 2026 году, универсальный выигрыш или обычную частоту отказов. Они задают проверяемую цепочку управления.

Источники

  1. RFC 6146 — Stateful NAT64
  2. RFC 6147 — DNS64
  3. RFC 6877 — 464XLAT
  4. RFC 8683 — развёртывание NAT64/464XLAT
  5. RFC 8781 — обнаружение PREF64
  6. RFC 9099 — операционная безопасность IPv6
  7. RFC 9313 — технологии IPv4aaS