Кратко

  • IESG одобрила редакцию 16 спецификации Stateful NAT64 как Internet Standard; при этом утверждённый текст прямо отделяет поведение отображения от входной фильтрации.
  • Оператору нужен раздельный отчёт о внешнем кортеже и о допущенных источниках, привязанный к протоколу, направлению, версии правил и положительным и отрицательным тестам.

В протоколе приёмки есть убедительная последовательность. Один адрес и порт IPv6 открывают соединения к разным адресам IPv4. Пока действует привязка, транслятор выдаёт им один и тот же внешний адрес и порт IPv4. Проверка корректно подтверждает отображение, независимое от конечной точки.

Ошибку добавляет следующая строка: «посторонний обратный трафик заблокирован». Из постороннего источника пакеты не отправляли. Действие по умолчанию не читали. Установленные правила не сохранили. Свойство распределения кортежей без испытания объявили свойством допуска.

4 сентября 2026 года IESG одобрила редакцию 16 документа Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers как Internet Standard и попросила RFC Editor включить его в STD 103. В сообщении сказано, что Stateful NAT64 широко реализован и развёрнут, новый текст заменит RFC 6146, а крупного разногласия рабочая группа не выявила.

Одобрение ещё не означает публикацию нового RFC. На момент исследования Datatracker показывал редакцию 16 в очереди RFC Editor; выпуск был заблокирован ожиданием ответа авторов. История документа подтверждает пройденные этапы, но не создаёт окончательный номер раньше редактора.

Не появилось и внезапно нового поведения протокола. В объявлении исправления errata 4756 и 8416 названы редакционными или поясняющими, без влияния на совместимость. Приложение A редакции 16 говорит, что у них нет протокольных последствий. RFC 6146 остаётся исторической основой до выхода преемника. Повод для анализа — не новая функция межсетевого экрана, а старая граница, которую эксплуатационные отчёты часто стирают.

Отображение выбирает внешний кортеж

Stateful NAT64 хранит базы привязок и таблицы сеансов. Для TCP и UDP транспортный адрес состоит из IP-адреса и порта. Внутренний транспортный адрес IPv6 получает внешний транспортный адрес IPv4; после простоя и истечения таймера динамическую привязку можно освободить.

При отображении, независимом от конечной точки, один внутренний адрес и порт получают один внешний кортеж при обращении к разным назначениям в пределах времени жизни привязки. RFC 4787 требует это для UDP NAT, чтобы поддержать прозрачность приложений и обход NAT. Там же подчёркнуто: варианты отображения не определяют свойства безопасности. Их определяет то, какие пакеты пропускает фильтр.

RFC 5382 переносит разделение на TCP. Приложение может узнать предсказуемый внешний кортеж и сообщить его партнёру, но входящее соединение всё равно подчиняется политике NAT. Тест отображения отвечает на вопрос о представлении внутренней стороны, а не о полномочиях внешней.

Одобренный текст требует поддержки endpoint-independent mapping и допускает дополнительное address-dependent mapping. Это сведения о возможностях. Даже выбранный режим отображения не раскрывает режим фильтра на конкретном интерфейсе.

Фильтр решает, кто воспользуется состоянием

Редакция 16 сопоставляет два случая. Если привязка существует, а фильтрации нет, пакет любого узла IPv4, направленный на внешний транспортный адрес, может пройти через NAT64 к связанному адресу IPv6. Доступ появляется из сочетания состояния и отсутствия фильтра, а не из одного названия отображения.

При том же отображении динамический фильтр, зависящий от адреса, может принимать только те источники IPv4, к которым узел IPv6 обращался ранее. Явный запрет или запрет по умолчанию отбрасывает остальные. Способ выдачи кортежа прежний, но входная поверхность стала уже.

Более узкий режим не всегда предпочтителен. RFC 4787 рекомендует endpoint-independent filtering, если важнее прозрачность приложений, и address-dependent filtering, если важнее строгость. Выбор может делать администратор. RFC 5382 позволяет фильтровать TCP не так, как UDP. Поэтому общая отметка о соответствии устройства не отвечает на вопрос о реальной политике протокола.

ICMP требует иной модели. RFC 5508 использует идентификатор запроса вместо порта. Разрешение errata 4756 уточняет, что на соответствующем этапе у ICMP нет правила address-dependent filtering, аналогичного TCP/UDP. Это не отменяет всю политику для ICMP. Это запрещает считать UDP-тест универсальным.

Статическая привязка усиливает требования к контексту

Раздел безопасности предупреждает: фильтр только по пяти параметрам иногда можно угадать при статическом отображении. Реализация вправе отслеживать номера последовательности TCP, проверяя порядок SYN и FIN, но это необязательная защита. Рабочая трансляция не доказывает, что она включена и пережила обновление.

Ресурсы транслятора конечны: адреса и порты IPv4, память привязок и сеансов, хранилище фрагментов, пропускная способность. Документ говорит об ограничении памяти для фрагментов и о правильном выборе внешнего интерфейса для некоторых механизмов времени жизни. Без направления, протокола, таймеров и происхождения состояния — статического, динамического или PCP — зелёная проверка EIM не годится для последующего разбора.

RFC 7269 описывает опыт эксплуатации NAT64, включая высокую доступность и безопасность. RFC 8683 добавляет рекомендации по NAT64/464XLAT. Они рассматривают транслятор как часть сети с маршрутами и отказами. Ни один документ не превращает повторное использование кортежа в доказательство фильтра.

Две линии доказательств в одной квитанции

Daniel Kade предлагает квитанцию решения об отображении и фильтрации. В ней указываются транслятор, версия ПО, интерфейс, направление и протокол. Отдельные поля содержат режим отображения, режим фильтрации, действие по умолчанию, статическое, динамическое или PCP-происхождение состояния, таймеры, версию политики, утвердившего, пределы ресурсов и срок исключения.

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

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

The Policy Mirror предлагает искать место, где правило получает силу: распределение кортежа и входной путь — разные места. Running-Code Primacy требует наблюдать оба. Reality, Not Advocacy ставит границу выводу: стандарт описывает варианты, но не доказывает дефект сети, которую никто не проверял.

Источники