Кратко

  • RFC 9868 создаёт область опций после данных, граница которых объявлена UDP Length. Дополнительные байты — конверт расширения, а не переосмысленный текст приложения.
  • При неудачной проверке опций обычно отбрасывается конверт, а проверенные данные UDP сохраняют доставку. Более строгий отказ требует явной политики приложения или библиотеки.

Сила UDP во многом в том, что он мало обещает. Заголовок содержит порты, контрольную сумму и длину, но не создаёт сеанс, не удостоверяет удалённую сторону и не доказывает прикладной результат. Опубликованный в октябре 2025 года RFC 9868 использует уже существующее свойство: UDP Length может завершаться до конца полезной нагрузки IP. Остаток документ называет surplus area и отводит под транспортные опции.

Положение байтов задаёт границу полномочий. Они не попадают внутрь сообщения приложения, и их наличие не доказывает согласия приложения на новую семантику. UDP Length по-прежнему завершает пользовательские данные; у остатка собственные правила разбора и целостности. RFC называет механизм мягкой плоскостью управления, но подчёркивает, что UDP остаётся без состояния и однонаправленным, а опции являются каркасом, не законченным протоколом.

SAFE-опцию получатель, который её не понимает, может проигнорировать без изменения данных UDP или их значения. Получатель с поддержкой опций молча игнорирует неизвестную либо повреждённую SAFE-опцию. UNSAFE-опции способны менять значение, поэтому ограничены: при их наличии обычные пользовательские данные UDP должны быть пустыми, а транспортная нагрузка передаётся через FRAG.

Контрольная сумма опций защищает surplus area отдельно от UDP checksum, покрывающей объявленные данные. Если проверка не проходит, получатель обязан игнорировать все опции и отбросить остаток. Пользовательские данные с корректной UDP checksum всё равно должны быть доставлены так, как если бы опций не было. Это свидетельство сбоя конверта расширения, а не автоматический приговор сообщению приложения.

Совместимость со старым поведением намеренна. Помимо фрагментов, ошибки checksum, аутентификации или расшифрования опции не должны автоматически блокировать принятый пакет. Если приложение желает иной результат, оно обязано явно переопределить правило. Транспорт может сообщить об ошибке опции; он не способен самостоятельно решить, должен ли DNS-резолвер, телеметрический приёмник или контроллер отвергнуть в остальном корректные данные.

Поэтому запись наблюдения должна раздельно хранить длины IP и UDP, виды и порядок опций, результат разбора, OCS/APC/AUTH/UENC при наличии, политику получателя и результат приложения. Пакет не доказывает личность, полномочие или успех. Вклад Touch также ограничен: профиль IETF подтверждает техническую деятельность, RFC — совместное авторство, но не контроль над каждым UDP-реализацией, middlebox или прикладной политикой.

Источники