RFC 3925 Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)

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)

PDF

Статус документа

Этот документ задает проект стандартного протокола 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 к серверу to 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


Перевод на русский язык

Николай Малых

nmalykh@gmail.com

9. Полное заявление авторских прав

Copyright (C) The Internet Society (2004).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an «AS IS» basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Интеллектуальная собственность

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF’s procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Подтверждение

Финансирование функций RFC Editor обеспечено Internet Society.


1Dynamic Host Configuration Protocol — протокол динамической настройки конфигурации хоста.