Кратко

  • draft-ietf-v6ops-ipv6-app-testing-03 разделяет IPv4-only, dual-stack, IPv6-only с NAT64 и IPv6-only-strict без релевантного пути к IPv4. Успех в dual-stack может означать лишь успешный откат на IPv4.
  • Установка, интерфейс, управление и обновление — независимые поверхности. Защищаемое утверждение называет важные потоки, применимый сценарий, доказательство условий стенда и результаты транспорта и приложения.

Один зелёный индикатор скрыл знаменатель

Обычный пользовательский путь редко проходит весь продукт. Он может затронуть фронтенд, идентификацию и основной API, не вызывая активацию, репозиторий пакетов, телеметрию, удалённую поддержку, резервирование или восстановление. Превращая этот путь в знак «IPv6 готов», организация заставляет наблюдавшийся маршрут отвечать за маршруты, которые не запускались.

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

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

Слепое декартово произведение не требуется. Управляемая архитектура позволяет исключать неприменимые комбинации, но исключение должно иметь версию, владельца и проверяемую причину. Молчаливый пропуск — не инженерное решение.

Dual-stack может скрыть исправленный им сбой

Happy Eyeballs полезен пользователю, но меняет доказательство. IPv6 может сломаться после TCP и до TLS, а IPv4 завершит операцию. RFC 8305 сокращает задержку между кандидатами и не подтверждает проигравший путь.

DNS64 из RFC 6147, формат RFC 6052 и 464XLAT из RFC 6877 могут сделать IPv4-зависимость доступной. Это валидно в переходном сценарии и загрязняет тест IPv6-only-strict. Нужно доказать состояние CLAT, DNS64, NAT64, VPN, туннелей и реле.

Квитанция сохраняет DNS-ответы, кандидатов, выбранное семейство, попытки, время fallback, прокси или переводчик, транспортный и прикладной результаты. Последний успех без предыдущей ошибки уничтожает важнейшую находку.

Стенд тоже способен сломаться. Отключение IPv4 может оборвать управление виртуальной машиной или корпоративный вход. Здоровье стенда и продукта — разные свидетельства.

Жизненный цикл шире главного экрана

Проект выделяет установку, UI, управление и обновление. Установщик зависит от активации и пакетов; управление — от API, SNMP, syslog и мониторинга; обновление — от иных процессов, сертификатов, зеркал и отката.

Успех UI не проверяет установщик. Работа API не доказывает правильную запись IPv6-источника. Ручное обновление не обязательно проверяет автоматический агент. Отчёт следует строить по потокам и владельцам, а не по экранам.

Прокси добавляет третье плечо. IPv6 от клиента к прокси ничего не говорит о прокси к origin. TURN добавляет кандидатов; RFC 8656 определяет реле, но не полноту кампании продукта.

Повторное использование делает проверку рекурсивной. Новый AAAA общей службы может привести другие продукты по IPv6 до готовности их списков и журналов. Реестр должен быть связан с версиями и зависимостями.

Адрес — также данные и полномочие

Приложение проверяет, отображает, хранит, сравнивает адреса и принимает по ним решения. RFC 4291 задаёт архитектуру, RFC 5952 рекомендует текстовую форму, но бизнес-логика может принимать только IPv4, обрезать строку или разделять эквивалентные формы.

Списки доступа показывают границу. После публикации AAAA клиент приходит по IPv6. Если правило знает лишь IPv4, транспорт проходит, приложение отказывает. Happy Eyeballs не исправляет авторизацию после соединения.

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

Трасса доказывает только увиденное

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

Проект называет сетевую трассировку наиболее ошибочным вариантом, потому что аналитик уже должен знать схему связи. Корректно: «все потоки реестра X наблюдались по IPv6 в запуске Y». Некорректно: «скрытых зависимостей IPv4 нет».

Last Call не является производственной квитанцией

Источник — редакция 03 от 29 сентября 2026 года, срок до 2 апреля 2027 года. Datatracker показывает активный документ V6OPS, I-D Exists, WG Last Call. Заголовок предлагает Best Current Practice, поле intended-status пусто. Это не RFC и не BCP.

Документ стандартизирует вопросы, но не выполняет тесты. RFC 8504 задаёт требования к узлам, не заменяя функциональное покрытие приложения. RFC 8585 описывает корпоративные сценарии, не сертифицируя зависимость.

Running-Code Primacy сохраняет порядок: руководство, реестр, условие стенда, наблюдение, прикладной результат, производство. Ни один слой не создаёт следующий декларацией.

Источники