Кратко

  • В RFC 6709 «обычное» не означает, что патч мал или в нём мало кода. Расширение можно отнести к этой категории, только если базовый протокол и уже развернутые реализации могут без вреда его игнорировать. Если существующее ПО приходится менять, изменение может быть крупным, даже когда формат передачи почти не изменился.
  • Такая классификация не отменяет экспертную проверку. RFC 6709 рекомендует редко использовать процедуры с минимальной проверкой или без неё и указывает, что экспертное мнение полезно даже для обычных расширений. RFC 4775 объясняет, почему новые атрибуты RADIUS следует обсуждать с учётом архитектуры протокола и сложившегося применения.

Одно слово не должно подменять два решения

При оценке протокола легко смешать два вопроса. Как расширение повлияет на протокол и на системы, которые уже его используют? Какая проверка нужна предложению, прежде чем на него начнут полагаться другие? Слово «обычное» будто отвечает сразу на оба. RFC 6709 показывает, почему это не так.

Internet Architecture Board (IAB) опубликовал RFC 6709 как документ Informational в сентябре 2012 года. Он адресован разработчикам базовых протоколов и расширений. В документе сказано, что расширяемость помогает вводить изменения постепенно, но также может создавать проблемы совместимости, эксплуатации и безопасности. Различие между обычными и крупными расширениями связывает возможное воздействие предложения с необходимой глубиной проверки. Это архитектурные рекомендации, а не Internet Standard и не универсальное правило утверждения.

RFC 6709 помещает свою работу в более долгую дискуссию. В нём упомянут RFC 1263 — меморандум 1991 года «TCP Extensions Considered Harmful» — как предыдущее предупреждение о цене расширений. У этого документа собственный исторический спор: RFC 6709 не возвращается к дискуссии о границе версий TCP. Он говорит, что общие соображения по проектированию расширений прежде не были собраны вместе. RFC 4775, опубликованный в 2006 году как BCP 125, описывал процедуры расширения протоколов IETF. RFC 6709 стремился явно сформулировать архитектурный критерий, которым следует руководствоваться в такой работе.

Крупное изменение определяется последствиями, а не размером пакета

RFC 6709 предлагает проверить восемь типов воздействия. Нужно ли менять реализацию базового протокола? Меняет ли предложение архитектурные предположения — например, вводит ли состояние сеанса в протокол, изначально рассчитанный на отсутствие такого состояния? Создаёт ли новый сценарий или масштаб использования, способный увеличить трафик, размер пакетов или нагрузку выше возможностей действующих систем? Соответствует ли расширение модели, предусмотренной базовым протоколом? Меняет ли оно синтаксис, связывает ли изменения нескольких протоколов, затрагивает ли модель безопасности или производительность существующих развёртываний?

Любой из этих факторов может сделать изменение крупным. Новый тип сообщения или транспорт может потребовать обновления даже от уже работающих реализаций, которым новая функция не нужна. Байты на линии могут остаться прежними, а новая нагрузка — превысить возможности старых алгоритмов. Если базовый протокол не задаёт единообразную и безопасную обработку неизвестных расширений, даже на вид небольшое предложение может автоматически попасть в категорию крупных. Это критерии проектирования из RFC 6709, а не числовая оценка и не заключение о каком-либо современном продукте.

Главный вопрос — кому придётся меняться и что произойдёт с теми, кто этого не сделает. Размер исправления кода — плохая замена такому анализу. Короткое поле может изменить разбор сообщения; более длинное значение производителя может остаться невидимым для базового протокола. По критериям RFC 6709 первый случай может быть крупным, а второй — обычным, но только при выполнении реальных условий совместимости.

У «обычного» расширения была строгая граница

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

RFC 6709 приводит в пример DHCP-опции для конкретных производителей, RADIUS Vendor-Specific Attributes, корпоративные идентификаторы объектов для MIB-модулей и MIME-типы производителей. Важно не то, что дополнения малы. Важно, что они занимают предусмотренное протоколом место расширения, не меняя требуемое поведение систем, которые в нём не участвуют.

Тот же раздел не позволяет читать слово «обычное» слишком вольно. RFC 6709 рекомендует редко использовать механизмы почти без проверки или без неё, например распределение по принципу First Come First Served. Такие механизмы следует оставлять для случаев с низким риском проблем совместимости, безопасности и эксплуатации. Документ также указывает, что экспертная проверка может быть полезна и для обычных расширений: непрозрачная для DHCP, но вовсе не структурированная опция может без необходимости усложнить работу клиентов и серверов.

RADIUS показывает, почему классификацию и проверку надо разделять

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

При этом RFC 6709 называет атрибуты RADIUS Vendor-Specific примером обычной расширяемости. Противоречия нет: документы отвечают на разные вопросы. «Обычное» проверяет, вписывается ли расширение в архитектуру и могут ли системы, не использующие его, безопасно игнорировать его. RFC 4775 спрашивает, какие процедуры и знания должны сопровождать предложение. RFC 6709 прямо допускает экспертную проверку даже после того, как расширение прошло критерий обычности.

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

Нужны три свидетельства, а не одна метка

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

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

RFC 6709 также не рекомендует закладывать в протокол больше расширяемости, чем разумно нужно в начале. Будущие способы применения могут быть неизвестны, но это не обязывает изначальный проект предугадывать любой возможный спрос. Следует предусмотреть безопасное место для изменений, не притворяясь, будто туда поместится любое последующее применение.

Что документы подтверждают — и чего не подтверждают

RFC 6709 фиксирует рекомендации IAB по проектированию, но не является эмпирической переписью реализаций. RFC 4775 описывает процедуры, но не доказывает, что каждое предложение им следовало. Источники подтверждают критерии и предостережения, изложенные в документах. Они не показывают, сколько расширений было развёрнуто, приняла ли конкретная сеть одно из них или вызвало ли определённое расширение инцидент.

Записка Heng Lu Note 64 предлагает другую редакционную оптику: задавать лишь общие правила, необходимые для совместимости, по возможности оставлять будущие решения участникам и считать изменение реальным в эксплуатации после его реализации и принятия. Это более поздняя аналитическая рамка BTW, а не изложение намерений IAB. В таком прочтении «обычное» описывает границу совместимости; публикация, регистрация или итог проверки не доказывают принятия.

Историческая ценность RFC 6709 — в вопросе, от которого трудно уйти: могут ли старые системы без вреда игнорировать расширение или от них требуют измениться? Когда ответ ясен, глубину проверки можно выбрать осознанно. «Обычное» не означает безопасное по умолчанию, а «крупное» не означает много строк кода.

Источники