RFC 5494 IANA Allocation Guidelines for the Address Resolution Protocol (ARP)

Network Working Group                                           J. Arkko
Request for Comments: 5494                                      Ericsson
Updates: 826, 951, 1044, 1329, 2131,                        C. Pignataro
         2132, 2176, 2225, 2834, 2835,                     Cisco Systems
         3315, 4338, 4361, 4701                               April 2009
Category: Standards Track

Рекомендации IANA по выделению значений ARP

IANA Allocation Guidelines for the Address Resolution Protocol (ARP)

PDF

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

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

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

Авторские права (Copyright (c) 2009) принадлежат IETF Trust и лицам, указанным в качестве авторов документа. Все права защищены.

К этому документу применимы права и ограничения, перечисленные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно.

Фрагменты программного кода, включенные в этот документ, распространяются в соответствии с упрощенной лицензией BSD, как указано в параграфе 4.e документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Аннотация

Этот документ содержит рекомендации IANA по выделению новых значений для протокола ARP¹. Документ также резервирует некоторые значения для экспериментальных целей. Внесенные изменения также влияют на другие протоколы, использующие значения из пространства имен ARP.

1. Введение

Этот документ задает рекомендации IANA [RFC5226] по выделению новых значений для различных полей в протоколе преобразования адресов ARP [RFC0826]. Изменения применимы к расширениям ARP, использующим такой же формат сообщений как [RFC0903], [RFC1931] и [RFC2390].

Изменения также оказывают влияние на другие протоколы, которые используют значения из пространства имен ARP. Например пространство типов аппаратного адреса ARP (ar$hrd) используется в полях htype (тип аппаратного адреса) протоколов BOOTP² [RFC0951] и DHCP³ [RFC2131], а также в поле hardware type в DHCP Unique Identifiers протокола DHCPv6 [RFC3315]. Поэтому обновление правил IANA оказывает влияние на эти протоколы. Другие спецификации, на которые влияют новые правила, включают механизмы преобразования адресов в:

• HYPERchannel [RFC1044];

• опциях DHCP [RFC2132] [RFC4361];

• ATM⁴ ARP [RFC2225]

• HARP⁵ [RFC2834] [RFC2835]

• Dual MAC⁶ FDDI⁷ ARP [RFC1329]

• MAPOS⁸ ARP [RFC2176]

• FC⁹ ARP [RFC4338]

• DNS DHCID Resource Record [RFC4701]

Рекомендации IANA приведены в разделе 2. Раньше для такого распределения рекомендаций IANA не было. Целью этого документа является предоставление агентству IANA возможности согласованного выделения числовых значений на основе этих рекомендаций.

Документ также резервирует некоторые значения для экспериментов. Эти значения описаны в разделе 3.

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

Ниже приведены правила, применяющиеся для полей ARP.

ar$hrd (16 битов) – пространство аппаратных адресов

Запросы для значений ar$hrd меньше 256, а также запросы на выделение более одного значения обрабатываются по процедуре Expert Review [RFC5226].

Отметим, что некоторые протоколы типа BOOTP и DHCPv4 используют эти значения в 8-битовых полях. Экспертам следует убедиться в необходимости выделения новых значений, а также в том, что имеющихся значений не достаточно для представления новых типов аппаратных адресов. Экспертам также следует определить применимость запроса и выделять значения больше 255 для запросов, которые не применимы к BOOTP/DHCPv4. Экспертам следует выделять 1-октетные значения для запросов, применимых к BOOTP/DHCPv4, например, IPsec tunnel со значением [RFC3456]. И наоборот, значения, предназначенные только для ARP, без каких-либо причин использовать их для BOOTP/DHCPv4, следует выделять из числа 2-октетных.

Запросы на выделение отдельных новых ar$hrd без указания конкретного значения или с указанием значения больше 255 обрабатываются про процедуре First Come First Served [RFC5226]. В результате всегда выделяется 2-октетное значение.

ar$pro (16 битов) – пространство протокольных адресов

Эти значения используют пространство Ethertype, администрирование которого описано в [RFC5342].

ar$op (16 битов) – коды операций

Запросы на выделение новых значений ar$op обрабатываются про процедуре IETF Review или IESG Approval [RFC5226].

3. Значения, выделенные в этом документе

При проверке новых идей расширения протоколов часто требуется применять действующие константы для использования новых функций даже при тестировании в замкнутой среде. Этот документ резервирует приведенные ниже значения для экспериментов с ARP.

• Для экспериментов выделены два новых значения ar$hrd – HW_EXP1 (36) и HW_EXP2 (256). Отметим, что для экспериментов осознанно было выбрано одно значение меньше 256, а другое больше 255, чтобы они различались как в старшем, так и в младшем октете.

• Для экспериментов выделены два новых значения ar$op – OP_EXP1 (24) и OP_EXP2 (25).

Отметим, что в Приложении B.2 к [RFC5342] указаны два значения Ethertype, которые могут использоваться в экспериментах.

Кроме того, для ar$hrd и ar$op значения 0 и 65535 были помечены как резервные. Это означает их недоступность для выделения.

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

Эта спецификация не меняет параметров безопасности затрагиваемых документом протоколов.

Однако нужно сказать несколько слов об использовании экспериментальных кодов, определенных в разделе 3. Возможные негативные последствия применения экспериментальных значений следует внимательно оценить до начала каких-либо экспериментов в сетях, которые не находятся под полным контролем экспериментатора. Приведенные в [RFC3692] рекомендации по использованию экспериментальных значений должны строго выполняться.

5. Благодарности

Отсутствие каких-либо действующих правил было обнаружено при запросе новых значений у агентства IANA, которое обратилось за консультацией в IESG. Автор признателен Michelle Cotton за поднятие этой проблемы. Спасибо также Brian Carpenter, Thomas Narten, Scott Bradner, Donald Eastlake, Andrew G. Malis, Brian Haberman, Robert Sparks, Larry Zhu и Dave Thaler за их отклики.

6. Литература

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

[RFC0826] Plummer, D., “Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware”, STD 37, RFC 826, November 1982.

[RFC0951] Croft, B. and J. Gilmore, “Bootstrap Protocol”, RFC 951, September 1985.

[RFC1044] Hardwick, K. and J. Lekashman, “Internet Protocol on Network System’s HYPERchannel: Protocol specification”, STD 45, RFC 1044, February 1988.

[RFC1329] Kuehn, P., “Thoughts on Address Resolution for Dual MAC FDDI Networks”, RFC 1329, May 1992.

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

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

[RFC2176] Murakami, K. and M. Maruyama, “IPv4 over MAPOS Version 1”, RFC 2176, June 1997.

[RFC2225] Laubach, M. and J. Halpern, “Classical IP and ARP over ATM”, RFC 2225, April 1998.

[RFC2834] Pittet, J., “ARP and IP Broadcast over HIPPI-800”, RFC 2834, May 2000.

[RFC2835] Pittet, J., “IP and ARP over HIPPI-6400 (GSN)”, RFC 2835, May 2000.

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 3315, July 2003.

[RFC3692] Narten, T., “Assigning Experimental and Testing Numbers Considered Useful”, BCP 82, RFC 3692, January 2004.

[RFC4338] DeSanti, C., Carlson, C., and R. Nixon, “Transmission of IPv6, IPv4, and Address Resolution Protocol (ARP) Packets over Fibre Channel”, RFC 4338, January 2006.

[RFC4361] Lemon, T. and B. Sommerfeld, “Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)”, RFC 4361, February 2006.

[RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, “A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)”, RFC 4701, October 2006.

[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.

[RFC5342] Eastlake. , D., “IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters”, BCP 141, RFC 5342, September 2008.

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

[RFC0903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, “Reverse Address Resolution Protocol”, STD 38, RFC 903, June 1984.

[RFC1931] Brownell, D., “Dynamic RARP Extensions for Automatic Network Address Acquisition”, RFC 1931, April 1996.

[RFC2390] Bradley, T., Brown, C., and A. Malis, “Inverse Address Resolution Protocol”, RFC 2390, September 1998.

[RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, “Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode”, RFC 3456, January 2003.

Приложение A. Отличия от исходных RFC

Этот документ задает лишь правила IANA, связанные с различными полями ARP. Эти правила также воздействуют на выделение соответствующих полей в протоколах, перечисленных в разделе 1, которые используют реестр. Этот документ не вносит каких-либо изменений в работу самих протоколов.

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

Jari Arkko

Ericsson

Jorvas 02420

Finland

EMail: jari.arkko@piuha.net

Carlos Pignataro

Cisco Systems

7200-12 Kit Creek Road

Research Triangle Park, NC 27709

USA

EMail: cpignata@cisco.com

---

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

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

nmalykh@protokols.ru

---