Network Working Group J. Littlefield Request for Comments: 3925 Cisco Systems, Inc. Category: Standards Track October 2004
Опции идентификации производителя для DHCPv4
Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)
Статус документа
Этот документ задает проект стандартного протокола Internet для сообщества Internet и служит приглашение к дискуссии в целях развития и совершенствования протокола. Текущий статус стандартизации протокола можно узнать из документа Internet Official Protocol Standards (STD 1). Распространение документа не ограничивается.
Авторские права
Copyright (C) The Internet Society (2004).
Аннотация
Опции протокола DHCP1 для Vendor Class и Vendor-Specific Information могут быть ограничительными и неоднозначными, когда клиент DHCP представляет множество производителей. В этом документе определяются две новых опции, основанные на опциях IPv6 для информации класса производителя и связанной с производителем информации, которые содержат Enterprise Number для устранения неоднозначности.
Оглавление
Исключено в версии HTML.
1. Введение
Протокол DHCP для IPv4, описанный в RFC 2131 [2], определяет опции, которые позволяют клиенту указать тип производителя (опция 60), а клиенту и серверу DHCP — обменяться зависящей от производителя информацией (опция 43) [5]. Хотя не запрещена передача множества копий этих опций в одном сообщении, это может приводить к неоднозначной интерпретации особенно для в тех случаях, когда информация связана с множеством производителей. Производитель, указанный опцией 60, определяет интерпретацию опции 43, которая не содержит указания производителя. Кроме того, конкатенация множества экземпляров одной опции, требуемая RFC 2131 и описанная в RFC 3396 [4], означает, что множественные копии опций 60 или 43 не будут независимыми.
При некоторых обстоятельствах реализации может потребоваться поддержка множества независимо определенных форм фирменной информации производителей. Например, реализация, которая должна соответствовать отраслевому стандарту использования DHCPv4 для обеспечения взаимодействия в той или иной технологической области, может потребоваться поддержка заданных производителями данной отрасли опций. Но той же реализации может потребоваться поддержка фирменных опций ее производителя. В частности, эта проблема возникает для производителей устройств, которые поддерживают стандарты [9], а также DOCSIS, CableHome и PacketCable, поскольку эти стандарты определяют отраслевое применение опций 60 и 43.
В этом документе определены две новых опции, моделирующие опции IPv6 для класса производителя и фирменной информации производителя, определенные в RFC 3315 [6], которые содержат выделенные IANA значения Enterprise Number [3] для устранения неоднозначной трактовки содержимого этих опций. При необходимости эти новые опции можно использовать в дополнение к имеющимся опциям vendor class и vendor information, определений которых данный документ не меняет.
1.1. Уровни требований
Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе должны интерпретироваться в соответствии с BCP 14, RFC 2119 [1].
2. Поддержка множества производителей
Каждая из определенных в этом документе опций может включать данные более чем для одного производителя. Данные каждой опции, определенные здесь, включают номер организации (назначается IANA [3]), за которым следует размер данных, а далее — фирменные данные производителя. Эта последовательность может повторяться в каждой опции. Поскольку размер агрегата фирменных данных для каждой из опций может превышать 255 октетов, эти опции объявляются concatenation-requiring (требуется конкатенация) в соответствии с RFC 3396 [4]. Поэтому для каждой из двух определенных здесь опций агрегат из всех экземпляров фирменных данных рассматривается как одна длинная опция. Такие длинные опции можно поделить на более мелкие при кодировании пакетов в соответствии с RFC 3396 по любым границам октетов, удобным для реализации. Деления по границам между данными разных производителей не требуется, но это может быть удобно для кодирования или отслеживания пакетов.
3. Опция Vendor-Identifying Vendor Class
Клиент DHCP может использовать эту опцию для однозначного указания производителя оборудования, на котором работает клиент, используемых программ или отраслевого консорциума, к которому относится производитель. Информация в каждой области данных производителя этой опции включает одно или множество не разобранных (opaque) полей, которые могут указывать детали конфигурации оборудования.
Эта опция может использоваться везде, где применима опция Vendor Class Identifier (60), как описано в RFC 2131 [2], за исключением сообщений DHCPNAK, где другие опции не разрешаются. Наиболее полезна эта опция в сообщениях от клиента DHCP к серверу DHCP (DHCPDISCOVER, DHCPREQUEST, DHCPINFORM).
Формат опции V-I Vendor Class показан ниже.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len1 | |
+-+-+-+-+-+-+-+-+ |
/ vendor-class-data1 /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| enterprise-number2 | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| data-len2 | | не обязательно
+-+-+-+-+-+-+-+-+ | |
/ vendor-class-data2 / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
option-code
OPTION_V-I_VENDOR_CLASS (124).
option-len
Общий размер данных следующей опции в октетах.
enterprise-numberN
32-битовое значение Enterprise Number производителя из реестра IANA [3].
data-lenN
Размер поля vendor-class-data.
vendor-class-dataN
Детали аппаратной конфигурации хоста, на котором работает клиент, или соответствия отраслевому консорциуму.
Эта опция содержит информацию, соответствующую одному или нескольким значениям Enterprise Number. Может присутствовать множество экземпляров опции, которые должны объединяться в соответствии с RFC 3396 [4]. Значению Enterprise Number следует присутствовать только один раз для всех экземпляров опции. При наличии множества Enterprise Number поведение становится неопределенным. Информация для каждого Enterprise Number трактуется независимо от ее использования с другими Enterprise Number или в отдельной опции.
Поле vendor-class-data представляет собой последовательность отдельных элементов, каждый из которых описывает некоторые характеристики аппаратной конфигурации или возможностей клиента. Примеры экземпляров vendor-class-data могут включать версию операционной системы клиента, объем памяти, доступной клиенту, и т. п.
Каждый экземпляр vendor-class-data имеет показанный ниже формат.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len | |
+-+-+-+-+-+-+-+-+ opaque-data |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Однооктетное поле data-len указывает размер данных vendor class, использующих сетевой порядок байтов.
4. Опция Vendor-Identifying Vendor-Specific Information
Клиенты и серверы DHCP могут использовать эту опцию для обмена данными конкретного производителя. При необходимости опцию может передавать каждая из сторон. Хотя обычно клиент передает опцию Vendor-Identifying Vendor Class для получения полезной ему опции Vendor-Identifying Vendor-Specific Information, это не обязательно.
Опция может включаться в любой пакет, для которого RFC 2131 [2] разрешает «прочие» опции (в частности, DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK и DHCPINFORM).
Формат опции V-I Vendor-specific Information показан ниже.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| enterprise-number1 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data-len1 | |
+-+-+-+-+-+-+-+-+ option-data1 |
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
| enterprise-number2 | ^
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| data-len2 | | не обязательно
+-+-+-+-+-+-+-+-+ option-data2 | |
/ / |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
~ ... ~ V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ----
option-code
OPTION_V-I_VENDOR_OPTS (125).
option-len
Общий размер данных следующей опции в октетах.
enterprise-numberN
32-битовое значение Enterprise Number производителя из реестра IANA [3].
data-lenN
Размер поля option-data.
option-dataN
Фирменные опции производителя, описанные ниже.
Определение информации, передаваемой в этой опции, зависит от производителя, который указывается полем enterprise-number. Опция содержит информацию, соответствующую одному или нескольким значениям Enterprise Number. Может присутствовать множество экземпляров опции, которые должны объединяться в соответствии с RFC 3396 [4].
Значение Enterprise Number следует включать лишь один раз для всех экземпляров опции. При наличии нескольких Enterprise Number поведение становится неопределенным. Информация для каждого Enterprise Number трактуется независимо от ее использования с другими Enterprise Number или в отдельной опции.
Использование фирменной информации обеспечивает поддержку расширенных операций с использованием дополнительных функций фирменных реализаций DHCP. Серверы, не способные интерпретировать такую информацию, должны игнорировать ее. Клиентам, которые не получили желаемой фирменной информации, следует пытаться обойтись без нее.
Инкапсулированное поле option-data должно кодироваться последовательностью полей код-размер-значение, идентичной формату поля опций DHCP. Коды опций, определенные производителем, идентифицируются полем enterprise-number и не контролируются агентством IANA. Коды 0 и 255 не имеют специального значения. Каждая из инкапсулированных опций использует показанный ниже формат.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subopt-code | subopt-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ sub-option-data /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
subopt-code
Код инкапсулированной опции.
subopt-len
Целое число без знака, указывающее размер поля option-data данной инкапсулированной опции в октетах.
sub-option-data
Область данных инкапсулированной опции.
5. Взаимодействие с IANA
Значения кодов опций OPTION_V-I_VENDOR_CLASS и OPTION_V-I_VENDOR_OPTS выделены из пространства, определенного для опций DHCP в RFC 2939 [7].
6. Вопросы безопасности
Этот документ не связан с обеспечением безопасности и не влияет на уровень защиты. Протокол DHCP поддерживает механизмы проверки подлинности и защиты целостности сообщений, описанные в RFC 3118 [8], которые могут использоваться для аутентификации данных, передаваемых в описанных здесь опциях.
7. Литература
7.1. Нормативные документы
[1] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[2] Droms, R., “Dynamic Host Configuration Protocol”, RFC 2131, March 1997.
[3] IANA, “Private Enterprise Numbers”, <http://www.iana.org/assignments/enterprise-numbers>.
[4] Lemon, T. and S. Cheshire, “Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)”, RFC 3396, November 2002.
7.2. Дополнительная литература
[5] Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions”, RFC 2132, March 1997.
[6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 3315, July 2003.
[7] Droms, R., “Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types”, BCP 43, RFC 2939, September 2000.
[8] Droms, R. and W. Arbaugh, “Authentication for DHCP Messages”, RFC 3118, June 2001.
[9] <http://www.cablelabs.com/>
8. Адрес автора
Josh Littlefield
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
USA
Phone: +1 978-936-1379
EMail: joshl@cisco.com
Перевод на русский язык
Николай Малых
9. Полное заявление авторских прав
Copyright (C) The Internet Society (2004).
К этому документу применимы права, лицензии и ограничения, указанные в BCP 78, и, за исключением указанного там, авторы сохраняют свои права.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
Интеллектуальная собственность
IETF не принимает какой-либо позиции в отношении действительности или объема каких-либо прав интеллектуальной собственности (Intellectual Property Rights или IPR) или иных прав, которые, как может быть заявлено, относятся к реализации или использованию описанной в этом документе технологии, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах RFC можно найти в BCP 78 и BCP 79.
Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить из сетевого репозитория IETF IPR по ссылке http://www.ietf.org/ipr.
IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Информацию следует направлять в IETF по адресу ietf-ipr@ietf.org.
Подтверждение
Финансирование функций RFC Editor обеспечено Internet Society.
1Dynamic Host Configuration Protocol — протокол динамической настройки конфигурации хоста.