Кратко

  • 27 октября IESG одобрила пересмотр VXLAN для публикации в виде информационного RFC. На 2 ноября документ ещё находился в очереди RFC Editor: требовался ответ авторов, действия IANA продолжались.
  • Размер заголовка и позиции битов сохраняются. Проект предлагает зарегистрировать свободные позиции флагов и выдавать новые значения по процедуре IETF Review.

Существующий пакет VXLAN не придётся переписывать ради нового документа. Другое дело — следующий разработчик, который захочет объявить: «Этот свободный бит теперь означает мою функцию». Двенадцатая версия проекта ставит перед ним не новую длину заголовка, а новую дверь. За ней — документ IETF и регистрация значения. Старые байты остаются на месте; контроль над их будущим толкованием меняется.

В списке решений IESG указано одобрение от 27 октября 2026 года с предполагаемым статусом Informational. Datatracker по-прежнему называет версию 12 Internet-Draft. RFC Editor ожидает ответа авторов, а у IANA отмечены незавершённые действия. Одобрение редакционного пути нельзя выдавать за уже опубликованный RFC или созданный реестр.

RFC 7348 вышел в 2014 году как независимая информационная публикация. Он описал уже работавший VXLAN и зафиксировал в разделе IANA порт UDP 4789. Реестра будущих значений отдельных флаговых битов он не создавал. Новая версия переводит спецификацию в поток документов IETF, чтобы расширения заголовка получили общедоступные определения и назначения.

Технический приём аккуратен. Из 24 бит прежнего поля Reserved первые восемь переклассифицируются как дополнительные позиции флагов. Получаются 16 бит «VXLAN Flags» и 16 бит «Reserved-1». Ни одна позиция не смещается, длина заголовка не растёт. Бит 4 остаётся флагом I и указывает на наличие VNI; VTEP должен отбросить пакет с I=0. Остальные 15 позиций сначала не назначены. Отправитель выставляет ноль, получатель их игнорирует. Старое оборудование продолжает видеть прежнюю последовательность.

Раздел для IANA — место настоящего изменения. Проект просит создать группу реестров VXLAN и реестр флагов с номером бита, описанием и ссылкой на определяющий документ. Новые значения выдавались бы через IETF Review. RFC 8126 определяет эту процедуру: нужен RFC из потока IETF, прошедший через IESG. Информационный RFC подходит; частное описание продукта не закрепляет публичное значение. Проект также просит поменять контакт записи порта 4789 на IETF Chair, а владельца назначения — на IESG.

Реестр защищает от очень приземлённой аварии: двух расширений, которые требуют один и тот же ограниченный бит, но означают разное. Публичная запись позволяет увидеть конфликт и найти исходное определение. За порядок приходится платить временем. Компании, рассчитывающей на общую интерпретацию нового флага, придётся включить рассмотрение RFC в график выпуска. Частное использование бита можно начать быстрее, но оно не создаёт обязательств для чужого VTEP.

Номер в реестре не обновляет сеть. Операторы сами решат, включать ли расширение, и проверят работу старых и новых VTEP вместе. В проекте нет измерений совместимости ещё не определённых расширений. Для решения о внедрении нужны конкретный RFC, трассы пакетов в смешанной среде и поведение при отказах.

Документ 2014 года записал уже существовавший порядок. Проект 2026 года сохраняет его пакет и меняет маршрут следующего публичного изменения. Никакой торжественной замены формата — только новый хранитель ключа от оставшихся нулей.

Статус проекта · Версия 12 · Решение IESG · RFC 7348 · RFC 8126