RFC 3442 The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4

Network Working Group                                           T. Lemon
Request for Comments: 3442                                 Nominum, Inc.
Updates: 2132                                                S. Cheshire
Category: Standards Track                           Apple Computer, Inc.
                                                                 B. Volz
                                                                Ericsson
                                                           December 2002

The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4

Опция бесклассового статического маршрута для протокола DHCP версии 4

PDF

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

Этот документ содержит проект стандартного протокола Internet для сообщества Internet и служит запросом к обсуждению в целях развития и совершенствования. Текущее состояние стандартизации и статус протокола можно узнать из документа «Internet Official Protocol Standards» (STD 1). Документ можно распространять без ограничений.

Авторские права

Аннотация

Этот документ определяет новую опцию протокола DHCP¹, которая передается от сервера DHCP клиенту DHCP для настройки у того списка статических маршрутов. Сети получателей в этих маршрутах являются бесклассовыми и каждый маршрут включает маску подсети.

Введение

Эта опция отменяет опцию Static Route (33), определенную в RFC 2132 [4].

Протокол IP [1] использует маршрутизаторы для передачи пакетов от хостов одной подсети IP хостам, подключенным к другой подсети IP. Когда хост IP (отправитель) хочет передать пакет другому хосту IP (получатель), он просматривает таблицу маршрутов для определения IP-адреса маршрутизатора, который следует использовать для пересылки пакета в направлении целевого хоста.

Таблица маршрутизации на хосте IP может поддерживаться множеством способов – с использованием протоколов маршрутизации, таких как RIP [8], обнаружения маршрутизаторов ICMP [6,9] или использования опции DHCP, определенной в RFC 2132 [4].

В сети, где уже применяется DHCP, использование протокола DHCP для обновления таблицы маршрутизации клиента DHCP дает несколько преимуществ. Это эффективно, поскольку использует сообщения, которые в любом случае будут передаваться. Это удобно – конфигурация сервера уже поддерживается, поэтому поддержка маршрутной информации (по крайней мере в относительно стабильной сети) не добавит много работы. Если услуги DHCP уже используются, другой инфраструктуры не нужно.

Протокол DHCP в соответствии с RFC 2131 [3] и опции, определенные в RFC 2132 [4], обеспечивают лишь механизм организации используемого по умолчанию маршрута или установки таблицы с маршрутами по классам адресов. Классовыми называют маршруты, в которых маска подсети неявно задается номером подсети (см. параграф 3.2 в STD 5, RFC 791 [1]).

Маршрутизация по классам вышла из употребления, поэтому опция DHCP Static Route стала бесполезной. В настоящее время бесклассовая маршрутизация [7, 10] стала общепринятой формой маршрутизации в Internet. В бесклассовой маршрутизации адреса IP состоят из номера сети (комбинация номера сети и номера подсети, описанная в RFC 950 [7]) и номера хоста.

В IP с классами номер сети и номер хоста выводились из адреса IP с использованием битовой маски, значение которой определялось несколькими первыми битами адреса IP. В IP без классов номер сети и номер хоста выводятся из адреса IP с использованием отдельного значения – маски подсети. Для определения сети, к которой относится данный маршрут, хост IP должен знать номер сети и маску подсети.

Опция Static Route (33) не указывала маску подсети для маршрутов, предполагая, что эта маска неявно определяется номером сети в каждой записи. Опция Classless Static Routes указывает маску подсети для каждой записи, поскольку маска может отличаться от определенной с помощью алгоритма из STD 5, RFC 791 [1] и STD 5, RFC 950 [7].

Определения

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), не рекомендуется (NOT RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с BCP 14, RFC 2119 [2].

Ниже приведены определения используемых в документе терминов.

DHCP client – клиент DHCP

Клиентом DHCP (клиентом) является хост Internet, использующий протокол DHCP для получения параметров конфигурации, таких как сетевой адрес.

DHCP server – сервер DHCP

Сервером DHCP (сервером) является хост Internet, который возвращает параметры конфигурации клиентам DHCP.

Link – канал

Любой набор точек подключения к сети, который будет принимать все широковещательные кадры канального уровня, переданные любой из точек подключения. Этот термин применяется в DHCP, поскольку в некоторых случаях на канале может быть организована не одна подсеть IP. DHCP использует широковещательный адрес local-network (все единицы), который не связан с подсетью и поэтому пакеты будут видны всем подключенным к каналу узлам, независимо от подсети или подсетей IP, которые на узле настроены.

Канал иногда называют доменом широковещания или физическим сегментом сети.

Формат опции Classless Routes

Эта опция имеет код 121 и минимальный размер 5 байтов. Опция может содержать один или множество статических маршрутов, каждый из которых включает дескриптор адресатов и IP-адрес маршрутизатора, который следует использовать для этих адресатов.

    Code Len Destination 1    Router 1
   +-----+---+----+-----+----+----+----+----+----+
   | 121 | n | d1 | ... | dN | r1 | r2 | r3 | r4 |
   +-----+---+----+-----+----+----+----+----+----+

    Destination 2       Router 2
   +----+-----+----+----+----+----+----+
   | d1 | ... | dN | r1 | r2 | r3 | r4 |
   +----+-----+----+----+----+----+----+

В приведенном выше примере заданы 2 статических маршрута.

Дескриптор получателя описывает номер подсети IP и маску для конкретного получателя с использованием компактного формата. Запись состоит из октета, указывающего размер маски, за которым следуют все значимые октеты номера подсети.

Размер маски указывает число битов. Например, подсеть с номером 10.0.127.0 и маской 255.255.255.0 будет иметь размер маски 24.

Значимая часть номера подсети включает все октеты номера подсети, для который соответствующий октет маски имеет отличное от нуля значение. Число значимых октетов равно размеру маски, поделенному на 8 с округлением в большую сторону, как показано в таблице.

Размер маски	Число значимых октетов
0	0
1-8	1
9-16	2
17-24	3
24-32	4

В следующей таблице приведены некоторые примеры представления разных номеров сети и масок.

Номер подсети	Маска подсети	Дескриптор адресата
0	0	0
10.0.0.0	255.0.0.0	8.10
10.0.0.0	255.255.255.0	24.10.0.0
10.17.0.0	255.255.0.0	16.10.17
10.27.129.0	255.255.255.0	24.10.27.129
10.229.0.128	255.255.255.128	25.10.229.0.128
10.198.122.47	255.255.255.255	32.10.198.122.47

Маршруты в локальные подсети

В некоторых случаях на канале может быть более одной подсети IP. При этом хост с IP-адресом из одной подсети может напрямую взаимодействовать с хостом, имеющим адрес IP из другой подсети на том же канале. Когда клиенту назначается IP-адрес из подсети на таком канале, для каждой другой подсети IP на этом канале сервер DHCP можно настроить на установку для маршрутизатора IP-адреса 0.0.0.0.

Например, рассмотрим случай наличия на канале трех подсетей IP – 10.0.0/24, 192.168.0/24, 10.0.21/24. Если клиенту назначен адрес IP 10.0.21.17, сервер может включить маршрут с адресатами 10.0.0/24 и маршрутизатором 0.0.0.0, а также маршрут с адресатами 192.168.0/24 и маршрутизатором 0.0.0.0.

Клиент DHCP, чей стек TCP/IP не обеспечивает такой возможности, должен игнорировать опцию Classless Static Routes, где указан IP-адрес маршрутизатора 0.0.0.0. Следует отметить, что описанное здесь поведение применимо лишь к опции Classless Static Routes, но не к опциям Static Routes и Router.

Поведение клиента DHCP

Не поддерживающие эту опцию клиенты DHCP должны игнорировать ее при получении от сервера DHCP. Поддерживающие опцию клиенты DHCP должны установить заданные в опции маршруты, за исключением указанных в параграфе «Маршруты в локальные подсети». Поддерживающим опцию клиентам DHCP недопустимо устанавливать маршруты, указанные в опции Static Routes (33), если присутствуют обе опции Static Routes и Classless Static Routes.

Клиенты DHCP, поддерживающие эту опцию и передающие опцию DHCP Parameter Request List, должны запрашивать эту опцию и опцию Router [4] в DHCP Parameter Request List.

Клиенты DHCP, поддерживающие эту опцию и передающие запрос списка параметров, могут также запросить опцию Static Routes для совместимости со старыми серверами, не поддерживающими Classless Static Routes. Код опции Classless Static Routes должен включаться в список запроса параметров до кодов опций Router и Static Routes, если они указываются.

Если сервер DHCP возвращает обе опции Classless Static Routes и Router, клиент DHCP должен игнорировать опцию Router.

Точно так же при возврате сервером обеих опций Classless Static Routes и Static Routes клиент DHCP должен игнорировать опцию Static Routes.

После вывода номера и маски подсети из дескриптора адресата клиент DHCP должен сбросить в 0 все биты номера подсети, для которых соответствующий бит маски имеет значение 0. Иными словами, номер подсети в таблице маршрутизации определяется результатом логической операции AND (И) для номера подсети и маски подсети из опции Classless Static Routes. Например, если сервер передал маршрут с получателем 129.210.177.132 (шестнадцатеричное значение 81D4B184) и маской подсети 255.255.255.128 (шестнадцатеричное значение FFFFFF80), клиент будет устанавливать маршрут с получателем 129.210.177.128 (шестнадцатеричное значение 81D4B180).

Предотвращение ограничения размеров

Поскольку полная таблица маршрутов может быть достаточно большой, стандартного максимального размера сообщений DHCP в 576 октетов может оказаться недостаточно для некоторых опций Classless Static Route. По этой причине клиентам, реализующим опцию Classless Static Route, следует передать опцию Maximum DHCP Message Size [4], если стек TCP/IP у клиента DHCP способен принимать более крупные дейтаграммы IP. В этом случае клиенту следует указывать в качестве значения этой опции как минимум значение MTU на интерфейсе, который настраивается. Клиент может указать для этой опции любое значение вплоть до максимального размера пакета UDP, который он готов принять (отметим, что значение опции Maximum DHCP Message Size ограничивает общий размер пакета с учетом заголовков IP и UDP).

Клиенты DHCP, запрашивающие эту опцию, и передающие ее серверы DHCP должны поддерживать конкатенацию опций DHCP [5]. В терминологии RFC 3396 [5] опция Classless Static Route Option является требующей конкатенации.

Администрирование серверов DHCP

Многие клиенты могут не поддерживать опцию Classless Static Routes. Поэтому администраторы серверов DHCP настраивают свои серверы на отправку опций Router и Classless Static Routes, при этом следует указывать используемые по умолчанию маршрутизаторы в обеих опциях Router и Classless Static Routes.

Когда клиент DHCP запрашивает опцию Classless Static Routes, а также одну или обе опции Router и Static Routes, а сервер DHCP передает этому клиенту опцию Classless Static Routes, серверу не следует включать опции Router и Static Routes.

Вопросы безопасности

Возможные атаки на протокол DHCP рассмотрены в разделе 7 спецификации DHCP [3] и в документе по аутентификации сообщений DHCP [11].

Опцию Classless Static Routes можно использовать для перенаправления сетевого трафика путем указания некорректных IP-адресов для маршрутизаторов. Это может быть DoS²-атака, где указывается недействительный IP-адрес маршрутизатора или MITM³-атака, где указывается специальный адрес IP для сбора и анализа пакетов. Это не создает новой проблемы, поскольку опции Router и Static Routes, определенные в RFC 2132 [4] имели такие же уязвимости.

Взаимодействие с IANA

Для этой опции DHCP выделен код 121 в списке опций DHCP, поддерживаемом IANA.

Нормативные документы

[1] Postel, J., “Internet Protocol”, STD 5, RFC 791, September 1981.

[2] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[3] Droms, R., “Dynamic Host Configuration Protocol”, RFC 2131, March 1997.

[4] Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions”, RFC 2132, March 1997.

[5] Lemon, T. and S. Cheshire, “Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)”, RFC 3396, November 2002.

Дополнительная литература

[6] Postel, J., “Internet Control Message Protocol”, STD 5, RFC 792, September 1981.

[7] Mogul, J. and J. Postel, “Internet Standard Subnetting Procedure”, STD 5, RFC 950, August 1985.

[8] Hedrick, C., “Routing Information Protocol”, RFC 1058, June 1988.

[9] Deering, S., “ICMP Router Discovery Messages”, RFC 1256, September 1991.

[10] Pummill, T. and B. Manning, “Variable Length Subnet Table For IPv4”, RFC 1878, December 1995.

[11] Droms, R. and W. Arbaugh, “Authentication for DHCP Messages”, RFC 3118, June 2001.

Права интеллектуальной собственности

IETF не занимает какой-либо позиции в отношении действительности или объёма каких-либо прав интеллектуальной собственности или иных прав, которые могут быть заявлены как относящиеся к реализации или применению технологии, описанной в этом документе, или степени, в которой любая лицензия, по которой права могут или не могут быть доступны, не заявляется также применение каких-либо усилий для определения таких прав. Сведения о процедурах IETF в отношении прав в документах, связанных со стандартами, можно найти в BCP-11. Копии раскрытия IPR, предоставленные секретариату IETF, и любые гарантии доступности лицензий, а также результаты попыток получить общую лицензию или право на использование таких прав собственности разработчиками или пользователями этой спецификации, можно получить в IETF Secretariat.

IETF предлагает любой заинтересованной стороне обратить внимание на авторские права, патенты или использование патентов, а также иные права собственности, которые могут потребоваться для реализации этого стандарта. Эту информацию следует направлять исполнительному директоу IETF (Executive Director).

Адреса авторов

Ted Lemon

Nominum, Inc.

2385 Bay Road

Redwood City, CA 94063

EMail: Ted.Lemon@nominum.com

Stuart Cheshire

Apple Computer, Inc.

1 Infinite Loop

Cupertino

California 95014

USA

Phone: +1 408 974 3207

EMail: rfc@stuartcheshire.org

Bernie Volz

Ericsson

959 Concord Street

Framingham, MA, 01701

Phone: +1 508 875 3162

EMail: bernie.volz@ericsson.com

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

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

nmalykh@gmail.com

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

Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.

Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.

Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.

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

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

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

2Denial of Service – отказ в обслуживании.

3Man-in-the-middle – перехват и изменение пакетов с участием человека.