Рабочая группа сети T. Narten
Запрос комментариев: 3692 IBM
BCP: 82 Январь 2004
Обновляет: 2434
Категория: Лучшая современная практика
Выделение экспериментальных и тестовых номеров, признанных полезными
Статус этого меморандума
Этот документ устанавливает Лучшую современную практику Интернета для
Интернет-сообщества и запрашивает обсуждение и предложения по
улучшению. Распространение этого меморандума не ограничено.
Уведомление об авторских правах
Copyright (C) The Internet Society (2004). All Rights Reserved.
Аннотация
При экспериментировании с протоколами или их расширении часто необходимо
использовать некоторый номер протокола или константу, чтобы фактически
тестировать или экспериментировать с новой функцией, даже при тестировании
в закрытой среде. Например, для тестирования новой опции DHCP нужен номер
опции для идентификации новой функции. Этот документ рекомендует, чтобы при
написании разделов IANA Considerations авторы рассматривали возможность
выделения небольшого диапазона номеров для экспериментальных целей, который
реализаторы могут использовать при тестировании расширений протоколов или
других новых возможностей. Этот документ резервирует некоторые диапазоны
номеров для экспериментальных целей в конкретных протоколах, для которых
выявлена необходимость поддержки экспериментирования.
1. Введение
При экспериментировании с протоколами или их расширении часто необходимо
иметь номер протокола как часть реализации [RFC2434]. Например, для
разработки протокола, работающего непосредственно над IP, нужен номер IP
Protocol, помещаемый в поле Protocol заголовка IP [RFC791]. В некоторых
случаях получение нового номера не представляет сложности (например,
общеизвестный порт TCP или UDP) либо вообще не требуется (например, номера
портов TCP и UDP для целей тестирования). В других случаях получить номер
сложнее. Например, число доступных и неназначенных значений в пространстве
имён может быть настолько малым, что есть опасение: при неосторожном
назначении все доступные номера будут исчерпаны. Даже в случаях, когда
номеров потенциально много, назначение номеров может быть нежелательным,
если предлагаемое использование не было надлежащим образом рассмотрено
более широким сообществом. Поэтому некоторые пространства номеров
устанавливают, что IANA делает назначения только в случаях, когда
предлагаемый протокол имеет сильную поддержку сообщества. Например,
значения из некоторых пространств имён назначаются только посредством
«IETF Standards Action» [RFC2434], что требует, чтобы предполагаемое
использование было описано в RFC IETF Standards Track.
Для эксперимента с новым протоколом может потребоваться экспериментальное
значение, которое не будет конфликтовать с существующим или будущим
использованием.
Один из подходов заключается в том, чтобы разрешить IANA делать временные
назначения для таких целей. Идея состоит в том, что значение протокола
может быть назначено для проведения эксперимента, но после завершения
эксперимента номер был бы возвращён IANA. Однако этот подход имеет несколько
недостатков. Во-первых, опыт показал, что после назначения номера может
быть трудно вернуть. Например, контактная информация устаревает, и может
стать трудно выяснить, каков фактический статус эксперимента. Во-вторых,
если происходит развёртывание с временно назначенным номером (например, он
включён в состав продукта), становится очень трудно определить, приведёт ли
повторное использование этого номера к неблагоприятному воздействию на уже
развёрнутые устройства. Наконец, может быть трудно определить, когда
эксперимент завершился и нужно ли вернуть номер.
Альтернативный подход, рекомендуемый в этом документе, состоит в выделении
диапазона номеров, специально предназначенных для целей тестирования и
экспериментирования. Устройства, взаимно согласившиеся на это, могли бы
использовать эти номера для любых желаемых целей, но с пониманием, что они
зарезервированы для общих целей тестирования и другие реализации могут
использовать те же номера для иных экспериментальных применений.
Номера в диапазоне для экспериментирования подобны тем, которые в RFC 2434
[IANA-CONSIDERATIONS] называются «Private Use». Они не предназначены для
использования в общих развёртываниях или для включения по умолчанию в
продуктах либо иных общедоступных выпусках. В тех случаях, когда продукт или
выпуск использует экспериментальный номер, от конечного пользователя должно
требоваться явное включение экспериментальной возможности, а также должна
быть возможность выбирать и назначать, какой номер из экспериментального
диапазона будет использоваться для конкретной цели (то есть чтобы конечный
пользователь мог обеспечить, что использование конкретного номера не
конфликтует с другими продолжающимися применениями). Поставка продукта с
предварительно включённым конкретным значением была бы неуместна и может
приводить к проблемам совместимости, когда выбранное значение конфликтует с
другим применением, как это когда-нибудь наверняка произойдёт.
Из сказанного выше следует, что группе поставщиков, консорциуму или другой
Организации по разработке стандартов было бы неуместно договориться между
собой использовать конкретное значение для определённой цели, а затем
договориться развёртывать устройства, использующие эти значения. По
определению экспериментальные номера не гарантируются как уникальные ни в
какой среде, кроме той, в которой локальный системный администратор выбрал
использовать конкретный номер для конкретной цели и может обеспечить, что
конкретное значение ещё не используется для какой-либо другой цели.
После того как расширение протестировано и признано полезным, постоянный
номер можно было бы получить через обычные процедуры назначения.
Большинство реализаций не будет делать ничего особенного с номерами,
назначенными для целей тестирования. В частности, если пакет или другая
единица данных протокола (PDU) специально не направлена устройству, это
устройство даже не будет просматривать это поле при обработке PDU.
Например, IP-маршрутизаторам не требуется исследовать или понимать поле
Protocol Type IP-дейтаграмм, чтобы знать, как правильно их пересылать. В тех
случаях, когда пакет или PDU направлен устройству и это устройство не было
настроено на распознавание расширения, устройство либо проигнорирует PDU,
либо отбросит его, либо сообщит об ошибке — в зависимости от
протокольно-специфичных правил, указывающих, как обрабатывать неизвестные
опции или возможности. В тех случаях, когда протокол предусматривает разные
способы обработки нераспознанных расширений (например, молча отбросить или
сообщить об ошибке), этому протоколу необходимо резервировать значения для
целей тестирования из всех соответствующих диапазонов. Только те реализации,
которые специально включены или настроены для использования расширения или
возможности, с которыми проводится эксперимент, будут обрабатывать данные
далее.
1.1. Рекомендация для протоколов
Чтобы сделать возможным безопасное экспериментирование с расширениями
протоколов, в документах протоколов следует рассматривать резервирование
небольшого набора номеров протоколов для экспериментирования. Такие
резервирования могут быть сделаны посредством явного резервирования в
разделе IANA Considerations.
Точное число значений, резервируемых для экспериментирования, будет зависеть
от конкретного протокола и факторов, специфичных для этого протокола.
Например, в случаях, когда значения поля подразделяются на диапазоны, к
которым применяется различная обработка (например, «молча игнорировать» или
«вернуть ошибку», если значение не понято), может потребоваться резервировать
одно или несколько значений из каждого поддиапазона.
Для протоколов, возвращающих коды ошибок, также может быть уместно
резервировать небольшое число экспериментальных значений ошибок, которые
могут использоваться совместно с возможными экспериментальными применениями.
Например, экспериментальное сообщение может приводить (даже при нормальных
условиях) к ошибке, при этом специальный код ошибки (или подкод) указывает
тип условия ошибки.
Во многих, если не в большинстве, случаев будет достаточно резервировать
одно значение для экспериментального использования. Хотя может возникнуть
соблазн резервировать больше, чтобы было легко тестировать много вещей
одновременно, резервирование многих значений также может усилить соблазн
для лица, использующего конкретное значение, предполагать, что определённое
экспериментальное значение можно использовать исключительно для заданной
цели. Значения, зарезервированные для экспериментального использования,
никогда не должны становиться постоянными; постоянные назначения следует
получать посредством стандартных процессов. Как описано выше,
экспериментальные номера предназначены для экспериментирования и
тестирования и не предназначены для широких или общих развёртываний.
Когда протоколы, использующие экспериментальные номера, включаются в
продукты, поставляемые версии продуктов должны по умолчанию отключать
распознавание экспериментальных номеров протокола — то есть конечный
пользователь продукта должен явно «включить» экспериментальную
функциональность протокола. В большинстве случаев реализация продукта должна
требовать от конечного пользователя явной настройки значения до включения
его использования. Если продукт не имеет пользовательского интерфейса для
такой настройки конечным пользователем, продукт должен требовать явного
перепрограммирования (например, специальной загрузки встроенного ПО или
установки карты возможности), чтобы неявно настроить экспериментальный
номер(а) протокола(ов).
2. Соображения IANA
2.1. Поле IP Protocol
Назначение новых значений для поля IP Protocol требует IETF Standards Action
согласно [RFC2780]. Для целей экспериментирования и тестирования IANA
назначила для этой цели два значения: 253 и 254. Эти значения были выделены
из верхней части доступного пространства номеров, чтобы их было легко
идентифицировать благодаря их заметному отличию от уже произведённых
назначений.
2.2. Существующие пространства имён
Существует множество пространств имён, для которых не зарезервированы
значения для целей экспериментирования или тестирования. Экспериментальные
значения для таких протоколов, разумеется, могут назначаться обычным
процессом публикации RFC, документирующего подробности такого выделения.
Чтобы упростить процесс в тех случаях, когда публикация документации только
для назначения экспериментального выделения представляется чрезмерной,
экспериментальные значения могут быть назначены через IESG Approval
[RFC2434].
3. Соображения безопасности
Этот документ не имеет известных последствий для безопасности.
4. Благодарности
Улучшения в этот документ были внесены в результате конкретной обратной
связи от Steve Bellovin, Scott Bradner, Randy Bush, Bill Fenner, Steve
Hanna, Paul Hoffman, Henrik Levkowetz, John Loughney, Allison Mankin и
Richard Woundy.
5. Ссылки
5.1. Нормативные ссылки
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For
Values In the Internet Protocol and Related Headers", BCP
37, RFC 2780, March 2000.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
Thomas Narten
IBM Corporation
P.O. Box 12195
Research Triangle Park, NC 27709-2195
USA
Phone: +1 919 254 7798
EMail: narten@us.ibm.com
7. Полное заявление об авторских правах
Copyright (C) The Internet Society (2004). All Rights Reserved.
Этот документ и его переводы могут копироваться и предоставляться
другим лицам, а производные работы, содержащие комментарии к нему,
иным образом объясняющие его или содействующие его реализации, могут
подготавливаться, копироваться, публиковаться и распространяться
полностью или частично без каких-либо ограничений при условии, что
приведённое выше уведомление об авторском праве и настоящий абзац
включены во все такие копии и производные работы. Однако сам этот
документ не может быть каким-либо образом изменён, например путём
удаления уведомления об авторском праве или ссылок на Internet Society
либо другие интернет-организации, за исключением случаев, когда это
необходимо для разработки интернет-стандартов, при которой должны
соблюдаться процедуры в отношении авторских прав, определённые
процессом Internet Standards, либо когда это требуется для его
перевода на языки, отличные от английского.
Предоставленные выше ограниченные разрешения являются бессрочными и
не будут отозваны Internet Society или её правопреемниками либо
лицами, которым она передала права.
Этот документ и содержащаяся в нём информация предоставляются на
условиях «КАК ЕСТЬ», И INTERNET SOCIETY И INTERNET ENGINEERING TASK
FORCE ОТКАЗЫВАЮТСЯ ОТ ВСЕХ ЯВНЫХ И ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ,
ВКЛЮЧАЯ, ПОМИМО ПРОЧЕГО, ЛЮБУЮ ГАРАНТИЮ ТОГО, ЧТО ИСПОЛЬЗОВАНИЕ
СОДЕРЖАЩЕЙСЯ ЗДЕСЬ ИНФОРМАЦИИ НЕ НАРУШИТ КАКИХ-ЛИБО ПРАВ, А ТАКЖЕ
ЛЮБЫЕ ПОДРАЗУМЕВАЕМЫЕ ГАРАНТИИ ТОВАРНОЙ ПРИГОДНОСТИ ИЛИ ПРИГОДНОСТИ
ДЛЯ ОПРЕДЕЛЁННОЙ ЦЕЛИ.
Благодарность
Финансирование функции RFC Editor в настоящее время предоставляется
Internet Society.