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

Internet Engineering Task Force (IETF)                   D. Eastlake 3rd
Request for Comments: 7042                                        Huawei
BCP: 141                                                        J. Abley
Obsoletes: 5342                                                Dyn, Inc.
Updates: 2153                                               October 2013
Category: Best Current Practice
ISSN: 2070-1721

Регистрация в IANA и использование в протоколах и документации IETF параметров IEEE 802

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

PDF

Аннотация

Некоторые протоколы IETF используют форматы кадров Ethernet и параметры IEEE 802. В этом документе рассматривается использование таких параметров в протоколах IETF, описано выделение агентством IANA значений IANA OUI¹ и приведены некоторые значения для использования в документации. Данный документ заменяет RFC 5342.

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

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

Документ является результатом работы IETF² и представляет согласованный взгляд сообщества IETF. Документ прошел открытое обсуждение и был одобрен для публикации IESG³. Дополнительную информацию о BCP можно найти в разделе 2 в RFC 5741.

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

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

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

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

1. Введение

Некоторые протоколы IETF используют Ethernet и другие, связанные с IEEE 802 форматы кадров и параметры [IEEE802]. К ним относятся идентификаторы MAC⁴ и протоколов.

В этом документе рассмотрены вопросы распределения агентством IANA кодов под эгидой IANA OUI. Рассмотрены также некоторые другие применения в IETF кодов IEEE 802 и представлен ряд значений для использования в документации. Как отмечено в [RFC2606] и [RFC5737], использование резервных кодов для документации и примеров снижает вероятность конфликтов и путаницы по причине дублирования кодов, предназначенных для развертывания.

Документ [RFC5226] включен в данный документ за исключением случаев возникновения явных противоречий. В этом документе используется термин «Ратификация IESG» (IESG Ratification), описанный в параграфе 5.1. Эта процедура отличается от «Одобрения IESG» (IESG Approval) в [RFC5226].

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

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

В документе используются приведенные ниже сокращения.

   AFN    Address Family Number [RFC4760] - номер семейства адресов.
   EUI    Extended Unique Identifier - расширенный уникальный идентификатор.
   IAB    Individual Address Block - индивидуальный адресный блок.
   MAC    Media Access Control - управление доступом к среде.
   OUI    Organizationally Unique Identifier - уникальный идентификатор организации.
   RRTYPE Тип записи DNS о ресурсе [RFC6895].
   **     Возведение в степень. Например, 2**24 означает 2 в степени 24.

1.2. Отличия от RFC 5342

• Добавлены MAC-адреса и протокол на базе IANA OUI, а также другие значения для использования в документации и язык написания разделов Security Considerations (вопросы безопасности).

• Исключены все требования для параллельного выделения значений для индивидуальной (unicast) и групповой (multicast) адресации без запроса. Такие требования были включены в [RFC5342] для упрощения учета в IANA, но практика показала их неудобство.

• Пересмотрен информационный материал о правилах выделения значений IEEE с учетом [RAC-OUI].

• Добавлены AFN и RRTYPE для 48- и 64-битовых MAC.

1.3. IEEE Registration Authority

Изначально регистрация параметров Ethernet обеспечивалась Xerox Corporation, а в настоящее время это делает IEEE Registration Authority и параметры доступны на web-странице http://standards.ieee.org/regauth/

Любой может обратиться в это агентство для получения параметров. При выделении значений может взиматься плата или предъявляться другие требования, но с организаций, разрабатывающих стандарты, плата обычно не взимается.

Списки некоторых значений и их держателей можно загрузить с сайта IEEE Registration Authority.

1.4. IANA OUI

Агентству IANA выделен идентификатор OUI 00-00-5E.

В настоящее время нет выделено OUI для документации, но ниже приведены коды для документации под эгидой IANA OUI.

2. Идентификационные параметры Ethernet

В параграфе 2.1 рассмотрены MAC-идентификаторы EUI-48⁵, их связь с OUI и другими префиксами, а также назначение под эгидой IANA OUI. В параграфе 2.2 описано то же самое для идентификаторов EUI-64. В параграфе 2.3 рассматриваются другие идентификаторы IETF MAC, используемые под эгидой IANA OUI.

В [RAC-OUI] отмечено, что комитет IEEE Registration Authority изучает возможность определения нового идентификатора EUI-128.

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

48-битовые MAC-адреса чаще всего используются в качестве идентификаторов интерфейсов Ethernet. Уникальные в глобальном масштабе идентификаторы этого типа называют также EUI-48. Идентификатор EUI-48 делится на трехоктетный идентификатор OUI и дополнительные 3 октета, выделяемые держателем OUI, но может использоваться более длинный префикс организации за счет сокращения числа дополнительных битов, чтобы общий размер идентификатора составлял 48 битов. Например, IEEE выделял блоки IAB⁶, где первые 36 битов связаны с держателем IAB, который самостоятельно контролирует оставшиеся 12 битов. Однако идентификаторы IAB становятся достоянием истории, а более длинные префиксы будут доступны в [RAC-OUI].

Процедуры и правила IEEE для выделения значений идентификаторов, связанных с IEEE 802, описаны в документе [802_O&A], который время от времени пересматривается.

Два бита первого октета EUI-48 имеют в MAC-адресах специальное значение – Group (01) и Local (02). OUI и более длинные префиксы MAC назначаются с нулевым значением бита Local и не заданным значением бита Group. Групповые идентификаторы могут создаваться путем установки бита Group, а индивидуальные – путем его сброса (0).

Бит Local имеет значение 0 для уникальных в глобальном масштабе идентификаторов EUI-48, назначаемых держателем OUI или владельцем более длинного префикса. Если бит Local установлен (1), идентификатор считается в IEEE 802 локальным и находящимся под контролем местного сетевого администратора, однако могут быть выпущены рекомендации IEEE Registration Authority по управлению пространством локальных адресов. Если бит Local установлен, держатель OUI не имеет каких-либо особых полномочий применительно к первым 3 октетам идентификаторов MAC, соответствующим его OUI.

Для 48-битовых MAC-адресов выделены AFN и DNS RRTYPE (параграф 5.2).

2.1.1. Назначение EUI-48 под эгидой IANA OUI

Значение OUI 00-00-5E было выделено агентству IANA, как отмечено в параграфе 1.4. Это позволяет задать 2²⁴ групповых идентификаторов EUI-48 от 01-00-5E-00-00-00 до 01-00-5E-FF-FF-FF и 2²⁴ индивидуальных EUI-48 от 00-00-5E-00-00-00 до 00-00-5E-FF-FF-FF.

Из числа этих идентификаторов EUI-48 выделены блоки, в которых агентство IANA выделило идентификаторы для документации.

Блоки по 2⁸ индивидуальных адресов

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

используются для очень мелких назначений (уже распределены 3 из 256 значений).

00-00-5E-00-53-00 – 00-00-5E-00-53-FF

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

Групповые идентификаторы

01-00-5E-00-00-00 – 01-00-5E-7F-FF-FF

2²³ для групповой адресации IPv4 [RFC1112].

01-00-5E-80-00-00 – 01-00-5E-8F-FF-FF

2²⁰ для групповой адресации MPLS [RFC5332].

01-00-5E-90-00-00 – 01-00-5E-90-00-FF

2⁸ адресов используются для очень мелких назначений (уже распределены 4 из 256 значений).

01-00-5E-90-10-00 – 01-00-5E-90-10-FF

2⁸ адресов для документации.

Более подробную и актуальную информацию можно найти в реестре Ethernet Numbers на сайте http://www.iana.org.

2.1.2. EUI-48 для документации

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

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.3. Вопросы назначения EUI-48 в IANA

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

• Блок должен быть предназначен для целей стандартизации (IETF Standard или иной стандарт, связанный с работой IETF).

• Блок должен иметь размер, равный степени 2, начиная с границы, равной или превышающей степень 2, включая выделение одного (2⁰) идентификатора.

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

• Блок должен быть документирован в Internet-Draft или RFC.

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

мелкие и средние блоки идентификаторов EUI-48 размером 1, 2, 4, …, 32768, 65536 (2⁰, 2¹, 2², …, 2¹⁵, 216) выделяются по процедуре Expert Review (параграф 5.1);

крупные блоки из 131072 (2¹⁷) и более идентификаторов EUI-48 выделяются по процедуре IESG Ratification (параграф 5.1).

В [RFC5342] требовалось одновременное выделение индивидуальных и групповых идентификаторов в некоторых случаях, даже при использовании приложением лишь одного типа. Это требование было признано непрактичным и отменено в данном документе.

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

В IEEE также определена система 64-битовых идентификаторов MAC, включая EUI-64. Идентификаторы EUI-64 в настоящее время используются:

• в измененной форме для создания некоторых идентификаторов интерфейсов IPv6, как описано в параграфе 2.2.1;

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

• в IEEE Std 802.15.4 (называется также ZigBee);

• в [InfiniBand].

Добавления 5-октетного (40 битов) расширения к 3-октетному OUI или более короткого расширения к более длинному префиксу [RAC-OUI] с общим размером 64 бита создает идентификатор EUI-64 под эгидой данного OUI или более длинного префикса. Как и для EUI-48 первый октет содержит биты Group и Local с таким же назначением.

Для 64-битовых MAC-адресов были выделены AFN и DNS RRTYPE (параграф 5.2).

Приведенное ниже описание почти полностью относится к «модифицированной» форме идентификаторов EUI-64, однако любой, кто назначает такие идентификаторы, может использовать также не измененную форму в качестве идентификаторов MAC на каналах, использующих такие 64-битовые идентификаторы для интерфейсов.

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

Идентификаторы MAC-64 используются в виде младших 64 битов некоторых адресов IPv6 (параграф 2.5.1 и Приложение A в [RFC4291], а также Приложение A в [RFC5214]). При таком использовании идентификатор MAC-64 изменяется путем инвертирования бита Local/Global для формирования «модифицированного идентификатора IETF EUI-64». Ниже показан идентификатор Modified EUI-64 для IANA OUI, где aa-bb-cc-dd-ee – биты расширения.

      02-00-5E-aa-bb-cc-dd-ee

В первом октете указано значение 02 вместо 00, поскольку в идентификаторах Modified EUI-64 значение бита Local/Global обратно по сравнению с идентификаторами EUI-48. Это уникальные в глобальном масштабе значения, содержащие бит 02 в первом октете, тогда как сброшенный бит означает локально назначенные адреса.

Бит Local/Global был инвертирован для того, чтобы упростить сетевым операторам создание идентификаторов с локальной значимостью. Таким образом такие измененные идентификаторы EUI-64, как 1, 2 и т. п. (без ведущих нулей) являются локальными. Без изменения локальные идентификаторы должны бы были меть вид 02-00-00-00-00-00-00-01, 02-00-00-00-00-00-00-02 и т. п.

Как и для идентификаторов MAC-48 бит 01 в первом октете указывает групповой идентификатор.

Когда два первых октета расширения в идентификаторе Modified 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 имеет также такое же число идентификаторов Modified EUI-64, которые могут формироваться путем вставки октетов FF-FE посередине их идентификаторов EUI-48 и обращения бита Local/Global.

Примечание. [EUI-64] определяет биты FF-FF как используемые для создания идентификатора IEEE EUI-64 из MAC-48. Данный документ говорит, что значение FF-FE используется для идентификаторов EUI-48. IETF использует только FF-FE для создания идентификаторов Modified EUI-64 из 48-битовых идентификаторов станций Ethernet независимо от того, являются они идентификаторами EUI-48 или MAC-48. Идентификаторы EUI-48 и локальные идентификаторы MAC-48 синтаксически эквивалентны и это не вызывает проблем на практике.

Кроме того, некоторые идентификаторы Modified EUI-64 под эгидой IANA OUI зарезервированы для держателей адресов IPv4 в форме

      02-00-5E-FE-xx-xx-xx-xx

где xx-xx-xx-xx – 32-битовый адрес IPv4. Владелец адреса IPv4 имеет индивидуальный и групповой адрес EUI-64. Модифицированные идентификаторы EUI-64 из диапазона

      02-00-5E-FE-F0-00-00-00 - 02-00-5E-FE-FF-FF-FF-FF

по сути дела зарезервированы для ожидаемой спецификации адресов IPv4 класса E. Однако для идентификаторов Modified EUI-64 на базе адресов IPv4 бит Local/Global следует устанавливать в соответствии с глобальной или локальной значимостью адреса IPv4 (принимайте во внимание, что в идентификаторах Modified EUI-64 значение бита Local/Global обратно по сравнению с исходными идентификаторами MAC-64).

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

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

02-00-5E-00-00-00-00-00 - 02-00-5E-0F-FF-FF-FF-FF резерв
02-00-5E-10-00-00-00-00 - 02-00-5E-10-00-00-00-FF выделено для использования в документации
02-00-5E-10-00-00-01-00 - 02-00-5E-EF-FF-FF-FF-FF доступно для распределения
02-00-5E-F0-00-00-00-00 - 02-00-5E-FD-FF-FF-FF-FF резерв
02-00-5E-FE-00-00-00-00 - 02-00-5E-FE-FF-FF-FF-FF выделено держателям адресов IPv4 (см. выше)
02-00-5E-FF-00-00-00-00 - 02-00-5E-FF-FD-FF-FF-FF резерв
02-00-5E-FF-FE-00-00-00 - 02-00-5E-FF-FE-FF-FF-FF выделено для EUI-48 под IANA OUI (см. выше)
02-00-5E-FF-FF-00-00-00 - 02-00-5E-FF-FF-FF-FF-FF резерв

Назначение из зарезервированных диапазонов идентификаторов, показанных выше, выполняется по процедуре IESG Ratification (параграф 5.1). Назначение идентификаторов IANA EUI-64 под эгидой IANA OUI должно происходить в соответствии с приведенными ниже правилами.

• Блок должен быть предназначен для целей стандартизации (IETF Standard или иной стандарт, связанный с работой IETF).

• Блок должен иметь размер, равный степени 2, начиная с границы, равной или превышающей степень 2, включая выделение одного (2⁰) идентификатора.

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

• Блок должен быть документирован в Internet-Draft или RFC.

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

мелкие и средние блоки идентификаторов EUI-48 размером 1, 2, 4, …, 32768, 65536 (2⁰, 2¹, 2², …, 2¹⁵, 216) выделяются по процедуре Expert Review (параграф 5.1);

крупные блоки из 131072 (2¹⁷) и более идентификаторов EUI-48 выделяются по процедуре 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 [RFC6034]

      01-00-5E-FF-FE-90-10-00 - 01-00-5E-FF-FE-90-10-FF выведенные из EUI-48

2.3. Другие идентификаторы MAC-48, используемые IETF

Два других блока идентификаторов MAC-48 используются IETF, как описано ниже.

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

Все групповые идентификаторы MAC-48 с префиксом 33-33 (т. е. 2³² групповых идентификаторов MAC из диапазона 33-33-00-00-00-00 – 33-33-FF-FF-FF-FF) используются в соответствии с [RFC2464] для групповой адресации IPv6. Во всех этих идентификаторах бит Group (младший бит первого октета) установлен для обеспечения корректной работы с имеющимся оборудованием. Бит Local также установлен и используется для этой цели в сетях IPv6.

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

2.3.2. Серия CF

В информационном [RFC2153] заявлено, что 3-октетные значения от CF-00-00 до CF-FF-FF будут выделены в качестве OUI, распределяемых IANA производителям программ для применения в PPP [RFC1661] и других приложениях, где от производителя не требуется наличие выделенного IEEE значения OUI. Следует отметить, что при использовании в качестве префиксов MAC-48 в этих значениях будут установлены биты Local и Group, тогда как в выделенных IEEE значениях OUI эти биты сброшены. Бит Group не имеет смысла в PPP. В [RFC2153] сказано: «Серия CF0000 была выбрана, чтобы соответствовать PPP NLPID ‘CF’, для мнемонического удобства.»

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

За долгие годы использования серии CF было выделено лишь несколько значений (см. Ethernet Numbers <http://www.iana.org/assignments/ethernet-numbers> и PPP Numbers <http://www.iana.org/assignments/ppp-numbers>).

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

Раздел IANA Considerations в [RFC2153] был обновлен, как показано ниже, путем одобрения [RFC5342] (без технических изменений):

• использование этих идентификаторов основано на отмененных назначениях IANA;

• агентству IANA дана инструкция не выделять в дальнейшем значений из серии CF.

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

Параметры протокола Ethernet позволяют указать содержимое кадра, например, IPv4 или IPv6.

Концепция была расширена путем добавления «тегов». Тег в этом смысле является префиксом, тип которого указывается значением Ethertype, затем может следовать другой тег Ethertype или индикатор протокола LSAP⁸ для «основного» тела кадра, как описано ниже. Традиционно в мире [802_O&A] теги имеют фиксированный размер и не включают кодирования этого размера. Обрабатывающее кадр устройство в общем случае не может безопасно обрабатывать содержимое кадра после Ethertype, если значение этого поля не понятно. Примером является C-Tag (ранее Q-Tag) [802.1Q], который указывает VLAN и приоритет для кадра.

Имеется два типа параметров идентификации протокола, которые могут появляться в кадрах Ethernet после начальных идентификаторов MAC-48 для получателя и отправителя.

Ethertype

Этот 16-битовый идентификатор появляется в виде двух начальных октетов после MAC-адресов получателя и отправителя (или после тега) и рассматривается как целое число без знака со значением не меньше 0x0600.

LSAP

Эти 8-битовые идентификаторы протокола попарно присутствуют в кадре сразу после 16-битового (2 октета) поля размера кадра, который в свою очередь следует за MAC получателя и отправителя (или за тегом). Размер при его рассмотрении как целого числа без знака, будет меньше 0x5DC или может быть ошибочно принят за Ethertype. Поля LSAP присутствуют в паре, где одно предназначено для индикации обработчика протокола у отправителя, второе – у получателя, однако случаи применения двух разных обработчиков достаточно редки.

Значение Ethertype и LSAP не назначаются IANA, они находятся в ведении IEEE Registration Authority (параграф 1.3 и Приложение B). Однако LSAP и Ethertype имеют механизмы расширения, поэтому они могут быть использованы с 5-октетными идентификаторами протоколов Ethernet под эгидой OUI, включая назначенные IANA значения для IANA OUI.

При использовании формата IEEE 802 LLC⁹ (SNAP¹⁰) [802_O&A] для кадра основанный на OUI идентификатор протокола может быть представлен в виде

      xx-xx-AA-AA-03-yy-yy-yy-zz-zz

где xx-xx – размер кадра, который, как отмечено выше, должен быть достаточно малым для предотвращения путаницы с Ethertype. AA – идентификаторы LSAP, которые указывают использование формата (иногда называются SAP¹¹), 03 – октет управления LLC, указывающий службу дейтаграмм, yy-yy-yy – OUI, а zz-zz – номер протокола для данного OUI, назначаемый владельцем OUI. Нечетный 5-октетный размер для таких идентификаторов протоколов на базе OUI был выбран для того, чтобы вместе с октетом управления LLC (03) обеспечивалось выравнивание по 16-битовой границе.

При использовании Ethertype для индикации основного содержимого кадра доступно специальное значение OUI Extended Ethertype 88-B7. В этом случае начало тела кадра будет иметь вид

      88-B7-yy-yy-yy-zz-zz

где yy-yy-yy и zz-zz имеют такой смысл как для описанного выше формата SNAP.

В рамках SNAP возможно использование любого Ethertype, которое помещается в поле zz-zz после OUI 00-00-00

      xx-xx-AA-AA-03-00-00-00-zz-zz

где zz-zz означает Ethertype.

Отметим, что в настоящее время синтаксические возможности протокола 802 достаточно мощны для поддержки цепочек неограниченной длины. Необходимость поддержки таких цепочек не очевидна, но [802_O&A] требует поддерживать

         xx-xx-AA-AA-03-00-00-00-88-B7-yy-yy-yy-zz-zz

хотя это можно более эффективно выразить простой вставкой 00-00-00-88-B7 посредине.

Помимо маркировки содержимого кадра тип протокола 802 появляется в сообщениях NBMA¹² NHRP¹³ [RFC2332]. В таких сообщениях указываются двухоктетные значения Ethertype и типа протокола на базе OUI.

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

Двухоктетные номера протоколов для IANA OUI доступны в виде

      xx-xx-AA-AA-03-00-00-5E-qq-qq

где qq-qq — номер протокола.

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

• Номер должен быть предназначен для целей стандартизации (IETF Standard или иной стандарт, связанный с работой IETF).

• Номер должен быть документирован в Internet-Draft или RFC.

• Такие номера не выделяются для протоколов, имеющих Ethertype (поскольку они могут быть выражены указанием OUI, включающим только 0 перед Ethertype, как описано выше).

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

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

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

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

Некоторые протоколы IEEE 802 и другие протоколы имеют основанные на OUI параметры, не описанные выше. Такие параметры обычно включают OUI и один октет дополнительного значения. Обычно их называют «фирменными» параметрами (vendor specific, хотя точнее было бы сказать organization specific). Эти параметры имеют вид

      yy-yy-yy-zz

где yy-yy-yy — OUI, zz — дополнительное значение. Примером может служить селектор шифра (Cipher Suite Selector) в IEEE [802.11].

Значения могут выделяться под эгидой IANA OUI для таких параметров на базе OUI по процедуре Expert Review за исключением значений, в которых дополнительный октет содержит только 0 или только 1 (0x00 – 00-00-5E-00 и 0xFF — 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 должен быть выпущен заново или обновлен с учетом этих правил.

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

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

Поскольку этот документ является заменой [RFC5342], ссылки на [RFC5342] в реестрах IANA заменены ссылками на данный документ. Кроме того, все ссылки на [DOC-ADDR] в реестрах, которые включены в данный документ, также заменены ссылками на этот документ.

Документ не создает новых реестров IANA.

Документ выделяет значения MAC-адресов для документации. Эти значения были выделены ранее в [DOC-ADDR], поэтому, как отмечено выше, все ссылки в реестрах на [DOC-ADDR] заменены ссылками на этот документ.

Единственным дополнительным назначением, сделанным в этом документе, является номер протокола для документации (параграф 5.6).

Документ не меняет выполненных ранее назначений.

5.1. Рецензия экспертов и ратификация IESG

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

Процедура Expert Review, описанная здесь, полностью соответствует процедуре IANA Expert Review из [RFC5226].

Пространства, из которых выделяются значения, хотя и конечны, но достаточно велики, поэтому рецензии экспертов достаточно для выделения значений. Идея состоит в том, чтобы эксперт обеспечивал упрощенный контроль для небольших назначений идентификаторов EUI, обращая повышенное внимание на выделение блоков среднего размера для EUI, идентификаторов протоколов и других параметров на базе IANA OUI. Тем не менее, имеет смысл выделять очень большие части пространства идентификаторов MAC (отметим, что имеющиеся назначения включают один блок в половину доступного пространства групповых IANA EUI-48 и один блок размером в 1/16 этого пространства). В таких случаях и при выделении резервных значений должна применяться ратификация IESG после процедуры Expert Review в соответствии с приведенным ниже описанием.

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

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

В любом случае при получении от эксперта отрицательного отзыва выделение значений будет отвергнуто.

Для процедуры Expert Review:

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

Для процедуры IESG Ratification:

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

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

Агентство IANA выделило значения номеров семейств адресов (AFN) для MAC-адресов, показанные в таблице.

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

EUI48

0x006C

EUI64

0x006D

5.3. Информационная Web-страница IANA

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

5.4. Нехватка OUI

Когда пространство индивидуальных или групповых идентификаторов EUI-48 для OUI 00-00-5E будет заполнено на 90% или более, IANA следует запросить дополнительное значение OUI в IEEE Registration Authority для распределения в рамках IANA. Заполнение пространства следует контролировать назначенному эксперту или экспертом и уведомлять IANA о нехватке свободного пространства.

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

В таблицах IANA Unicast 48-bit MAC Addresses и IANA Multicast 48-bit MAC Addresses были изменены лишь ссылки, как указано в начале раздела 5.

5.6. Таблица и назначение номеров протоколов SNAP

Таблица идентификаторов протоколов SNAP (SNAP PROTOCOL Ids) переименована в SNAP Protocol Numbers (номера протоколов SNAP). Вместо PID используется номер протокола (Protocol Number).

Агентство IANA выделило значение 0x0042 в качестве номера протокола SNAP под эгидой IANA OUI для использования в документации.

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

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

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

В [RFC7043] рассмотрены вопросы безопасности при хранении MAC-адресов в DNS.

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

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

Данный документ:

David Black, Adrian Farrel, Bob Grow, Joel Jaeggli, Pearl Liang, Glenn Parsons, Pete Resnick, Dan Romascanu.

RFC 5342:

Bernard Aboba, Scott O. Bradner, Ian Calder, Michelle Cotton, Lars Eggert, Eric Gray, Alfred Hoenes, Russ Housley, Charlie Kaufman, Erik Nordmark, Dan Romascanu, Geoff Thompson, Mark Townsley.

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

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

[802_O&A] “IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture”, IEEE Std 802-2001, 8 March 2002.

“IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture / Amendment 1: Ethertypes for Prototype and Vendor-Specific Protocol Development”, IEEE Std 802a-2003, 18 September 2003.

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

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

[802.1Q] “IEEE Standard for Local and metropolitan area networks / Media Access Control (MAC) Bridges and Virtual Bridge Local Area Networks”, IEEE Std 802.1Q-2011, 31 August 2011.

[802.3] “IEEE Standard for Ethernet”, IEEE Std 802.3-2012, 28 December 2012.

[802.11] “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 Std 802.11-2012, 29 March 2012.

[DOC-ADDR] Abley, J., “EUI-48 and EUI-64 Address Assignments for use in Documentation”, Work in Progress, March 2013.

[EUI-64] IEEE Registration Authority, “Guidelines for 64-bit Global Identifier (EUI-64(TM))”, <http://standards.ieee.org/regauth/oui/tutorials/EUI64.html>, November 2012.

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

[IEEE802] IEEE 802 LAN/MAN Standards Committee, <http://www.ieee802.org>.

[InfiniBand] InfiniBand Trade Association, “InfiniBand Architecture Specification Volume 1”, November 2007.

[RAC-OUI] Parsons, G., “OUI Registry Restructuring”, Work in Progress, September 2013.

[RFC1112] Deering, S., “Host extensions for IP multicasting”, STD 5, RFC 1112, August 1989.

[RFC1661] Simpson, W., Ed., “The Point-to-Point Protocol (PPP)”, STD 51, RFC 1661, July 1994.

[RFC2153] Simpson, W., “PPP Vendor Extensions”, RFC 2153, May 1997.

[RFC2332] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, “NBMA Next Hop Resolution Protocol (NHRP)”, RFC 2332, April 1998.

[RFC2464] Crawford, M., “Transmission of IPv6 Packets over Ethernet Networks”, RFC 2464, December 1998.

[RFC2606] Eastlake 3rd, D. and A. Panitz, “Reserved Top Level DNS Names”, BCP 32, RFC 2606, June 1999.

[RFC3092] Eastlake 3rd, D., Manros, C., and E. Raymond, “Etymology of “Foo””, RFC 3092, April 1 2001.

[RFC4291] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291, February 2006.

[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, “Multiprotocol Extensions for BGP-4”, RFC 4760, January 2007.

[RFC5214] Templin, F., Gleeson, T., and D. Thaler, “Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)”, RFC 5214, March 2008.

[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, “MPLS Multicast Encapsulations”, RFC 5332, August 2008.

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

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, “IPv4 Address Blocks Reserved for Documentation”, RFC 5737, January 2010.

[RFC5798] Nadas, S., Ed., “Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6”, RFC 5798, March 2010.

[RFC6034] Thaler, D., “Unicast-Prefix-Based IPv4 Multicast Addresses”, RFC 6034, October 2010.

[RFC6895] Eastlake 3rd, D., “Domain Name System (DNS) IANA Considerations”, BCP 42, RFC 6895, April 2013.

[RFC7043] Abley, J., “Resource Records for EUI-48 and EUI-64 Addresses in the DNS”, RFC 7043, October 2013.

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

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

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

Имя заявителя:
Электронная почта:
Телефон заявителя: (с кодом страны)
Применение: (краткое описание использования параметра типа «Foo Protocol» [RFC3092])
Документ: (ID или RFC, задающий приложение, для которого выделяется идентификатор или блок идентификаторов).
Тип используемого приложением идентификатора: EUI-48 или EUI-64:
Размер запрашиваемого блока: (должен быть степенью 2, включая 1 идентификатор)
Тип: индивидуальный, групповой или оба.

A.2. Шаблон для номера протокола на базе IANA OUI

Имя заявителя:
Электронная почта:
Телефон заявителя: (с кодом страны)
Применение: (краткое описание использования кода типа «Foo Protocol»)
Документ: (ID или RFC, задающий приложение, для которого выделяется идентификатор протокола).
Примечание: (дополнительная информация).

A.3. Шаблон для прочих параметров на базе IANA OUI

Имя заявителя:
Электронная почта:
Телефон заявителя: (с кодом страны).
Протокол, в котором используется запрошенное значение параметра на базе OUI: (типа выбора шифра в IEEE 802.11).
Применение: (краткое описание использования кода типа «Foo Cipher Suite» [RFC3092]).
Документ: (ID или RFC, задающий приложение, для которого выделяется параметр на базе IANA OUI).
Примечание: (дополнительная информация).

Приложение B. Значения Ethertype

В этом приложении указаны некоторые значения Ethertype, заданные для протоколов IETF или IEEE 802 и известные на момент публикации. Актуальный список доступен на сайте IANA [IANA]. Может быть полезна также страница IEEE Registration Authority для значений Ethertype http://standards.ieee.org/regauth/ethertype/eth.txt. См. Также раздел 3 выше.

B.1. Некоторые значения Ethertype, заданные IETF

0x0800  Internet Protocol Version 4 (IPv4)
0x0806  Address Resolution Protocol (ARP)
0x0808  Frame Relay ARP
0x22F3  TRILL
0x22F4  L2-IS-IS
0x8035  Reverse Address Resolution Protocol (RARP)
0x86DD  Internet Protocol Version 6 (IPv6)
0x880B  Point-to-Point Protocol (PPP)
0x880C  General Switch Management Protocol (GSMP)
0x8847  MPLS
0x8848  MPLS with upstream-assigned label
0x8861  Multicast Channel Allocation Protocol (MCAP)
0x8863  PPP over Ethernet (PPPoE) Discovery Stage
0x8864  PPP over Ethernet (PPPoE) Session Stage
0x893B  TRILL Fine Grained Labeling (FGL)
0x8946  TRILL RBridge Channel

B.2. Некоторые значения IEEE 802 Ethertype

0x8100  IEEE Std 802.1Q   Customer VLAN Tag Type (C-Tag14) (изначально Wellfleet)
0x8808  IEEE Std 802.3    Ethernet Passive Optical Network (EPON)
0x888E  IEEE Std 802.1X   Управление доступом в сеть на уровне порта
0x88A8  IEEE Std 802.1Q   Идентификатор тега Service VLAN (S-Tag)
0x88B5  IEEE Std 802      Ethertype для локальных экспериментов
0x88B6  IEEE Std 802      Ethertype для локальных экспериментов
0x88B7  IEEE Std 802      OUI Extended Ethertype
0x88C7  IEEE Std 802.11   Pre-Authentication (802.11i)
0x88CC  IEEE Std 802.1AB  Протокол определения канального уровня (LLDP15)
0x88E5  IEEE Std 802.1AE  Media Access Control Security
0x88F5  IEEE Std 802.1Q   Multiple VLAN Registration Protocol (MVRP)
0x88F6  IEEE Std 802.1Q   Multiple Multicast Registration Protocol (MMRP)
0x890D  IEEE Std 802.11   Fast Roaming Remote Request (802.11r)
0x8917  IEEE Std 802.21   Media Independent Handover Protocol
0x8929  IEEE Std 802.1Qbe Multiple I-SID Registration Protocol
0x8940  IEEE Std 802.1Qbg Протокол ECP (используется также в 802.1BR)

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

Ниже приведен шаблон, на основе которого был назначен номер протокола, основанного на IANA OUI, для использования в документации (см. раздел 3 и Приложение A.2.)

Имя заявителя: Donald E. Eastlake 3rd
Электронная почта: d3e3e3@gmail.com
Телефон заявителя: 1-508-333-2270
Применение: документация
Документ: данный документ
Примечание: запрошено значение 0x0042

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

Donald E. Eastlake 3rd

Huawei Technologies

155 Beaver Street

Milford, MA 01757

USA

Phone: +1-508-634-2066

EMail: d3e3e3@gmail.com

Joe Abley

Dyn, Inc.

470 Moore Street

London, ON N6C 2C2

Canada

Phone: +1 519 670 9327

EMail: jabley@dyn.com

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

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

nmalykh@gmail.com