Кратко

  • RFC 5211 предложил этапы подготовки, перехода и период с января 2012 года, когда связность должна была стать преимущественно IPv6. Сам документ называл себя одним информационным планом и не создавал обязательств.
  • Дата и слово MUST уточняют намерение. Они не подтверждают, что IPv6 можно заказать, что он подключён, имеет обратный путь, выбран приложением, несёт трафик или позволяет завершить услугу.

Рубеж плана и состояние системы

RFC 5211 вышел в июле 2008 года и попытался согласовать действия множества независимых участников. Подготовка продолжалась бы до конца 2009-го, переход — в 2010–2011 годах, а после перехода система жила бы с января 2012-го. Провайдеры двигались бы от пилота к производству, организации добавляли бы IPv6 к публичным серверам.

Документ точно обозначил пределы. Это был «один возможный план»; допускались иные. Он не налагал обязанностей. Термины RFC 2119 использовались лишь для однозначного описания предложения. В примечании IESG сказано: RFC не претендует ни на один уровень интернет-стандарта и не опубликован по результатам обычной технической проверки консенсуса IETF.

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

Предложение услуги состоит из доказательств

TRANS1 и POST1 требуют в рамках плана предлагать интернет-доступ IPv6. Для проверки нужно развернуть глагол: продукт в каталоге, рынок, тип доступа, квалификация, принятый заказ, префикс, клиентское устройство, прямой и обратный маршруты, DNS, мониторинг и поддержка.

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

Запись AAAA подтверждает публикацию в DNS, но не результат приложения. Разрешение имени, выбор пути, соединение, транзакция и устойчивость имеют разные квитанции. Успех из одной точки не описывает всех пользователей и все интервалы. Для слова «преимущественно» необходимы метрика, знаменатель и период.

MUST не назначил контролёра

RFC 5211 применил MUST, SHOULD и MAY, чтобы чётко изложить план, но прямо отрицал создание обязательства. Общего аудитора, теста, совокупности объектов и санкции в нём нет.

Искажение возникает при переносе. Фраза «провайдеры MUST предлагать» проходит через закупочную таблицу и превращается в «Интернет завершил переход». Исчезают провайдер, продукт, территория, клиент, время и проверяющий; остаётся только сильное слово.

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

POST4 сохранял IPv4

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

Поэтому последующие RFC отдельно описывают dual stack, трансляцию, клиентские маршрутизаторы, контент, предприятия, безопасность и IPv4-as-a-Service. IPv6-only ядро, IPv4aaS, публичный dual-stack и старое IPv4-приложение могут жить в одной организации и находиться на разных этапах.

Слишком раннее удаление IPv4 обрывает скрытую зависимость. Бессрочное сохранение фиксирует расходы и поверхность атаки. Год в плане не решает этот конфликт.

Новый RFC не является журналом внедрения

RFC 6144 отметил в 2011 году, что исчерпание адресов IPv4 может наступить раньше значимого распространения IPv6. RFC 6180 ожидал длинный хвост перехода. RFC 6540 позже сделал поддержку IPv6 лучшей текущей практикой для IP-узлов. Отдельные документы детализировали контент, клиентское оборудование и корпоративные сети.

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

Цепочка, переживающая диаграмму

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

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

У срока остаётся правильная функция: запустить пересмотр. Если наблюдения расходятся с планом, исправляют план, а не название реальности.

Источники

  1. Сведения о RFC 5211
  2. RFC 5211 в HTML
  3. Текст RFC 5211
  4. IETF Datatracker: RFC 5211
  5. История RFC 5211
  6. Ссылки RFC 5211
  7. Исправления RFC 5211
  8. RFC 3932 — независимые публикации
  9. RFC 2119 — слова требований
  10. RFC 8174 — обновление BCP 14
  11. RFC 6144 — трансляция IPv4/IPv6
  12. RFC 6180 — руководство по переходу
  13. RFC 6540 — обязательная поддержка IPv6
  14. RFC 6589 — перевод контента
  15. RFC 7084 — требования к клиентской границе
  16. RFC 7381 — корпоративное внедрение
  17. RFC 8170 — сценарии внедрения
  18. RFC 9099 — операционная безопасность IPv6
  19. RFC 9313 — технологии IPv4-as-a-Service
  20. Heng Lu — уровни реальности и символическая власть
  21. Heng Lu — минимальная исходная спецификация
  22. Heng Lu — первичность работающего кода