RFC 9542 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Опубликовано 26.04.2024 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 9542                                   Independent
BCP: 141                                                        J. Abley
Obsoletes: 7042                                               Cloudflare
Category: Best Current Practice                                    Y. Li
ISSN: 2070-1721                                      Huawei Technologies
                                                              April 2024

IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters

Соображения IANA, использование протоколов и документации IETF для параметров IEEE 802

PDF

Аннотация

Некоторые протоколы IETF используют форматы кадров Ethernet и параметры IEEE 802. В этом документе обсуждаются некоторые аспекты таких параметров и их использование в протоколах IETF, приведены соображения IANA по выделению точек под IANA Organizationally Unique Identifier (OUI), а также указаны некоторые значения для использования в документации. Документ заменяет RFC 7042.

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

Документ относится к категории Internet Best Current Practice.

Документ является результатом работы IETF1 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG2. Дополнительную информацию о документах BCP можно найти в разделе 2 в RFC 7841.

Информацию о текущем статусе документа, ошибках и способах обратной связи можно найти по ссылке https://www.rfc-editor.org/info/rfc9542.

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

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

К документу применимы права и ограничения, указанные в BCP 78 и IETF Trust Legal Provisions и относящиеся к документам IETF (http://trustee.ietf.org/license-info), на момент публикации данного документа. Прочтите упомянутые документы внимательно. Фрагменты программного кода, включённые в этот документ, распространяются в соответствии с упрощённой лицензией BSD, как указано в параграфе 4.e документа IETF Trust Legal Provisions, без каких-либо гарантий (как указано в Revised BSD License).



1. Введение


В некоторых протоколах IETF применяются форматы и параметры кадров Ethernet и других кадров, связанных с IEEE 802 [IEEE802], включая MAC-адреса и идентификаторы протоколов. Регистрационное агентство (Registration Authority) IEEE [IEEE_RA] управляет выделением идентификаторов, используемых в сетях IEEE 802, в некоторых случаях выделяя блоки таких идентификаторов для дальнейшего распределения получившей блок организацией. IEEE RA также предоставляет ряд учебных пособий, относящихся к этим параметрам [IEEEtutorials].


Агентство IEEE RA выделило IANA уникальный идентификатор организации (Organizationally Unique Identifier или OUI) и соответствующий набор MAC-адресов, а также иные коды, основанные на полученном OUI. Этот документ описывает соображения IANA по распределению кодов в рамках IANA OUI, включая MAC-адреса и идентификаторы протоколов, а также указывает некоторые значения для использования в документации. Как указано в [RFC2606] и [RFC5737], использование значений кодов, зарезервированных для документации и примеров, снижает вероятность конфликтов и путаницы в результате использования кодов, выделенных для других целей (применения в реальных системах). В документе рассматривается несколько других случаев применения IETF кодов IEEE 802, включая коды IEEE 802 для контроля отказов связности (Connectivity Fault Management тлт CFM) [RFC7319] и связанных с производителями субтипов TLV (Vendor-Specific TLV Sub-Type) [RFC8520] протокола IEEE 802 для обнаружения локального канала (Link Local Discovery Protocol или LLDP) [IEEE802.1AB]. Документ также задаёт теги краткого двоичного представления объектов (Concise Binary Object Representation или CBOR) для MAC-адресов и OUI/CID.


Приведённые здесь описания правил и процедур [IANA] являются полномочными, но описания правил, процедур и стандартов регистрации IEEE имеют лишь информативный характер, а полномочные сведения IEEE следует получать из документов IEEE.


Этот документ включает процедуры [RFC8126], за исключением случаев противоречия данному документу. Здесь термин «ратификация IESG» (IESG Ratification), определённый в параграфе 5.1, указывает сочетание процедур Expert Review и IESG Approval, определённых в [RFC8126], где IESG Approval требуется лишь в тех случаях, когда эксперт не отклоняет запрос. Это не совпадает с трактовкой IESG Approval в [RFC8126].


1.1. Используемые обозначения


В документе применяется шестнадцатеричная нотация. Каждый октет (8-битовый байт) представляется двумя шестнадцатеричными цифрами, указывающими октет как целое число без знака. Последовательные октеты разделяются символом дефиса (-). В документе используется принятый в IETF (сетевой) порядок битов, хотя физически битов октета передаются по каналу IEEE [IEEE.802.3_2012], начиная с младшего (обратный по отношению к IETF).


AFN


Address Family Number [RFC4760] – номер семейства адресов.


CBOR


Concise Binary Object Representation [RFC8949] – краткое двоичное представление.


CFM


Connectivity Fault Management [RFC7319] – контроль отказов связности.


CID


Company Identifier – идентификатор компании (см. параграф 2.1.2).


DSAP


Destination Service Access Point – точка доступа к целевому сервису (см. раздел 3).


EUI


Extended Unique Identifier – расширенный уникальный идентификатор.


EUI-48


48-битовый EUI.


IEEE


Institute of Electrical and Electronics Engineers [IEEE] – Институт инженеров по электротехнике и электронике.


IEEE 802


LAN/MAN Standards Committee [IEEE802] – Комитет стандартизации локальных и городских сетей.


IEEE RA


IEEE Registration Authority [IEEE_RA] – Регистрационное агентство IEEE.


IEEE SA


IEEE Standards Association [IEEE_SA] – Ассоциация стандартов IEEE.


LLC


Logical Link Control – управление логическим каналом. Тип заголовка кадра, где протокол указывается полями LSAP отправителя и получателя (см. раздел 3).


LSAP


Link-Layer Service Access Point – точка доступа к услугам канального уровня (см. раздел 3).


MA-L


MAC Address Block Large – большой блок MAC-адресов.


MA-M


MAC Address Block Medium – средний блок MAC-адресов.


MA-S


MAC Address Block Small – мелкий блок MAC-адресов.


MAC


Media Access Control – управление доступом к среде (не Message Authentication Code).


MAC-48


48-битовый MAC-адрес. Термин устарел, для глобально уникальных адресов применяется EUI-48.


OUI


Organizationally Unique Identifier – уникальный идентификатор организации (см. параграф 2.1.2).


RRTYPE


DNS Resource Record type [RFC6895] – тип записи о ресурсе DNS.


SLAP


IEEE 802 Structured Local Address Plan [IEEE802_OandA] – структурированный план локальной адресации IEEE 802 (см. параграф 2.1.1).


SNAP


Subnetwork Access Protocol – протокол доступа в подсеть (см. раздел 3).


SSAP


Source Service Access Point – точка доступа к сервису у источника (см. раздел 3).


tag


Ттермин «тег» в этом документе используется в двух значениях. Теги Ethernet описаны в разделе 3, теги CBOR – в параграфе 2.4.


TLV


Type-Length-Value – тип-размер-значение.


**


Обозначение возведения в степень. Например, 2**24 указывает 2 в степени 24.


1.2. Регистрационное агентство IEEE


Изначально за регистрацию параметров Ethernet отвечала корпорация Xerox Corporation, а в 1986 г. было организовано агентство IEEE Registration Authority, доступное через Web [IEEE_RA].


IEEE Registration Authority работает под руководством совета управляющих (Board of Governors) Ассоциации стандартов IEEE (IEEE SA), а надзор за деятельность агентства осуществляет специальный комитет (IEEE Registration Authority Committee или IEEE RAC), являющийся комитетом Совета управляющих.


Любой человек может обратиться в агентство для выделения ему параметров. IEEE RA может устанавливать плату и другие требования, но обычно освобождает от платы организации по разработке стандартов. Списки назначений и их держателей можно загрузить с сайта IEEE RA.


1.3. Идентификатор IANA OUI


Агентство IEEE RA выделило IANA уникальный идентификатор организации (OUI) 00-00-5E. В настоящее время нет значения OUI, зарезервированного для документации, но имеются коды в иерархии IANA OUI, описанные ниже.


1.4. Коды CFM


В стандарте IEEE Std 802.1Q [IEEE.802.1Q_2014] для IETF выделены два блока кодов 802 CFM – один для CFM OpCode, другой для CFM TLV Type (дополнительные сведения приведены в [RFC7319]). В реестре IANA Connectivity Fault Management (CFM) OAM IETF Parameters созданы субреестры для этих кодов. В данном документе эти блоки кодов больше не обсуждаются.


2. Параметры идентификаторов Ethernet


В этом разделе приведены обобщающие контекст сведения из [IEEE802_OandA]. При возникновении каких-либо расхождений преимущество отдаётся [IEEE802_OandA]. В параграфе 2.1 рассмотрены 48-битовые идентификаторы MAC, их связь с OUI и другими префиксами, а также выделение значений в рамках IANA OUI. В параграфе 2.2 рассматриваются 64-битовые идентификаторы, а в параграфе 2.3 обсуждаются другие идентификаторы IETF MAC, не связанные с IANA OUI. Параграф 2.4 задаёт теги CBOR для MAC-адресов и OUI/CID.


Историческое примечание. В устаревшем документе Internet-Draft Note [RAC_OUI] представлены дополнительные сведения о реестрах [IEEE802].


2.1. 48-битовые идентификаторы MAC, OUI и другие префиксы


48-битовые «адреса» MAC являются наиболее распространёнными идентификаторами интерфейсов Ethernet. Уникальные в глобальном масштабе идентификаторы этого типа называются EUI-48 (Extended Unique Identifier 48). Идентификатор EUI-48 состоит из префикса, выделяемого IEEE RA и дополнительных битов, назначаемых владельцем префикса. С 2024 г. выделяются префиксы трёх размеров, однако некоторые биты префикса могут иметь специальное значение, как показано на рисунке 1.


Таблица .


 








Размер префикса в битах




Имя




Представляемые владельцем биты MAC-48








24




MA-L




24








28




MA-M




20








36




MA-S




12








 


4 младших бита первого из 6 октетов 48-битового MAC имеют особое значение и называются далее битами M, X, Y, Z (рисунок 1).


  0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| .  .  .  .  Z  Y  X  M| .  .  .  .  .  .  .  .| октеты 0+1
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| .  .  .  .  .  .  .  .| .  .  .  .  .  .  .  .| октеты 2+3
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| .  .  .  .  .  .  .  .| .  .  .  .  .  .  .  .| октеты 4+5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


Рисунок . Структура 48-битового MAC-адреса.



Для глобальных адресов X = 0 и MAC-адрес начинается с префикса размером 3 октета или больше, указывающего блок адресов MAC. За префиксом следуют дополнительные дополнительные биты3 до полного размера MAC-адреса. Например IEEE выделяет мелкий блок MAC (MA-S), где заданы первые 4 ½ октета (36 битов), а держателю MA-S оставлены полтора октета (12 битов), которые он может использовать для создания 48-битовых MAC-адресов. Префиксы могут иметь несколько размеров [IEEEtutorials].


Для 48-битовых MAC-адресов выделены теги AFN, DNS RRTYPE и CBOR, как указано в параграфах 2.4, 5.3 и 5.9.


В IEEE Std 802 описаны процедуры и правила выделения идентификаторов, связанных с IEEE 802 [IEEE802_OandA]. Документация IEEE RA по EUI, OUI и CID доступна в [IEEEtutorials].


2.1.1. Особые биты первого октета


В первом октете адреса IEEE MAC имебтся особые биты [IEEE802_OandA], описанные ниже.


M


Этот бит часто называют групповым или многоадресным (multicast). Для индивидуальных MAC-адресов бит сброшен (0). Установленный (1) бит означает многоадресную передачу (групповую или широковещательную). Значение бита не зависит от установки битов X, Y, Z.


X


Этот бит называют universal/local (универсальный/локальный), а раньше использовалось название Local/Global. Сброшенный (0) быт указывает глобальный MAC-адрес, контролируемый владельцем выделенного IEEE префикса. Ранее установка (1) этого бита указывала «локальный» адрес MAC, контролируемый местным оператором сети (см. также параграф 2.3). Если бит установлен и действует IEEE 802 SLAP, характер MAC-адреса может определяться битами Y и Z, как описано ниже.


Y и Z


Эти два бита не имеют особого значения при сброшенном (0) бите X. Если бит X и действует IEEE 802 SLAP, эти биты делят ранее единое пространство «локальных» адресов MAC на 4 квадранта, как описано ниже.


Таблица .


 








Бит Y




Бит Z




Квадрант








0




0




Назначен административно








0




1




Расширенный локальный адрес








1




0




Резерв








1




1




Назначен стандартом








 


Хотя локальный администратор может установить (1) бит X в любом адресе, необязательный план SLAP выделяет 4 квадранта для пространства «локальных» адресов с помощью битов Y и Z, как указано ниже


Administratively Assigned – назначен административно


MAC-адреса этого квадранта называют назначенными административно идентификаторами (Administratively Assigned Identifier). Они предназначены для произвольного локального распределения, например, случайного (см. также параграф 2.3.1).


Extended Local – расширенный локальный адрес


MAC-адреса этого квадранта называют расширенными локальными идентификаторами (Extended Local Identifier). Фактически они не являются «локальными» при использовании SLAP. Эти адреса доступны организации, которой выделен идентификатор CID (параграф 2.1.2), задающий другие 20 битов 24-битового префикса с X=1, Y=0 и Z = 1.


Reserved – резерв


MAC-адреса этого квадранта зарезервированы для будущего использования со SLAP4. До этого они могут распределяться локально (как Administratively Assigned Identifier), но при последующем использовании SLAP могут возникнуть конфликты с этим распределением.


Standard Assigned – назначен стандартом


MAC-адреса этого квадранта называют назначенными стандартом (Standard Assigned Identifier или SAI). SAI выделяются протоколом, заданным в стандартеiIEEE 802, например, [IEEE802.1CQ]5.


2.1.2. OUI и CID


Префиксы MA-L, MA-M и MA-S выделяются со сброшенным битом Local (X=0). Держатель OUI имеет исключительное право назначать групповые MAC-адреса, используя изменённый вариант назначенного OUI, где бит M = 1 (рисунок 1) [IEEEtutorials].


Бит Local (X) сброшен (0) для глобально уникальных идентификаторов EUI-48, назначаемых владельцем MAC-L или более длинного префикса. При установленном бите Local идентификатор исторически считается локальным и находящимся под контролем местного администратора сети. Однако в настоящее время имеются рекомендации по необязательному управлению локальным пространством адресов, как описано в параграфе 2.1.1. Если бит Local установлен (1), владелец OUI не имеет особых полномочий для идентификаторов MAC, где три первых октета соответствуют его OUI или началу более длинного префикса.


CID является 24-битовым идентификатором компании и выделяется нуждающимся в таких идентификаторах организациям. Этот идентификатор можно применять вместо OUI, но не требуется назначать дочерние глобальные адреса MAC. В CID биты X и Z установлены (1), а бит Y сброшен в 0 (см. рисунок 1).


Для идентификаторов OUI и CID назначены теги AFN и CBOR, как описано в параграфах 2.4, 5.3, 5.9.


2.1.3. Назначение 48-битовых MAC в иерархии IANA OUI


OUI 00-00-5E назначен IANA, как указано в параграфе 1.3. Это включает 224 48-битовых групповых идентификаторов от 01-00-5E-00-00-00 до 01-00-5E-FF-FF-FF и 224 индивидуальных EUI-48 от 00-00-5E-00-00-00 до 00-00-5E-FF-FF-FF. Эти идентификаторы разделены на субблоки, как описано ниже.


Индивидуальные (unicast) блоки по 28 адресов


00-00-5E-00-00-00 – 00-00-5E-00-00-FF – резерв, распределяемый по процедуре IESG Ratification (параграф 5.1).


00-00-5E-00-01-00 – 00-00-5E-00-01-FF – выделен для протокола VRRP [RFC5798].


00-00-5E-00-02-00 – 00-00-5E-00-02-FF – выделен для протокола IPv6 VRRP [RFC5798].


00-00-5E-00-52-00 – 00-00-5E-00-52-FF – используется для мелких блоков (на 2024 г. выделены 4 блока из 256). См. [EthernetNum].


00-00-5E-00-53-00 – 00-00-5E-00-53-FF – используется для документации в соответствии с эти документом.


00-00-5E-90-01-00 – 00-00-5E-90-01-FF – используется для мелких блоков, где нужны индивидуальные и групповые MAC-адреса (на 2024 г. выделено 1 из 256 значений). См. [EthernetNum].


Групповые (multicast)


01-00-5E-00-00-00 – 01-00-5E-7F-FF-FF – 223 адресов для IPv4 multicast [RFC1112].


01-00-5E-80-00-00 – 01-00-5E-8F-FF-FF – 220 адресов для MPLS multicast [RFC5332].


01-00-5E-90-00-00 – 01-00-5E-90-00-FF – 28 адресов для мелких блоков (на 2024 г. выделены 4 блока из 256). См. [EthernetNum].


01-00-5E-90-01-00 – 01-00-5E-90-01-FF – используется для мелких блоков, где нужны индивидуальные и групповые MAC-адреса (на 2024 г. выделено 1 из 256 значений). См. [EthernetNum].


01-00-5E-90-10-00 – 01-00-5E-90-10-FF – 28 адресов для документации в соответствии с эти документом.


Более подробные и актуальные сведения представлены в реестре IANA OUI Ethernet Numbers [EthernetNum].


2.1.4. Значения 48-битовых адресов MAC для документации


Ниже указаны значения, выделенные для использования в документации.


    

  • 

    00-00-5E-00-53-00 – 00-00-5E-00-53-FF для индивидуальных адресов.
    

    • 

  • 

    01-00-5E-90-10-00 – 01-00-5E-90-10-FF для групповых адресов.
    

    • 



2.1.5. Вопросы распределения 48-битовых IANA MAC


Назначения 48-битовых адресов в иерархии текущего и будущих IANA OUI (см. параграф 5.6) должны соответствовать приведённым ниже требованиям.


    

  • 

    Назначение для стандартных целей (IETF Standard или иные стандарты, связанные с IETF).
    

    • 

  • 

    Выделение блоков размером в степень 2, начиная с границы, равной или большей степени 2, включая выделение одного (20) идентификатора.
    

    • 

  • 

    Использование для обхода требования к производителям сетевых интерфейсов получать свой блок от IEEE.
    

    • 

  • 

    Документирование в Internet-Draft или RFC.
    

    • 



Кроме того, выделение должно быть одобрено (см. процедуры в параграфе 5.1):


    

  • 

    для мелких и средних блоков из 1, 2, 4, …, 32768, 65536 (20, 21, 22, …, 215, 216) идентификатора EUI-48 по процедуре Expert Review (параграф 5.1).
    

    • 

  • 

    для больших блоков из 131072 (217) и более адресов EUI-48 по процедуре IESG Ratification ( параграф 5.1).
    

    • 



2.2. 64-битовые идентификаторы MAC


В IEEE определены 64-битовые идентификаторы MAC, включая EUI-64, которые применяются:


    

  • 

    в IEEE Std 1394 [IEEE1394] (называется также FireWire и i.Link);
    

    • 

  • 

    в IEEE Std 802.15.4 [IEEE802.15.4] ( называется также Zigbee);
    

    • 

  • 

    в [InfiniBand];
    

    • 

  • 

    в изменённой форме для создания некоторых идентификаторов интерфейсов IPv6, как описано в параграфе 2.2.1, хотя сейчас это признано устаревшим.
    

    • 



Добавление 5-октетного (40 юитов) расширения к 3-октетному (24 бита) OUI или более короткое расширение более длинного префикса [RAC_OUI], чтобы в сумме получилось 64 бита, создаёт EUI-64 битовый идентификатор в рамках OUI или более длинного префикса. Первый октет имеет особые биты, как и в идентификаторах EUI-48.


Для 64-битовых MAC-адресов выделены теги AFN, DNS RRTYPE и CBOR, как описано в параграфах 2.4, 5.3 и 5.9.


Далее рассматривается в основном «изменённая» форма идентификаторов EUI-64, однако те, кому такой идентификатор выделен, могут применять не изменённую форму MAC на любом канале, где 64-битовые идентификаторы применяются для интерфейсов.


2.2.1. Использование изменённых идентификаторов EUI-64 в IPv6


Описанный ниже подход к созданию идентификаторов IPv6 для интерфейсов в настоящее время признан устаревшим и взамен рекомендуется использовать метод, описанный в [RFC8064].


Идентификаторы EUI-64 служат в качестве 64 младших битов некоторых адресов IPv6 (параграф 2.5.1 и Приложение A к [RFC4291], Приложение A к [RFC5214]). При таком использовании EUI-64 бит X (universal/local) инвертируется для формирования «идентификатора Modified EUI-64» IETF. Примером изменённого индивидуального идентификатора EUI-64 в рамках IANA OUI может служить 02-00-5E-aa-bb-cc-dd-ee, где aa-bb-cc-dd-ee – это расширение. Первый октет имеет значение 02, а не 00, поскольку в изменённых EUI-64 бит X инвертируется по сравнению с EUI-48. Бит 0x02 (X или universal/local) в первом октете имеют уникальные в глобальном масштабе идентификаторы, тогда как идентификаторы со сброшенным (0) битом назначаются локально и не подлежат глобальному управлению. Бит X (universal/local) инвертирован для упрощения ввода идентификаторов локального действия администраторами сетей. В результате изменённые идентификаторы EUI-64 вида 1, 2 и т. д. (нули в начале не показаны) являются локальными. Без этого изменения локальные идентификаторы бы имели вид 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02 и т. д.


Как и в 48-битовых MAC бит M (0x01) в первом октете указывает групповой или широковещательны идентификатор.


Когда первые два октета расширения изменённого идентификатора EUI-64 имеют значение FF-FE, остальное расширение является 24-битовым значением, заданным владельцем OUI для EUI-48. Например, в идентификаторах 02-00-5E-FF-FE-yy-yy-yy и 03-00-5E-FF-FE-yy-yy-yy октеты yy-yy-yy являются частью (глобального индивидуального или группового идентификатора EUI-48), назначенной владельцем OUI (в данном случае IANA). Таким образом, держатель одного или множества идентификаторов EUI-48 в рамках IANA OUI имеет равное число изменённых идентификаторов EUI-64, которые могут формироваться вставкой FF-FE в середину идентификаторов EUI-48 и инвертированием бита X.


Некоторые изменённые идентификаторы EUI-64 в рамках IANA OUI зарезервированы для держателей адресов IPv4. Например, в 02-00-5E-FE-xx-xx-xx-xx октеты xx-xx-xx-xx указывают 32-битовый адрес IPv4. Владелец адреса IPv4 получает индивидуальный и групповой адрес EUI-64 address. Изменённые идентификаторы EUI-64 из диапазона от 02-00-5E-FE-F0-00-00-00 до 02-00-5E-FE-FF-FF-FF-FF фактически зарезервированы в ожидании спецификации адресов IPv4 класса E [RFC1112]. Однако в изменённых идентификаторах EUI-64 на основе адреса IPv4 бит universal/local следует устанавливать в соответствии с локальным или глобальным характером адреса IPv4, не забывая о том, что трактовка этого бита в изменённых идентификаторах EUI-64 обратна по отношению к обычным (неизменным) EUI-64.


2.2.2. Вопросы назначения IANA EUI-64


В таблице 3 показано распределение идентификаторов Modified EUI-64 в рамках IANA OUI. Как отмечено выше, соответствующие MAC-адреса могут формироваться добавлением бита 02 к первому октету. Во всех случаях соответствующие групповые 64-битовые адреса MAC, созданные путём добавления к первому октету бита 01, имеют такой же статус, как и указанные в таблице блоки 64-битовых индивидуальных адресов. Значения применяются с префиксом 02-00-5E для формирования изменённых адресов EUI-64.


Таблица . 64-битовые MAC-адреса IANA.


 








Адреса




Применение




Документ








00-00-00-00-00 – 0F-FF-FF-FF-FF




Резерв




RFC 9542








10-00-00-00-00 – 10-00-00-00-FF




Документация




RFC 9542








10-00-00-01-00 – EF-FF-FF-FF-FF




Не выделены













FD-00-00-00-00 – FD-FF-FF-FF-FF




Резерв




RFC 9542








FE-00-00-00-00 – FE-FF-FF-FF-FF




Держатели адресов IPv4




RFC 9542








FF-00-00-00-00 – FF-FD-FF-FF-FF




Резерв




RFC 9542








FF-FE-00-00-00 – FF-FE-FF-FF-FF




IANA EUI-48




RFC 9542








FF-FF-00-00-00 – FF-FF-FF-FF-FF




Резерв




RFC 9542








 


Выделения указанных в таблице резервных идентификаторов выполняется по процедуре IESG Ratification (параграф 5.1). Идентификаторы IANA EUI-64 в рамках IANA OUI выделяются в соответствии с указанными ниже требованиями.


    

  • 

    Назначение для стандартных целей (IETF Standard или иные стандарты, связанные с IETF).
    

    • 

  • 

    Выделение блоков размером в степень 2, начиная с границы, равной или большей степени 2, включая выделение одного (20) идентификатора.
    

    • 

  • 

    Использование для обхода требования к производителям сетевых интерфейсов получать свой блок от IEEE.
    

    • 

  • 

    Документирование в Internet-Draft или RFC.
    

    • 



Кроме того, выделение должно быть одобрено (см. процедуры в параграфе 5.1):


    

  • 

    для мелких и средних блоков из 1, 2, 4, …, 134217728, 268435456 (20, 21, 22, …, 227, 228) идентификатора EUI-64 по процедуре Expert Review (параграф 5.1).
    

    • 

  • 

    для больших блоков из 536870912 (229) и более адресов EUI-64 по процедуре IESG Ratification ( параграф 5.1).
    

    • 



2.2.3. Значения EUI-64 для документации


Ниже приведены блоки неизмененных 64-битовых адресов MAC для использования в документации. Полученные из IPv4 адреса основаны на адресах IPv4 для документации [RFC5737], а полученные из MAC – на описанных выше адресах EUI-48 для документации.


Индивидуальные адреса для документации


00-00-5E-EF-10-00-00-00 – 00-00-5E-EF-10-00-00-FF – общее назначение.


00-00-5E-FE-C0-00-02-00 – 00-00-5E-FE-C0-00-02-FF, 00-00-5E-FE-C6-33-64-00 – 00-00-5E-FE-C6-33-64-FF и 00-00-5E-FE-CB-00-71-00 – 00-00-5E-FE-CB-00-71-FF – основаны на IPv4.


00-00-5E-FF-FE-00-53-00 – 00-00-5E-FF-FE-00-53-FF – основаны на EUI-48.


00-00-5E-FE-EA-C0-00-02, 00-00-5E-FE-EA-C6-33-64 и 00-00-5E-FE-EA-CB-00-71 – групповые адреса IPv4 на основе индивидуальных адресов IPv4 [RFC6034].


Групповые адреса для документации


01-00-5E-EF-10-00-00-00 – 01-00-5E-EF-10-00-00-FF – общее назначение.


01-00-5E-FE-C0-00-02-00 – 01-00-5E-FE-C0-00-02-FF, 01-00-5E-FE-C6-33-64-00 – 01-00-5E-FE-C6-33-64-FF и 01-00-5E-FE-CB-00-71-00 – 01-00-5E-FE-CB-00-71-FF – основаны на IPv4.


01-00-5E-FE-EA-C0-00-02, 01-00-5E-FE-EA-C6-33-64 и 01-00-5E-FE-EA-CB-00-71 IPv4 – групповые адреса IPv4 на основе индивидуальных адресов IPv4 [RFC6034].


01-00-5E-FF-FE-90-10-00 – 01-00-5E-FF-FE-90-10-FF – основаны на EUI-48.


2.3. Другие 48-битовые идентификаторы MAC, применяемые IETF


Ниже описаны ещё два блока 48-битовых адресов MAC, используемые IETF.


2.3.1. Идентификаторы с префиксом 33-33


Все 48-битовые идентификаторы MAC с префиксом 33-33 (232 групповых идентификатора MAC из диапазона 33-33-00-00-00-00 – 33-33-FF-FF-FF-FF) используются в соответствии с [RFC2464] для группового обмена IPv6. Во всех этих идентификаторах бит Group (последний в первом октете) установлен (1), как это требуется для корректной работы в качестве группового идентификатора с имеющимся оборудованием. Установлен (1) также бит Local, но в Ethernet со стандартной групповой адресацией IPv6 нужно учитывать такое использование адресов. Эти групповые MAC-адреса относятся к квадранту административно назначаемых адресов SLAP (параграф 2.1.1).


Историческое замечание. При разработке IPv6 было принято использовать цифру 3 для неизвестных значений и примеров, 3333 Coyote Hill Road, Palo Alto, California – это адрес исследовательского центра Palo Alto (Palo Alto Research Center или PARC), ранее называвшегося Xerox PARC. Спецификация Ethernet была разработана Digital Equipment Corporation, Intel Corporation и Xerox Corporation. До IEEE [IEEE.802.3_2012] протокол Ethernet иногда называли DIX Ethernet по первым буквам названий этих компаний.


2.3.2. Серия CF


В информационном [RFC2153] 3-октетные значения CF-00-00 – CF-FF-FF объявлены как OUI, доступные для распределения IANA производителям программ для использования с PPP [RFC1661] или иных применений, где не требуется OUI от IEEE. При использовании в качестве 48-битовых префиксов MAC в этих значениях особые биты Z, Y, X (Local) и M (Group) в конце первого октета будут иметь значение 1, тогда как в выделенных IEEE идентификаторах OUI биты X и M сброшены (0), а во всех CID сброшены биты Y и M. Таким образом, конфликтов между OUI серии CF и выделенными IEEE значениями OUI/CID не возникает. Групповые MAC-адреса, созданные с OUI серии CF, попадают в квадрант SLAP Standard Assigned (параграф 2.1.1). Бит Group не имеет значения для PPP. В [RFC2153] сказано «Серия CF0000 была выбрана для удобства запоминания, чтобы соответствовать PPP NLPID ‘CF’». Дополнительные сведения об идентификаторах протоколов сетевого уровня (Network Layer Protocol Identifier или NLPID) приведены в [RFC6328].


CF-00-00 является зарезервированным, CF-00-00-00-00-00 – групповой идентификатор указанный IANA как используемый для шлейфовых тестов Ethernet.


За срок более 10 лет было выделено лишь несколько значений из серии CF, указанных в реестрах IANA OUI Ethernet Numbers” [EthernetNum] и Point-to-Point (PPP) Protocol Field Assignments [PPPNum].


2.3.2.1. Отличия от RFC 2153


Раздел «Взаимодействие с IANA» [RFC2153] обновлён после одобрения [RFC5342] и остаётся в этом состоянии (нет технических изменений).


    

  • 

    Использование идентификаторов серии CF, выделяемых IANA, отменено.
    

    • 

  • 

    Агентству IANA предписано в дальнейшем не выделять значений в серии CF.
    

    • 



2.4. Теги CBOR


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


Агентство IANA выделило значение 48 как тег CBOR для указания MAC-адреса. Приложенный к тегу элемент данных является строкой октетов, размер которой указывает, представлен ли 48-битовый (6 октетов) или 64-битовый (8 октетов) MAC-адрес. Если в будущем для размера адресов MAC будет применяться иное значение, кратное 8 битам, например 128 битов (16 октетов) использование тега 48 сохранится.


Тег CBOR 1048 выделен IANA для указания идентификаторов организаций OUI, CID или CF. Приложенный элемент данных является строкой из 3 октетов для размещения 24-битовых OUI и CID (параграф 2.1.2).


3. Параметры протокола Ethernet


Параметры протокола Ethernet позволяют указать в начале кадра его содержимое, например, пакет IPv4 или IPv6. Имеется два типа параметров идентификатора протокола [EthernetNum].


EtherType


16-битовый идентификатор, который при рассмотрении как целого числа без знака имеет значение не меньше 0x0600. На рисунке 2 показан простейший случай, где EtherType данных протокола в кадре указывается сразу после MAC-адресов отправителя и получателя. В [IEEE802_OandA] заданы два EtherType для локальных экспериментов – 0x88B5 и 0x88B6.


  0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Destination MAC Address                     ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Source MAC Address                          ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  EtherType (не меньше 0x0600)                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Protocol Data                               ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


Рисунок . Маркировка EtherType.



LSAP


Это 8-битовые идентификаторы протокола, размещаемые парой после поля, указывающего размер кадра. Это размер должен быть меньше 0x5DD (при рассмотрении как целого числа без знака), иначе его можно ошибочно принять за EtherType. Однако вместо размера может использоваться инкапсуляция LLC с EtherType = 0x8870 [IEEE802.1AC] в качестве индикатора незаданного размера. Значение LSAP указываются парами, где один элемент указывает обработчик протокола на стороне источника (SSAP), другой – на стороне получателя (DSAP), однако на практике разные значения этих элементов встречаются сравнительно редко. На рисунке 3 показан простейший случай, где поле размера указано сразу после MAC-адресов отправителя и получателя. На этом рисунке поле CTL (control) со значением 3 указывает службу дейтаграмм. Такой тип указания протокола иногда называют управлением логическим каналом (Logical Link Control или LLC).


  0  1  2  3  4  5  6  7  0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Destination MAC Address                     ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Source MAC Address                          ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  Frame length (или 0x8870)                    |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  DSAP                 |  SSAP                 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|  CTL = 0x03           |  Protocol Data       ///
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


Рисунок . Маркировка LSAP.



Концепция маркировки EtherType была расширена для маркировки «тегами» Ethernet. Тег Ethernet в этом смысле является префиксом, тип которого указан EtherType, за которым следует другой тег, EtherType или индикатор протокола точки доступа к сервису канального уровня (LLC Link-Layer Service Access Point или LSAP) для «основного» тела кадра. Обычно в среде [IEEE802_OandA] теги имеют фиксированный размер и не включают кодирования своего размера, Например, C-Tag (ранее Q-Tag) [IEEE.802.1Q_2014] указывает для кадра VLAN клиента и приоритет. Обрабатывающее кадр устройство в общем случае не может безопасно обрабатывать что-либо в кадре после непонятного EtherType.


Значения EtherType и LSAP не выделяются IANA, их назначает IEEE RA [IEEE_RA] (см. параграф 1.2 и Приложение B). Однако для LSAP и EtherType имеются механизмы расширения, позволяющие использовать их с 5-октетными идентификаторами протокола Ethernet в рамках OUI, включая назначенные IANA в иерархии IANA OUI.


При использовании для кадра формата IEEE 802 LLC format (Subnetwork Access Protocol (SNAP)) [IEEE802_OandA] идентификатор протокола на основе OUI можно выразить в форме xx-xx-AA-AA-03-yy-yy-yy-zz-zz, где xx-xx – размер кадра (см. выше), который должен быть достаточно малым, чтобы не путаться с EtherType, AA – октет LSAP, указывающий такое применение и иногда называемый точкой доступа к услугам SNAP (SNAP Service Access Point или SNAP SAP), 03 – октет управления LLC, указывающий службу дейтаграмм, yy-yy-yy – OUI, а zz-zz – номер протокола в рамках OUI, назначенный владельцем OUI. 5-октетный размер таких идентификаторов протокола на основе OUI с октетом управления LLC (0x03) обеспечивает выравнивание по 16-битовой границе.


При использовании EtherType для указания основного типа тела кадра доступен особый тип 0x88B7 (OUI Extended EtherType). В этом случае тело кадра может начинаться с последовательности 88-B7-yy-yy-yy-zz-zz, где yy-yy-yy и zz-zz имеют такой же смысл, как в описанном выше формате SNAP, однако для формате с EtherType = 0x88B7 не сохраняется выравнивание по 16-битовым границам.


В формате SNAP возможно использование произвольного EtherType. Это делается указанием EtherType в поле zz-zz после OUI, содержащего лишь нули (00-00-00), и имеет вид xx-xx-AA-AA-03-00-00-00-zz-zz, где zz-zz – EtherType.


Помимо маркировки содержимого кадра, тип протокола IEEE 802 указывается в сообщениях протокола распознавания следующего узла (Next Hop Resolution Protocol) [RFC2332] сетей с множественным доступом без широковещания (Non-Broadcast Multi-Access или NBMA). В таких сообщениях предусмотрены 2-октетные EtherType и типы протокола на основе OUI. 16-битовые значения EtherType присутствуют также в заголовках базовой маршрутной инкапсуляции (Generic Routing Encapsulation или GRE) [RFC2784] и базовой инкапсуляции для виртуализации сетей (Generic Network Virtualization Encapsulation или Geneve) [RFC8926].


3.1. Назначение протоколов Ethernet в иерархии IANA OUI


Доступны 2-октетные номера протоколов в рамках IANA OUI. Например, в 88-B7-00-00-5E-qq-qq или xx-xx-AA-AA-03-00-00-5E-qq-qq поле qq-qq указывает номер протокола..


Было выделено несколько значения из 216 номеров протоколов диапазона 00-00-5E-00-00 – 00-00-5E-FF-FF (см. [EthernetNum]). Крайние значения 00-00-5E-00-00 и 00-00-5E-FF-FF зарезервированы и для их назначения требуется процедура IESG Ratification (см. параграф 5.1). Назначения номеров протокола (qq-qq) в рамках IANA OUI должны удовлетворять приведённым ниже требованиям.


    

  • 

    Использование в стандарте (IETF Standard или иной стандарт, связанный с работой IETF).
    

    • 

  • 

    Наличие в протоколе поля версии с фиксированным смещением или эквивалентной маркировки, чтобы более поздние версии можно было указать понятным прежним версиям способом.
    

    • 

  • 

    Документирование в Internet-Draft или RFC.
    

    • 

  • 

    Протокол не имеет EtherType (значение EtherType моет использоваться напрямую или, в случае LSAP, – вместе с SNAP SAP путём размещения OUI 00-00-00 перед EtherType, как описано выше).
    

    • 



Кроме того, для выделения значений должна использоваться процедура Expert Review (или IESG Ratification для зарезервированных значений), как описано в параграфе 5.1.


3.2. Номер протокола для документации


Номер протокола 0x0042 в рамках IANA OUI (т. е. 00-00-5E-00-42) выделен для использования в документации.


4. Другие параметры на основе OUI/CID


В некоторых протоколах IEEE 802 и др. предусмотрены основанная на OUI или CID параметры, помимо описанных выше. Такие параметры обычно включают OUI или CID, а также 1 октет дополнительного значения. Они называются фирменными (Organizationally Specific) параметрами, а иногда (менее точно), параметрами производителя (vendor specific). Параметры имеют вид yy-yy-yy-zz, где yy-yy-yy – OUI или CID, а zz – дополнительное значение. Примером такого параметра является селектор шифра (Cipher Suite Selector) [IEEE.802.11_2012].


Значения могут выделяться в рамках IANA OUI для других параметров на основе OUI по процедуре Expert Review, за исключением того, что для дополнительных значения, содержащих только 0 (00-00-5E-00) или только 1 (00-00-5E-FF), применяется процедура IESG Ratification (параграф 5.1), а дополнительное значение 0x42 (00-00-5E-42), дополненное нулями справа для выравнивания, служит для примеров в документации.


Значения параметров на основе IANA OUI должны выделяться для стандартов (IETF Standard или иной стандарт, связанный с IETF) и документироваться в Internet-Draft или RFC. При первоначальном выделении значения для конкретного параметра создаётся реестр IANA, включающий это значение, а также последующие значения этого параметра в рамках IANA OUI. Эксперт может задать имя для такого реестра. Если для такого параметра нужны правила, отличающиеся от приведённых выше, следует подготовить (обновить) RFC со статусом BCP или Standards Track RFC с указанием новых правил и параметра.


4.1. Тип TLV для IETF LLDP


Пример такого параметра на основе IANA OUI представлен в [RFC8520]. Он включает тип Organizationally Specific TLV для анонсирования унифицированного идентификатора ресурса (Uniform Resource Locator или URL) описания использования от производителя (Manufacturer Usage Description или MUD) в протоколе IEEE для обнаружения канального уровня (Link Local Discovery Protocol или LLDP) [IEEE802.1AB]. Дополнительно в IETF предложено использование кодов из этого пространства [BGP11dp] (см. параграф 5.8.).


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


Этот документ касается взаимодействия с IANA по вопросам назначения параметров Ethernet в связи с IANA OUI и смежным вопросам.


Примечание. Группа реестров (web-страница) IANA OUI Ethernet Numbers предназначена для реестров значений в рамках IANA OUI, а группа реестров IEEE 802 Numbers содержит списки значений, выделенных IEEE RA.


Документ не создаёт новых реестров IANA и не меняет имеющихся назначений.


Значения MAC-адресов и номеров протоколов для документации выделены [RFC7042].


5.1. Expert Review и IESG Ratification


В этом параграфе заданы процедуры Expert Review и IESG Ratification для MAC, протоколов и других идентификаторов на основе IANA OUI. В качестве эксперта выступает один или несколько человек, назначенных и работающих по поручению IESG.


5.1.1. Рекомендации для Expert Review


Описанная здесь процедура Expert Review соответствует aIANA Expert Review из [RFC8126].


Несмотря на ограниченность пространства кодов MAC для выделения значений экспертами, он достаточно велик, чтобы рекомендаций этого документа и обоснованных суждений экспертов позволили распределять значения. Идея заключается в том, чтобы эксперты обеспечивали облегчённую проверку при выделении небольших блоков идентификаторов MAC и более тщательно проверяли запросы на выделение блоков MAC, идентификаторов протоколов и других параметров на основе IANA OUI средних размеров.


5.1.2. Процедуры Expert Review и IESG Ratification


Может иметь смысл выделение очень больших частей пространства идентификаторов MAC (в настоящее время выделено лишь 1 значение из пространства индивидуальных 48-битовых кодов IANA и 1 значение из 16 доступных в пространстве групповых кодов). В этих случаях, а также при выделении «резервных» значений требуется процедура IESG Ratification для Expert Review с одобрением запроса, как описано ниже. Это можно считать сочетанием процедур Expert Review и IESG Approval, заданных в [RFC8126]. Процедура IESG Approval требуется лишь в тех случаях, когда эксперты не отклоняют запрос. Сама процедура описана ниже.


Заявитель заполняет соответствующий шаблон из Приложения A и направляет его IANA по адресу <iana@iana.org>.


Агентство IANA передаёт шаблон назначенному эксперту. Если эксперт берет самоотвод или не отвечает на запрос, IANA может выбрать другого назначенного эксперта, а при его отсутствии – обратиться в IESG.


Если IANA получает неодобрение от эксперта, выбранного для рассмотрения шаблона заявки, эта заявка отклоняется. Эксперту следует указывать причину отклонения, которую IANA передаёт заявителю.


При использовании процедуры Expert Review


IANA выделяет запрошенные значения при получении одобрения и доступности запрошенных кодов.


При использовании процедуры IESG Ratification


Сначала выполняется процедура Expert Review. Если эксперты отклоняют запрос, они просто информируют IANA, а те – заявителя. Если же эксперты считают, что заявку следует одобрить, или имеются неясности и предположения о том, что следует привлечь внимание IESG, эксперты информируют IANA о своём мнении и IANA пересылает заявку вместе с мнениями экспертов в IESG. Окончательное решение о выделении значений или отказе должно приниматься IESG. Это может быть сделано через элемент управления в телечате IESG, как для других типов запросов. Если IESG не подтверждает положительное мнение экспертов или отклоняет заявку, для которой у экспертов нет уверенности, заявка отвергается. В иных случаях заявка одобряется. IESG информирует о своём решении экспертов и IANA. В случае отказа IESG следует указать его причину, которую IANA сообщает заявителю.


5.2. Смена имени группы реестров IANA (Web-страницы)


Для ясности и сходства с реестром IANA IEEE 802 Numbers группа реестров IANA Ethernet Numbers переименована в IANA OUI Ethernet Numbers.


Поскольку этот документ заменяет [RFC7042], ссылки на [RFC7042] в реестрах IANA IEEE 802 Numbers и IANA OUI Ethernet Numbers заменены ссылками на данный документ. В других реестрах IANA ссылки на [RFC7042] сохранены.


5.3. AFN и RRTYPE для MAC-адресов


Агентство IANA выделило значения Address Family Number (AFN) для MAC-адресов, как указано в таблице 4.


Таблица .


 








AFN




Десятичный




Шестнадцатеричный




Документ








48-битовый MAC




16389




0x4005




[RFC7042]








64-битовый MAC




16390




0x4006




[RFC7042]








OUI




16391




0x4007




[RFC7961]








Младшие 24 бита 48-битовых MAC-адресов – MAC/24




16392




0x4008




[RFC7961]








Младшие 40 битов 64-битовых MAC-адресов – MAC/40




16393




0x4009




[RFC7961]








 


Агентство IANA выделило значения DNS RRTYPE [RFC6895] для MAC-адресов, как указано в таблице 5.


Таблица .


 










Код RRTYPE









Данные




Обозначение




Десятичный




Шестнадцатеричный




Документ








48-битовый MAC




EUI48




108




0x006C




[RFC7043]








64-битовый MAC




EUI64




109




0x006D




[RFC7043]








 


5.4. Информационный материал группы реестров IANA


IANA поддерживает группу реестров, в настоящее время реализованную в форме web-страницы, для EtherType, OUI и групповых адресов, выделенных в рамках OUI, отличных от IANA OUI. Эта группа называется IEEE 802 Numbers. IANA обновляет сведения в реестрах при изменениях и одобрении значений экспертами.


5.5. Процесс назначения EtherType


Подача в IEEE RA заявки на выделение EtherType для протокола IETF требует процедуры IESG Approval, как указано в Приложении B. Для снижения путаницы этот процесс обычно выполняет главный эксперт реестра EtherType в группе IEEE 802 Numbers, как описано ниже (см. также параграф 5.4).


После IESG Approval для запроса EtherType IESG следует передать этот вопрос в IANA. В любом случае IANA будет просить эксперта реестра EtherType выполнить процесс запроса EtherType в IEEE RA [IEEE_RA]. Этот путь указан потому, что IESG обычно имеет дело с IANA для действий по выделению значений, а IANA следует знать, кто из экспертов реестра EtherType доступен (обычно запрос на выделение EtherType передаётся основному эксперту).


Ниже приведён примерный текст Internet-Draft, где требуется назначение от IANA и IEEE. Шаблон YYY заменяется разъяснением, для чего (почему) требуется EtherType с достаточным уровнем детализации, и обычно включает ссылки на соответствующие части Internet-Draft.


X. Assignment Considerations (вопросы назначение).


X.1. IEEE Assignment Considerations (вопросы назначения в IEEE).


IESG предлагается одобрить передачу в IEEE RA запроса на EtherType для YYY (IESG следует сообщить о свом одобрении в IANA и связанным с документом лицам; IANA пересылает IESG Approval эксперту реестра EtherType из группы IEEE 802 Numbers, который передаёт заявку в IEEE RA, информируя об этом IANA).


X.2. IANA Considerations (взаимодействие с IANA).


…


5.6. Исчерпание OUI


При исчерпании пространства индивидуальных или групповых идентификаторов EUI-48 в рамках OUI 00-00-5E на 90% и более IANA следует запросить в IEEE RA дополнительный идентификатор OUI для последующих назначений IANA. Назначенным экспертам следует контролировать распределение идентификаторов и информировать IANA о его исчерпании.


5.7. Таблица MAC-адресов IANA OUI


Этот документ вносит указанные ниже изменения в примечания к реестрам IANA Unicast 48-bit MAC Addresses, IANA Multicast 48-bit MAC Addresses и IANA 64-bit MAC Addresses. Кроме того, в этих реестрах обновляются ссылки, как указано в параграфе 5.2.


В Примечания к IANA Unicast 48-bit MAC Addresses и IANA Multicast 48-bit MAC Addresses вносится следующее изменение:


Эти значения используют префикс 00-00-5E (см. параграф 2.1.3 в RFC 9542).


В Примечания к IANA 64-bit MAC Addresses вносится следующее изменение:


Эти значения используют префикс 00-00-5E для формирования индивидуальных MAC-адресов и 01-00-5E – для групповых, а также префикс 02-00-5E для индивидуальных изменённых адресов EUI-64 и 03-00-5E – для групповых. Дополнительные сведения представлены в RFC 9542, в частности, в параграфе 2.2.2.


5.8. Субтипы IANA LLDP TLV


Агентство IANA перенесло реестр IANA Link Layer Discovery Protocol (LLDP) TLV Subtypes из группы IEEE 802 Numbers в группу IANA OUI Ethernet Numbers, поскольку коды в этом реестре назначаются IANA. Кроме того, в реестр добавлена ссылка на RFC 9542. Обновлены также три записи этого реестра, как показано в таблице 6.


Таблица .


 








Значение




Описание




Документ








0




Резерв




RFC 9542








42




Пример для использования в документации




RFC 9542








255




Резерв




RFC 9542








 


Записи для значений 1 (MUD), 2-41 (не выделены) и 43-254 (не выделены) не изменились.


5.9. Назначение тегов CBOR


Агентство IANA выделило два тега CBOR Tags в реестре Concise Binary Object Representation (CBOR) Tags (таблица 7).


Таблица .


 








Тег




Элемент данных




Назначение




Документ








48




Строка байтов




Адрес IEEE MAC




RFC 9542








1048




Строка байтов




IEEE OUI/CID




RFC 9542








 


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


Этот документ посвящено назначению параметров IEEE 802, переданных в IANA (в частности, в рамках IANA OUI), и тесно связанным с этим вопросам. Документ не оказывает прямого влияния на безопасность, за исключением указанного ниже.


Может возникать путаница и конфликты при использовании MAC-адресов или иных параметров, выведенных из OUI, в качестве примеров в документации. Примеры, которые должны использоваться лишь в документации, могут быть закодированы и выпущены или вызвать конфликты при последующем реальном использовании, а также возможном приобретении прав интеллектуальной собственности на такие адреса и параметры. Резервирование здесь MAC-адресов и параметров для документации минимизирует такую путаницу и конфликты.


MAC-адреса – это идентификаторы, представляемые устройствами в сеть. На некоторых устройствах такие адреса не являются статическими и могут настраиваться. В сетях следует проявлять осторожность при использовании таких адресов с целью соблюдения правил, поскольку адреса могут быть подделаны, а известные ранее устройства могут возвращаться в сеть с другими адресами.


MAC-адрес идентифицирует физический или виртуальный интерфейс и может применяться для отслеживания устройства с этим интерфейсом, а, следовательно, и пользователей такого устройства. В [madinas] рассматриваются связанные с этим вопросы приватности, а также обсуждается применение случайных MAC-адресов для частичного снижения такой угрозы. В [RFC7043] рассматриваются вопросы безопасности и приватности при публикации MAC-адресов в DNS.


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


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


[IEEE.802.1Q_2014] IEEE, “IEEE Standard for Local and metropolitan area networks–Bridges and Bridged Networks”, IEEE 802.1Q-2014, DOI 10.1109/ieeestd.2014.6991462, 18 December 2014, <http://ieeexplore.ieee.org/servlet/opac?punumber=6991460>.


[IEEE802.1AB] IEEE, “IEEE Standard for Local and metropolitan area networks – Station and Media Access Control Connectivity Discovery”, IEEE Std 802.1AB-2016, DOI 10.1109/IEEESTD.2016.7433915, March 2016, <https://doi.org/10.1109/IEEESTD.2016.7433915>.


[IEEE802_OandA] IEEE, “IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture”, IEEE Std 802-2014, DOI 10.1109/IEEESTD.2014.6847097, June 2014, <https://doi.org/10.1109/IEEESTD.2014.6847097>.


IEEE, “IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture — Amendment 2: Local Medium Access Control (MAC) Address Usage”, IEEE Std 802c-2017, DOI 10.1109/IEEESTD.2017.8016709, August 2017, <https://doi.org/10.1109/IEEESTD.2017.8016709>.


[RFC8126] Cotton, M., Leiba, B., and T. Narten, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.


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


[BGP11dp] Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu, “BGP Logical Link Discovery Protocol (LLDP) Peer Discovery”, Work in Progress, Internet-Draft, draft-acee-idr-lldp-peer-discovery-17, 4 January 2024, <https://datatracker.ietf.org/doc/html/draft-acee-idr-lldp-peer-discovery-17>.


[EthernetNum] IANA, “IANA OUI Ethernet Numbers”, <https://www.iana.org/assignments/ethernet-numbers>.


[IANA] IANA, “Internet Assigned Numbers Authority”, <https://www.iana.org>.


[IEEE] IEEE, “Institute of Electrical and Electronics Engineers”, <https://www.ieee.org>.


[IEEE.802.11_2012] IEEE, “IEEE Standard for Information technology–Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”, IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, 5 April 2012, <http://ieeexplore.ieee.org/servlet/opac?punumber=6178209>.


[IEEE.802.3_2012] IEEE, “IEEE Standard for Ethernet”, IEEE 802.3-2012, DOI 10.1109/ieeestd.2012.6419735, 24 January 2013, <http://ieeexplore.ieee.org/servlet/opac?punumber=6419733>.


[IEEE1394] IEEE, “IEEE Standard for a High-Performance Serial Bus”, IEEE Std 1394-2008, DOI 10.1109/IEEESTD.2008.4659233, October 2008, <https://doi.org/10.1109/IEEESTD.2008.4659233>.


[IEEE802] IEEE 802, “IEEE 802 LMSC”, <https://www.ieee802.org>.


[IEEE802.15.4] IEEE, “IEEE Standard for Low-Rate Wireless Networks”, IEEE Std 802.15.4-2020, DOI 10.1109/IEEESTD.2020.9144691, July 2020, <https://doi.org/10.1109/IEEESTD.2020.9144691>.


[IEEE802.1AC] IEEE 802, “IEEE Standard for Local and metropolitan area networks — Media Access Control (MAC) Service Definition”, IEEE Std 802.1AC-2016, DOI 10.1109/IEEESTD.2017.7875381, March 2017, <https://doi.org/10.1109/IEEESTD.2017.7875381>.


[IEEE802.1CQ] IEEE, “Draft Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment”, draft 0.8, IEEE Std 802.1CQ/D0.8, July 2022.


[IEEEtutorials] IEEE, “Guidelines for Use of Extended Unique Identifier (EUI), Organizationally Unique Identifier (OUI), and Company ID (CID)”, August 2017, <https://standards.ieee.org/wp-content/uploads/import/documents/tutorials/eui.pdf>.


[IEEE_RA] IEEE, “Registration Authority”, <https://standards.ieee.org/products-programs/regauth/>.


[IEEE_SA] IEEE, “IEEE Standards Association”, <https://standards.ieee.org>.


[InfiniBand] InfiniBand Trade Association, “InfiniBand Architecture Specification Volume 1”, November 2007, <https://www.infinibandta.org/>.


[madinas] Zúñiga, JC., Bernardos, CJ., Ed., and A. Andersdotter, “Randomized and Changing MAC Address state of affairs”, Work in Progress, Internet-Draft, draft-ietf-madinas-mac-address-randomization-12, 28 February 2024, <https://datatracker.ietf.org/doc/html/draft-ietf-madinas-mac-address-randomization-12>.


[PPPNum] IANA, “Point-to-Point (PPP) Protocol Field Assignments”, <https://www.iana.org/assignments/ppp-numbers>.


[RAC_OUI] Parsons, G., “OUI Registry Restructuring”, Work in Progress, Internet-Draft, draft-ieee-rac-oui-restructuring-01, 9 September 2013, <https://datatracker.ietf.org/doc/html/draft-ieee-rac-oui-restructuring-01>.


[RFC1112] Deering, S., “Host extensions for IP multicasting”, STD 5, RFC 1112, DOI 10.17487/RFC1112, August 1989, <https://www.rfc-editor.org/info/rfc1112>.


[RFC1661] Simpson, W., Ed., “The Point-to-Point Protocol (PPP)”, STD 51, RFC 1661, DOI 10.17487/RFC1661, July 1994, <https://www.rfc-editor.org/info/rfc1661>.


[RFC2153] Simpson, W., “PPP Vendor Extensions”, RFC 2153, DOI 10.17487/RFC2153, May 1997, <https://www.rfc-editor.org/info/rfc2153>.


[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, “NBMA Next Hop Resolution Protocol (NHRP)”, RFC 2332, DOI 10.17487/RFC2332, April 1998, <https://www.rfc-editor.org/info/rfc2332>.


[RFC2464] Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks”, RFC 2464, DOI 10.17487/RFC2464, December 1998, <https://www.rfc-editor.org/info/rfc2464>.


[RFC2606] Eastlake 3rd, D. and A. Panitz, “Reserved Top Level DNS Names”, BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, <https://www.rfc-editor.org/info/rfc2606>.


[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, “Generic Routing Encapsulation (GRE)”, RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>.


[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, “Etymology of “Foo””, RFC 3092, DOI 10.17487/RFC3092, April 2001, <https://www.rfc-editor.org/info/rfc3092>.


[RFC4291] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.


[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4”, RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>.


[RFC5214] Templin, F., Gleeson, T., and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)”, RFC 5214, DOI 10.17487/RFC5214, March 2008, <https://www.rfc-editor.org/info/rfc5214>.


[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, “MPLS Multicast Encapsulations”, RFC 5332, DOI 10.17487/RFC5332, August 2008, <https://www.rfc-editor.org/info/rfc5332>.


[RFC5342] Eastlake 3rd, D., “IANA Considerations and IETF Protocol Usage for IEEE 802 Parameters”, RFC 5342, DOI 10.17487/RFC5342, September 2008, <https://www.rfc-editor.org/info/rfc5342>.


[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, “IPv4 Address Blocks Reserved for Documentation”, RFC 5737, DOI 10.17487/RFC5737, January 2010, <https://www.rfc-editor.org/info/rfc5737>.


[RFC5798] Nadas, S., Ed., “Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6”, RFC 5798, DOI 10.17487/RFC5798, March 2010, <https://www.rfc-editor.org/info/rfc5798>.


[RFC6034] Thaler, D., “Unicast-Prefix-Based IPv4 Multicast Addresses”, RFC 6034, DOI 10.17487/RFC6034, October 2010, <https://www.rfc-editor.org/info/rfc6034>.


[RFC6328] Eastlake 3rd, D., “IANA Considerations for Network Layer Protocol Identifiers”, BCP 164, RFC 6328, DOI 10.17487/RFC6328, July 2011, <https://www.rfc-editor.org/info/rfc6328>.


[RFC6895] Eastlake 3rd, D., “Domain Name System (DNS) IANA Considerations”, BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <https://www.rfc-editor.org/info/rfc6895>.


[RFC7042] Eastlake 3rd, D. and J. Abley, “IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters”, BCP 141, RFC 7042, DOI 10.17487/RFC7042, October 2013, <https://www.rfc-editor.org/info/rfc7042>.


[RFC7043] Abley, J., “Resource Records for EUI-48 and EUI-64 Addresses in the DNS”, RFC 7043, DOI 10.17487/RFC7043, October 2013, <https://www.rfc-editor.org/info/rfc7043>.


[RFC7319] Eastlake 3rd, D., “IANA Considerations for Connectivity Fault Management (CFM) Code Points”, BCP 191, RFC 7319, DOI 10.17487/RFC7319, July 2014, <https://www.rfc-editor.org/info/rfc7319>.


[RFC7961] Eastlake 3rd, D. and L. Yizhou, “Transparent Interconnection of Lots of Links (TRILL): Interface Addresses APPsub-TLV”, RFC 7961, DOI 10.17487/RFC7961, August 2016, <https://www.rfc-editor.org/info/rfc7961>.


[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, “Recommendation on Stable IPv6 Interface Identifiers”, RFC 8064, DOI 10.17487/RFC8064, February 2017, <https://www.rfc-editor.org/info/rfc8064>.


[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.


[RFC8520] Lear, E., Droms, R., and D. Romascanu, “Manufacturer Usage Description Specification”, RFC 8520, DOI 10.17487/RFC8520, March 2019, <https://www.rfc-editor.org/info/rfc8520>.


[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed., “Geneve: Generic Network Virtualization Encapsulation”, RFC 8926, DOI 10.17487/RFC8926, November 2020, <https://www.rfc-editor.org/info/rfc8926>.


[RFC8947] Volz, B., Mrugalski, T., and C. Bernardos, “Link-Layer Address Assignment Mechanism for DHCPv6”, RFC 8947, DOI 10.17487/RFC8947, December 2020, <https://www.rfc-editor.org/info/rfc8947>.


[RFC8948] Bernardos, CJ. and A. Mourad, “Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6”, RFC 8948, DOI 10.17487/RFC8948, December 2020, <https://www.rfc-editor.org/info/rfc8948>.


[RFC8949] Bormann, C. and P. Hoffman, “Concise Binary Object Representation (CBOR)”, STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/info/rfc8949>.


Приложение A. Шаблоны


В этом приложении представлены конкретные шаблоны для назначения параметров через IANA. Приведённые в скобках пояснения могут быть удалены из шаблона перед представлением в IANA.


A.1. Шаблон идентификатора или блока идентификаторов EUI-48/EUI-64


Applicant Name:


Applicant Email:


Applicant Telephone: (с указанием кода страны)


Use Name: (короткое имя параметра, например, Foo Protocol [RFC3092])


Document: (Internet-Draft или RFC со спецификацией применения идентификатора или блока идентификаторов)


Specify whether this is an application for EUI-48 or EUI-64 identifiers:


Size of Block requested: (должен быть равен целой степени 2, включая 20)


Specify multicast, unicast, or both:


A.2. Шаблон номера протокола на основе IANA OUI/CID


Applicant Name:


Applicant Email:


Applicant Telephone: (с указанием кода страны)


Use Name: (короткое имя параметра, например, Foo Protocol)


Document: (Internet-Draft или RFC со спецификацией применения номера протокола)


Note: (любые дополнительные сведения)


A.3. Шаблон для других параметров на основе IANA OUI/CID


Applicant Name:


Applicant Email:


Applicant Telephone: (с указанием кода страны)


Protocol where the OUI/CID-Based Parameter for which a value is being requested appears: (например, выбор Cipher Suite в IEEE 802.11)


Use Name: (короткое имя для применения кода, например, Foo Cipher Suite” [RFC3092])


Document: ( Internet-Draft или RFC со спецификацией применения параметра на основе IANA OUI)


Note: (любые дополнительные сведения)


Приложение B. EtherType


В этом приложении представлена копия заявления IESG (1 мая 2023 г.) о получении новых IETF EtherType (B.1). Отметим, что имеется информационный реестр IANA для некоторых важных EtherType, заданных для протоколов IETF или IEEE 802 [IANA]. Может быть полезна также страница IEEE RA для EtherType (см. раздел 3) <https://standards.ieee.org/regauth/ethertype/eth.txt>.


B.1. Заявление IESG для EtherType


From: IESG


Date: 1 May 2023


Регистрационное агентство IEEE (IEEE RA) под надзором IEEE Registration Authority Committee (IEEE RAC) выделило значения EtherType (см. https://standards.ieee.org/products-programs/regauth/ethertype/). В спецификациях некоторых протоколов IETF применяются значения EtherType. Все случаи применения EtherType подлежат техническому рецензированию IEEE RA на предмет соответствия правилам.


Поскольку ресурс EtherType достаточно ограничен, IEEE RAC сообщает, что не будет выделять новых EtherType для спецификаций протоколов IETF, пока IESG не одобрит спецификацию протокола для публикации как RFC. В исключительных случаях IEEE RA может рассмотреть раннее выделение EtherType для находящегося в разработке протокола IETF при получении запроса, одобренного IESG.


Для информирования IEEE RAC об одобрении IESG запроса на выделение параметров Ethernet для протокола IETF все будущие запросы EtherType для протоколов IETF будут направляться в IESG.


Отметим, что EtherType для локальных экспериментов были выделены IEEE 8026 для использования в процессе разработки и экспериментах.


Приложение C. Отличия от RFC 7042


Этот документ отменяет [RFC7042] и вносит указанные ниже изменения. Тем не менее, заполненный шаблон, на основе которого было выделено значение для протокола, основанное на IANA OUI, для использования в документации, сохраняется в соответствии с Приложением C к [RFC7042].


    

  • 

    Добавлены сведения о префиксах EUI MA-M (28 битов) и MA-S (36 битов), выделяемых IEEE RA.
    

    • 

  • 

    Добавлены сведения о разделении пространства «локальных» MAC-адресов на 4 квадранта в рамках SLAP [IEEE802_OandA].
    

    • 

  • 

    Включено Заявление IESG Statement для EtherType (Приложение B.1) и более подробно описаны процедуры IETF для подачи заявок в IEEE RA на значения EtherType для использования в протоколах IETF (параграф 5.5).
    

    • 

  • 

    Упомянуты коды IEEE 802 CFM, выделенные IETF ( параграф 1.4).
    

    • 

  • 

    Упомянут элемент данных Organizationally Specific LLDP, выделенный в рамках IANA OUI, и создан реестр для будущих значений ( параграф 4.1).
    

    • 

  • 

    Уточнены некоторые детали в параграфе 5.1 для процедур Expert Review и IESG Ratification.
    

    • 

  • 

    Заданы теги CBOR для MAC-адресов и OUI/CID ( параграф 2.4).
    

    • 

  • 

    Добавлено требование к полю версии для выделения номеров протоколов в рамках IANA OUI ( параграф 3.1).
    

    • 

  • 

    Упомянуто использование EtherType в заголовках инкапсуляции Geneve [RFC8926] (раздел 3).
    

    • 

  • 

    Добавлено сочетание процедур Expert Review и IESG Approval как часть процедуры IESG Ratification.
    

    • 



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


Авторы с благодарностью принимают комментарии и предложения указанных ниже лиц.


Для текущего документа: Carsten Bormann, Bob Hinden, рабочая группа IEEE 802.1, Éric Vyncke, Dale Worley, Amanda Baber.


Для [RFC7042] (отменен этим документом): David Black, Adrian Farrel, Bob Grow, Joel Jaeggli, Pearl Liang, Glenn Parsons, Pete Resnick, Dan Romascanu.


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


Donald E. Eastlake 3rd


Independent


2386 Panoramic Circle


Apopka, Florida 32703


United States of America


Phone: +1-508-333-2270


Email: d3e3e3@gmail.com, donald.eastlake@futurewei.com


 


Joe Abley


Cloudflare


Amsterdam


The Netherlands


Phone: +31 45 56 36 34


Email: jabley@strandkip.nl


 


Yizhou Li


Huawei Technologies


101 Software Avenue


Nanjing


Jiangsu, 210012


China


Phone: +86-13809002299


Email: liyizhou@huawei.com




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


nmalykh@protokols.ru






1Internet Engineering Task Force – комиссия по решению инженерных задач Internet.






2Internet Engineering Steering Group – комиссия по инженерным разработкам Internet.






3В оригинале некорректно говорится о дополнительных октетах, см. https://www.rfc-editor.org/errata/eid7952. Прим. перев.






4Tне существует автоматизированного способа определить, настроена ли локальная сеть на SLAP и/или работу в соответствии с ним.






5Хотя в SLAP используются MAC-адреса, назначаемые локальным протоколом из квадранта SAI м назначаемые протоколом, заданным в стандарте IEEE 802, использование SLAP не является обязательным. Локальные администраторы моут использовать положения протоколов IETF из [RFC8947] и [RFC8948], которые поддерживают распределение MAC-адресов в локальном пространстве MAC с использованием DHCPv6 [RFC8415] или иного протокола.






6IEEE Std 802. IEEE standard for Local and Metropolitan Area Networks: Overview and Architecture.



 											


		
						

							Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.													

					


					

					
			




	

		
Добавить комментарий