Кратко

  • В редакции -03 от 29 сентября проект IETF по испытанию приложений для IPv6 уточняет раздел 3.7: внутренние потоки обычно независимы, пока адреса конечных точек не передаются внутри самого протокола. В -02 этой оговорки не было.
  • В раздел 3.6 явно включены обычные действия пользователя, а пояснение к таблице сценариев сообщает, что сети только с IPv4 не делятся на варианты с NAT и без него. Документ остаётся рабочим Internet-Draft на стадии WG Last Call, а не утверждённым RFC.

Успешное соединение часто принимают за короткий ответ на вопрос о готовности приложения к IPv6. Между тем приложение может получить в первом соединении сообщение с адресом, а затем открыть по этому адресу второе. Если оба соединения проходили испытание порознь, их связка всё ещё может оставаться непроверенной. Это мысленный пример для проектирования теста, не сообщение о конкретном сбое или поставщике.

Проект Testing Applications for IPv6 Readiness предлагает рассматривать приложение как набор потоков данных. Такой подход уменьшает объём работы: не нужно без разбора перемножать все варианты сети со всеми сочетаниями внутренних путей. В новой версии раздел 3.7 сохраняет этот подход, но называет его предпосылку. Потоки, как правило, независимы, если протокол не сигнализирует конечные точки внутри сообщений. Когда адрес для последующего соединения путешествует по первому потоку, независимость требуется проверить, а не объявить по схеме сети. При этом текст не требует полного декартова произведения тестов для каждого приложения. Он предлагает не применять экономию вслепую.

В разделе 3.6 меняется масштаб проверки пользовательского интерфейса: туда прямо входят обычные операции приложения, после чего отдельно оговаривается связь интерфейсов, не построенных на вебе. Установка, повседневные действия, администрирование и журналы, обновление — разные поводы для сетевого обмена. Один успешный вход или открытие главной страницы не показывают, какими адресами пользуются остальные функции. В проекте нет утверждения, что какой-либо развернутый продукт провалил такие проверки; речь идёт о том, что именно считать предметом испытания.

Раздел 3.1 предупреждает и о неверном чтении таблицы сетевых условий. В ней не выделены два вида сети только с IPv4 — с NAT и без NAT. Некоторые приложения предполагают наличие NAT и могут не работать при его отсутствии; авторы пишут, что описанные сценарии IPv6 помогают выявить подобные трудности. Вопросы MTU для 464XLAT и IPv6-Mostly отнесены к разделу 3.4. Это не обещание, что один запуск в лаборатории покрывает все сочетания NAT и размеров пакета. В отчёте важны реальные условия, а не воображаемая полнота таблицы.

Для выпуска достаточно компактной карты: какие операции вызывают каждый поток, откуда приходит адрес назначения, на какой версии приложения и в какой сети получен результат. Адрес может быть задан настройкой, найден автоматически или получен в сообщении другого протокола. В последнем случае следует отдельно проверить связь потоков. Это предлагаемая здесь дисциплина приёмки, а не обязательная форма IETF. Она позволяет сохранить раздельные испытания там, где для них есть основания, и добавить точечные проверки там, где предпосылка перестаёт действовать.

Процесс стандартизации следует отделять от инженерного вывода. Datatracker показывает рабочий проект группы в состоянии WG Last Call. Первоначальный сбор отзывов был объявлен на 4–18 сентября; председатель продлил его на неделю, пока авторы отвечали на замечания. Из этого нельзя заключить, что последний раунд обсуждения завершён или стандарт утверждён. Новость состоит в изменении текста -03: условие независимости и охват обычной работы приложения теперь выражены точнее.

Источники