Кратко

  • Текущий проект V6OPS определяет IPv6-Only по фактическому нативному использованию в явно названной области, а не по установленной поддержке протоколов и не по единому состоянию всей сети.
  • IPv4 может сохраняться как IPv4aaS, через NAT64, DNS64, CLAT или SIIT-DC, а также в апстриме, управлении, контрольной плоскости и старых устройствах.
  • Проверяемая миграционная запись должна связывать ярлык с объектом, наблюдением, остаточными зависимостями, исключениями, владельцем и условием замены статуса.

Слишком большое обещание в двух словах

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

Проект рабочей группы V6OPS IPv6-Only and IPv6-Mostly Terminology Definitions пытается не дать этим разным состояниям слиться в один лозунг. Редакция 02 опубликована 11 сентября 2026 года; объявление I-D называет её рабочим документом V6OPS. Сейчас Datatracker показывает стадию Working Group Last Call. Это не утверждённый IESG документ и не окончательный RFC. История и сравнение редакций 01 и 02 подтверждают, что текст ещё может измениться.

Главная дисциплина редакции 02 — всегда называть область. Термин описывает реально используемую нативную функцию, а не все возможности устройства. Узел может поддерживать IPv4 и IPv6, но на конкретном интерфейсе нативно передавать лишь IPv6. При этом IPv4 способен пройти по той же линии в инкапсулированном или транслированном виде. Доказанный факт звучит так: «здесь нативен только IPv6». Он не равен утверждению «организация больше не зависит от IPv4».

Разница определяет и границы полномочий. Команда доступа отвечает за конфигурацию и измерения канала. Она не обязательно контролирует каждое приложение, внешний ресурс, клиентское устройство, инструмент поставщика и путь восстановления. Если при подготовке сводки исчезает существительное — канал, VLAN, плоскость данных, — утверждение охватывает системы, по которым первоначальный автор не собирал полных доказательств.

Ненативный — не значит отсутствующий

В проекте IPv6-Only означает, что в указанной области нативен только IPv6; IPv4 там не настраивается и не управляется, хотя может переноситься поверх IPv6. Более сильный термин IPv6-Only-Strict означает, что IPv4 в этой области также не транслируется, не инкапсулируется и не переносится.

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

Механизмы перехода показывают, куда перемещается функция. RFC 6877 определяет 464XLAT, сочетание трансляций для работы IPv4-приложений или сетей через IPv6-доступ. RFC 6146 задаёт stateful NAT64 между IPv6-клиентами и IPv4-серверами, а RFC 6147 — DNS64. RFC 8585 описывает требования к абонентскому маршрутизатору для вариантов IPv4-as-a-Service.

Эти механизмы сами по себе не означают провал. Они переносят совместимость в новые контрольные точки. Важнее становятся мощность транслятора, синтез DNS, журналирование, совместимость приложений, поддержка и ответственность поставщика. Снижение числа выданных IPv4-адресов может сопровождаться ростом зависимости от централизованной платформы трансляции.

В центре обработки данных RFC 7755 описывает SIIT-DC: внутренние IPv6-узлы обслуживают IPv4-клиентов через пограничные ретрансляторы. Внутреннюю LAN корректно назвать IPv6-only. Но спрос со стороны IPv4, таблицы соответствий, ресурс ретранслятора и его оператор не исчезают. Зависимость перемещена к границе.

Область входит в содержание факта

Проект различает канал доступа, сегмент, хост, сервис, API, плоскость данных, контроль и управление. В одной компании могут одновременно работать двухстековые, IPv6-only и IPv6-mostly VLAN. Мобильная сеть может доставлять к устройству только IPv6, а приложениям и режиму модема показывать двухстековую среду. Облако может использовать IPv6 в одних подсетях и частный IPv4 в других.

«Только IPv6 в плоскости данных» ничего не говорит о контроле и восстановлении. «IPv6-only сервер» не объясняет, как к нему приходят IPv4-клиенты. «IPv6-only доступ» не описывает абонентскую LAN. «IPv6-only облако» слишком широко, если его интерфейсы и подсети различаются.

Следовательно, область — не необязательная сноска, а логическая часть утверждения. После её удаления возникает новое, обычно более сильное утверждение. Если технический реестр хранит область, а отчёт руководству теряет её, это не нейтральное сокращение: вывод расширен без нового наблюдения.

Точная область защищает и сравнения. Один оператор может перевести жилой доступ на нативный IPv6 с центральным NAT64. Другая организация может создать строгий лабораторный сегмент без какого-либо переноса IPv4. Оба статуса допустимы при верной квалификации, но их цели и остаточные риски различны. Одна шкала зрелости сотрёт эти различия.

Устав V6OPS ориентирует группу на эксплуатационные рекомендации для конкретных сред — операторских, корпоративных и центров обработки данных. Общий словарь нужен для обмена опытом, а не для навязывания одной архитектуры. Это согласуется с эссе Heng Lu Minimum Initial Specification, Localized Future Decision, Voluntary Adoption: общая спецификация должна быть минимальной, а последующие решения и их пересмотр должны оставаться у локальных участников.

«Преимущественно» — не доля трафика

IPv6-Mostly в проекте не означает, что IPv6 превысил некоторый процент. Это двухстековая область с NAT64 и DHCPv4 option 108, возможно с DNS64, где совместно работают IPv4-only, Dual Stack и IPv6-only клиенты. IPv4 предоставляется по запросу.

RFC 8925 определяет обмен. Способный клиент запрашивает option 108. Получив корректное значение, он может отказаться от предложенного IPv4-адреса и остановить DHCPv4 на указанный срок или до нового события подключения. Способность относится к интерфейсу; устройство не получает вечный статус IPv6-only.

Число IPv4-аренд измеряет распределение адресов, а не все зависимости. Нативные пакеты измеряют канал, а не транслятор. Перечень NAT64 измеряет инфраструктуру, а не работоспособность приложений. Проверка целей измеряет результат, а не аварийное управление. Каждый показатель полезен, пока не выдаётся за ответ на другой вопрос.

Реестр области и зависимостей

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

  1. точный сервис, класс интерфейсов, канал, VLAN, группу приложений, плоскость или сеть;
  2. выбранный термин и версию словаря;
  3. состояние нативной передачи и метод наблюдения;
  4. период действия или релиз конфигурации;
  5. остаточный перенос, трансляцию, инкапсуляцию, адресацию и внешнюю достижимость IPv4;
  6. необходимые NAT64, DNS64, CLAT, SIIT-DC, прокси или CDN;
  7. исключения для старых устройств, приложений, контроля, поставщиков и аварийных процедур;
  8. владельца каждой зависимости и роль, уполномоченную изменить ярлык;
  9. ожидаемый отказ и путь отката;
  10. доказательство следующего состояния, решение и дату замены записи.

Это реестр, не сертификат. Сертификат намекает на всеобщую завершённость. Реестр хранит ограниченные, датированные и исправимые решения. Эксплуатация может видеть упрощение, безопасность — концентрацию риска, финансы — экономию адресов, продукт — поддержку старых клиентов. Центральному органу не нужно унифицировать оценки; достаточно сохранить общую фактическую границу.

В The Policy Mirror Heng Lu требует, чтобы политика отражала реальные системы и стимулы. Публичная награда за «завершение» заметна, а работа по поддержке совместимости — нет. Чем ценнее становится ярлык, тем важнее узкая область, в которой он правдив.

Чего источники не доказывают

Открытые материалы не показывают, что конкретный оператор вводит публику в заблуждение. Они не измеряют распространённость, производительность или стоимость решений. Working Group Last Call может изменить текст, а возможный будущий информационный RFC не сертифицирует отдельную сеть.

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

IPv6-only доступ может быть важным достижением и одновременно оставаться только доступом. Хранить обе истины в одной записи — значит превращать технический прогресс в управляемое доказательство.

Источники