RFC 8948 Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6

Опубликовано 14.12.2020 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                     CJ. Bernardos
Request for Comments: 8948                                          UC3M
Category: Standards Track                                      A. Mourad
ISSN: 2070-1721                                             InterDigital
                                                           December 2020

Structured Local Address Plan (SLAP) Quadrant Selection Option for DHCPv6

Опция выбора квадранта SLAP для DHCPv6

PDF

Аннотация

Пространство 48-битовых адреса IEEE MAC1 исходно было разделено на 2 половины, одна из которых предназначена для локального использования. В 2017 г. был опубликован новый стандарт IEEE Std 802c с необязательным планом структурированных локальных адресов (Structured Local Address Plan — SLAP), задающим разный подход к распределению адресов из 4 указанных областей локального пространства MAC-адресов.

В IEEE разрабатываются протоколы для назначения адресов (IEEE P802.1CQ). В рамках IETF также ведется работа по определению новых механизмов для расширения операций DHCPv6 в части выделения локальных MAC-адресов.

Этот документ представляет расширение протоколов DHCPv6, позволяющее клиенту или ретранслятору DHCPv6 указать серверу предпочтительный квадрант SLAP, из которого могут быть назначены адреса, запрошенные клиентом или ретранслятором. Для этого определена новая опция DHCPv6 – QUAD.

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

Документ относится к категории Internet Standards Track.

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

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

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

Авторские права (Copyright (c) 2020) принадлежат 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. Введение

Пространство 48-битовых адресов IEEE MAC разделено так, что одна половина предназначена для локального использования (бит Universal/Local (U/L) имеет значение 1). В 2017 г. был опубликован новый стандарт IEEE [IEEEStd802c], определяющий новый необязательный план структурированных локальных адресов (SLAP), который задает разный подход к назначению адресов в 4 заданных областях локальных адресов MAC. Эти 4 области, названные квадрантами SLAP, кратко описаны ниже (см. рисунок 1 и таблицу 1).

  • В квадранте SLAP 01 с расширенным локальным идентификатором (Extended Local Identifier или ELI) MAC-адреса назначаются на основе 24-битового идентификатора компании (Company ID – CID), выделенного IEEE Registration Authority (RA). Оставшиеся биты указываются как расширение уполномоченным CID или протоколом, назначенным им.

  • В квадранте SLAP 11 со стандартным идентификатором (Standard Assigned Identifier – SAI) MAC-адреса назначаются на основе протокола, заданного стандартом IEEE 802. Для 48-битовых MAC-адресов доступно 44 бита. Для назначения SAI в стандартах IEEE может быть задано множество протоколов. Сосуществование разных протоколов может поддерживаться ограничением доступного протоколу подпространства адресов.

  • В квадранте SLAP 00 с административно назначенным идентификатором (Administratively Assigned Identifier – AAI) MAC-адреса назначаются администратором локально. Групповые пакеты IPv6 используют адреса получателей, начинающиеся с 33-33, поэтому адреса AAI из этого диапазона не следует выделять. Для 48-битовых MAC-адресов доступно 44 бита.

  • В резервном квадранте SLAP 10 адреса MAC могут назначаться с помощью новых метолов (еще не заданы) или администратором как в квадранте AAI. Для 48-битовых MAC-адресов доступно 44 бита.

LSB                MSB
M  X  Y  Z  -  -  -  -
|  |  |  |
|  |  |  +------------ SLAP бит Z
|  |  +--------------- SLAP бит Y
|  +------------------ бит X (U/L) = 1 для локальных адресов
+--------------------- бит M (I/G) (unicast/group)

LSB - Least Significant Bit (младший бит)
MSB - Most Significant Bit (старший бит)

Рисунок 1. Структура 48-битового MAC-адреса (представления IEEE).


Таблица 1. Квадранты SLAP.

Квадрант

Бит Y

Бит Z

Тип локального идентификатора

Локальный идентификатор

01

0

1

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

ELI

11

1

1

Стандартное назначение

SAI

00

0

0

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

AAI

10

1

0

Резерв

Резерв

1.1. Постановка задачи

В IEEE разрабатываются механизмы назначения адресов [IEEE-P802.1CQ-Project]. В [RFC8947] задано новое расширение DHCPv6 для обработки назначения локальных MAC-адресов. Этот документ предлагает расширение протокла DHCPv6, позволяющее клиентам и ретрансляторам DHCPv6 указать серверу предпочтительный квадрант SLAP для назначения MAC-адресов.

Ниже описаны 2 варианта, где имеется потребность выделения локальных MAC-адресов из заданного квадранта SLAP.

1.1.1. Устройства Wi-Fi (IEEE 802.11)

Сегодня большинство устройств Wi-Fi поставляются с интерфейсами, имеющими «вшитый» MAC-адрес из универсального пространства, распределяемого с помощью 24-битовых уникальных идентификаторов организаций (Organizationally Unique Identifier – OUI), выдаваемых производителям интерфейсов IEEE 802. Однако недавно возникла потребность локального (взамен универсального) назначения MAC-адресов, вызванная указанными ниже сценариями.

  • IoT (Internet of Things – Интернет вещей) используют в основном устройства с ограниченными возможностями [RFC7228] в части питания, памяти и ресурсов обработки. Примерами служат датчики и исполнительные механизмы для здравоохранения или домашней автоматизации. Учитывая рост числа таких устройств, производители могут предпочесть установку для них временных MAC-адресов, используемых лишь при первой загрузке. Эти временные адреса служат лишь для отправки начальных пакетов DHCP доступным серверам. Устройствам IoT обычно нужен 1 MAC-адрес для каждого доступного сетевого интерфейса. После назначения сервером MAC-адреса устройство откажется от временного адреса. Устройства IoT для домашней автоматизации обычно не перемещаются (хотя следует отметить рост числа мобильных интеллектуальных устройств для охраны здоровья). Для таких устройств обычно подходит любой квадрант SLAP, но квадранты ELI и SAI в некоторых случаях будут лучше. Например, устройству может потребоваться адрес из CID, выделенного производителю коммуникационного устройства IoT, а не адрес из квадранта ELI.

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

1.1.2. Гипервизор – возможность перемещения функций

В больших средах виртуализации могут быть активны тысячи виртуальных машин (VM), которые обычно управляются гипервизором, запускающим и останавливающим VM при необходимости. Обычно гипервизор назначает и новые MAC-адреса для VM. Если для этого служит сервер DHCP, гипервизор выступает клиентом DHCP и запрашивает у доступных серверов DHCP назначение одного или множества (блок) MAC-адресов. Гипервизор не использует эти адреса для себя, а назначает их создаваемым VM. В современных ЦОД часто используется деление сети на области, каждая из которых назначает свои адреса. В этом варианте следует рассмотреть два случая, описанных ниже.

  • Перемещаемые функции. Если VM (обеспечивающую функцию) нужно перенести в другую область ЦОД (например, для обслуживания, обеспечения отказоустойчивости, перемещения конечного пользователя и пр.), вместе с VM нужно перенести ее сетевой контекст, включая MAC-адреса VM. Поскольку назначение адресов из квадрантов ELI/SAI подчиняется правилам IEEE Std 802c, они лучше подходят для обеспечения уникальности MAC-адресов в рамках ЦОД.

  • Неперемещаемые функции. Если VM не перемещается в другую область ЦОД, связанных с MAC-адресом требований не возникает. В этом случае проще выделять адреса из квадранта AAI, которые не обязаны быть уникальными в рамках множества ЦОД (т. е. каждая область может управлять своим назначением MAC-адресов без глобальной проверки дубликатов).

2. Терминология

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

Когда возможно, в документе используются относящиеся к задаче термины из [RFC8415]. Ниже приведены определения терминов, которые отличаются от указанного документа или введены заново.

address – адрес

Если явно не указано иное, это адрес канального уровня (MAC-адрес) [IEEEStd802] размером 6 или 8 октетов.

address block – блок адресов

Множество последовательных адресов канального уровня. Блок указывается первым адресом и числом дополнительно выделяемых адресов. Один адрес можно представить блоком из этого адреса и 0 дополнительных.

client – клиент

Узел, заинтересованный в получении адреса канального уровня. Он реализует базовые механизмы DHCP, описанные в [RFC8415], и поддерживает новые опции, заданные [RFC8947] (IA_LL и LLADDR), а также этим документом (QUAD). Клиент может поддерживать назначение адресов IPv6 и делегирование префиксов в соответствии с [RFC8415].

IA_LL

Identity Association для Link-Layer Address – ассоциация отождествления (IA – identity association), используемая для запроса или назначения адресов канального уровня (параграф 11.1 [RFC8947]).

LLADDR

Опция адреса канального уровня, используемая для запроса или назначения блока адресов (параграф 11.2 [RFC8947]).

relay – ретранслятор

Узел, служащий посредником при доставке сообщений DHCP между клиентами и серверами. Ретранслятор на основе локальной информации и правил может указывать предпочтительный квадрант SLAP в передаваемой серверу опции QUAD. Ретранслятор реализует базовую фцнкциональность агента трансляции DHCPv6 [RFC8415].

server – сервер

Узел, который поддерживает назначение адресов канального уровня и способен отвечать на запросы клиентов. Узел реализует базовую функциональность сервера DHCP [RFC8415] и поддерживает новые опции, заданные [RFC8947] (IA_LL и LLADDR), а также этим документом (QUAD). Сервер может поддерживать назначение адресов IPv6 и делегирование префиксов в соответствии с [RFC8415].

3. Расширения DHCPv6

3.1. Назначение адресов из квадранта SLAP, указанного клиентом

Далее описаны операции протокола для выбора клиентом предпочтительного квадранта SLAP с помощтю сигнальных процедур DHCPv6, описанных в [RFC8947] и показанных на рисунке 2.


+--------+                            +--------+
| Клиент |                            | Сервер |
| DHCPv6 |                            | DHCPv6 |
+--------+                            +--------+
    |                                      |
    +----1. Solicit(IA_LL(LLADDR,QUAD))--->|
    |                                      |
    |<--2. Advertise(IA_LL(LLADDR,QUAD))---+
    |                                      |
    +---3. Request(IA_LL(LLADDR,QUAD))---->|
    |                                      |
    |<------4. Reply(IA_LL(LLADDR))--------+
    |                                      |
    .     (завершен отсчет таймера)        .
    |                                      |
    +---5. Renew(IA_LL(LLADDR,QUAD))------>|
    |                                      |
    |<-----6. Reply(IA_LL(LLADDR))---------+
    |                                      |

Рисунок 2. Поток сигнализации DHCPv6 (клиент-сервер).

  1. Адреса канального уровня (MAC) выделяются блоками, начиная с одного. Для запроса адресов клиент передает сообщение Solicit с опцией IA_LL, которая должна включать опцию LLADDR. Для указания предпочтительного квадранта SLAP опция IA_LL включает новую опцию OPTION_SLAP_QUAD в поле IA_LL-option (наряду с опцией LLADDR).

  2. Сервер при получении опции IA_LL в сообщении Solicit проверяет ее содержимое. Для каждой записи в OPTION_SLAP_QUAD в порядке значений поля preference (от большего к меньшему) сервер проверяет наличие настроенного пула адресов MAC, соответствующего запрошенному квадранту, и наличие доступного блока адресов запрошенного размера. Если подходящие адреса найдены, сервер передает сообщение Advertise с опцией IA_LL, содержащей опцию LLADDR, которая указывает предлагаемые адреса. Если у сервера есть блк адресов в указанном квадранте, должны предлагаться адреса из этого квадранта. Если соответствующих запросу клиента адресов нет у сервера, ему следует возвратить опцию IA_LL с адресами из поддерживаемого сервером квадранта (в соответствии с локальной политикой выбора квадранта). Если у сервера есть пул адресов в запрошенном квадранте, но в нем нет доступных адресов, сервер должен вернуть опцию IA_LL, где Status Code имеет значение NoAddrsAvail.

  3. Клиент ждет от доступных серверов откликов Advertise и выбирает один сервер, как указано в параграфе 18.2.9 [RFC8415]. Клинету не следует выбирать сервер, которые не анонсировал адреса из запрошенного квадранта. Затем клиент передает сообщение Request, включающее контейнер IA_LL с опцией LLADDR, скопированной из сообщения Advertise от выбранного сервера, указав предпочтительные квадранты SLAP в новой опции QUAD IA_LL.

  4. При получении Request с контейнером IA_LL сервер назначает запрошенные адреса, при этом он может изменить выделение (например, уменьшить блок). Затем сервер создает и отправляет клиенту сообщение Reply. При получении Reply клиент анализирует контейнер IA_LL и может начинать использование назначенных ему адресов. Отметим, что клиент, включивший опцию Rapid Commit в сообщение Solicit, может получить в ответ сообщение Reply и пропустить описанные выше этапы Advertise и Request (следуя стандартным процедурам DHCPv6).

  5. Предполагается, что клиент будет периодически обновлять адреса канального уровня по таймерам T1 и T2. Этот механизм можно отключить административно путем отправки сервером «бесконечного» (infinity) значения для T1 и T2 (см. раздел 7.7 в [RFC8415]). Клиент передает опцию Renew по таймеру T1, включая предпочтительные квадранты в новую опцию QUAD IA_LL, чтобы в случае неспособности сервера расширить срок действия имеющихся адресов он знал предпочтительные квадранты для выделения других адресов.

  6. Сервер отвечает сообщением Reply с опцией IA_LL, включающей опцию LLADDR с расширенным сроком.

Клиенту следует проверять принадлежность MAC-адреса к одному из запрошенных квадрантов. Клиент может повторить процесс выбора сервера DHCP.

3.2. Назначение адресов из квадранта SLAP, указанного ретранслятором

Далее описана работа протокола по выбору предпочтительного квадранта по запросу ретранслятора с помощью сигнальных процедур DHCPv6, описанных в [RFC8947]. Это полезно при работе сервера DHCPv6 в большой инфраструктуре, разделенной на области с разными требованиями. Поток сигналов показан на рисунке 3.

  1. +--------+                  +--------+                     +--------+
| Клиент |                  |Ретранс.|                     | Сервер |
| DHCPv6 |                  | DHCPv6 |                     | DHCPv6 |
+--------+                  +--------+                     +--------+
   |                            |                                |
   +-----1. Solicit(IA_LL)----->|                                |
   |                            +----2. Relay-forward            |
   |                            |    (Solicit(IA_LL),QUAD)------>|
   |                            |<---3. Relay-reply              |
   |                            |    (Advertise(IA_LL(LLADDR)))--+
   |<4. Advertise(IA_LL(LLADDR))+                                |
   |-5. Request(IA_LL(LLADDR))->|                                |
   |                            +-6. Relay-forward               |
   |                            | (Request(IA_LL(LLADDR)),QUAD)->|
   |                            |                                |
   |                            |<--7. Relay-reply               |
   |                            |   (Reply(IA_LL(LLADDR)))-------+
   |<--8. Reply(IA_LL(LLADDR))--+                                |
   |                            |                                |
   .               (завершен отсчет таймера)                     .
   |                            |                                |
   +--9. Renew(IA_LL(LLADDR))-->|                                |
   |                            |--10. Relay-forward             |
   |                            |  (Renew(IA_LL(LLADDR)),QUAD)-->|
   |                            |<---11. Relay-reply             |
   |                            |     (Reply(IA_LL(LLADDR)))-----+
   |<--12. Reply(IA_LL(LLADDR))-+                                |
   |                            |                                |

    Рисунок 3. Поток сигнализации DHCPv6 (клиент-ретранслятор-сервер).


    Адреса канального уровня (MAC) выделяются блоками, начиная с одного. Для запроса адресов клиент передает сообщение Solicit с опцией IA_LL, которая должна включать опцию LLADDR.

  2. Ретранслятор DHCP получает сообщение Solicit и инкапсулирует его в Relay-forward. Ретранслятор на основе локальных сведений и правил включает в сообщение Relay-forward опцию QUAD с предпочтительным квадрантом. Ретранслятор может знать, какой квадрант следует запросить, из локальной конфигурации (например, обслуживаемая сеть содержит лишь устройства IoT и запрашивать следует ELI/SAI) или иных данных. Отметим, что при передаче клиентом множества опций IA_LL в одном сообщении, ретранслятор DHCP может добавить лишь один экземпляр опции QUAD.

  3. При получении ретранслированного сообщения с опцией IA_LL сервер проверяет содержимое экземпляров OPTION_SLAP_QUAD в сообщении Relay-forward и вложенном в него клиентском сообщении. В зависимости от правил сервера выбирается экземпляр опции для обработки при выборе (см. конец этот параграфа). Для каждой записи в OPTION_SLAP_QUAD в порядке значений поля (от высшего к низшему) сервер проверяет наличие настроенного пула адресов MAC, соответствующего запрошенному квадранту, и наличие доступного блока адресов запрошенного размера. Если подходящие адреса найдены, сервер передает сообщение Advertise с опцией IA_LL, содержащей опцию LLADDR, которая указывает предлагаемые адреса. Это сообщение передается ретранслятору в сообщении Relay-reply. Если сервер поддерживает семантику предпочтительного квадранта из опции QUAD и поддерживает блок адресов в этом квадранте, он должен предлагать адреса из запрошенного квадранта. Серверу следует применять содержимое представленной ретранслятором опции QUAD для всех клиентских IA_LL, если в конфигурации не задано иное.

  4. Ретранслятор передает клиенту полученное сообщение Advertise.

  5. Клиент ждет от доступных серверов откликов Advertise и выбирает один сервер, как указано в параграфе 18.2.9 [RFC8415]. Затем клиент передает сообщение Request, включающее контейнер IA_LL с опцией LLADDR, скопированной из сообщения Advertise от выбранного сервера.

  6. Ретранслятор пересылает полученное сообщение Request в сообщении Relay-forward, доавляя опцию QUAD IA_LL с предпочитаемым квадрантом.

  7. При получении пересланного сообщения Request с контейнером IA_LL сервер назначает запрошенные адреса, которые он может изменить. Затем сервер создает и передает сообщение Reply ретранслятору в Relay-reply.

  8. При получении сообщения Reply клиент разбирает контейнер IA_LL и может начать использование адресов.

  9. Предполагается, что клиент будет периодически обновлять адреса канального уровня по таймерам T1 и T2. Этот механизм можно отключить административно путем отправки сервером «бесконечного» (infinity) значения для T1 и T2 (см. раздел 7.7 в [RFC8415]). Клиент передает опцию Renew по таймеру T1.

  10. Это сообщение пересылается ретранслятором в сообщении Relay-forward с опцией QUAD IA_LL, указывающей предпочтительный квадрант.

  11. Сервер отвечает сообщением Reply с опцией IA_LL, включающей опцию LLADDR с расширенным сроком, которое передается в сообщении Relay-reply.

  12. Ретранслятор передает сообщение Reply клиенту.

Серверу следует реализовать конфигурационный параметр для обработки случаев, конда клинетское сообщение DHCP содержит экземпляр OPTION_SLAP_QUAD а ретранслятор добавляет второй экземпляр в своем сообщении Relay-forward. Этот параметр настраивает сервер на обработку одного из экземпляров QUAD. Рекомендуется по умолчанию обрабатывать опцию их запроса клиента.

Клиент может проверить принадлежность полученного MAC-адреса к желаемому квадранту и принять на основе этой проверки решение об использовании или настройке полученного адреса.

4. Определение опции DHCPv6

4.1. Опция QUAD

Опция QUAD служит для задания предпочтений при выборе квадрантов в опции IA_LL. Опция должна инкапсулироваться в поле IA_LL-options опции IA_LL или в сообщение Relay-forward. Формат QUAD показана на рисунке 4.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       OPTION_SLAP_QUAD        |          option-len           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   quadrant-1  |    pref-1     |   quadrant-2  |    pref-2     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  quadrant-n-1 |   pref-n-1    |   quadrant-n  |    pref-n     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат опции QUAD.


option-code

OPTION_SLAP_QUAD (140).

option-len

Удвоенное число пар (quadrant, preference). Это 2-байтовое поле указывает общий размер всех пар (quadrant, preference), включенных в опцию.

quadrant-n

Идентификатор квадранта (0- AAI, 1 – ELI, 2 – резерв IEEE [IEEEStd802c], 3 – SAI). Каждый квадрант должен включаться в опцию не более 1 раза. Поле имеет размер 1 байт.

pref-n

Предпочтение для quadrant-n (большее значение для большего приоритета). Поле имеет размер 1 байт.

Значение идентификатора квадранта должно присутствовать в опции не более 1 раза. В противном используется лишь первое включение, а остальные сервер должен игнорировать.

Если для нескольких квадрантов указано одинаковое предпочтение, сервер может выбрать квадрант (при условии наличия адресов в нескольких квадрантах с одинаковым предпочтением). assign addresses from all or some of the quadrants with the same assigned preference). Отметим, что это не просто список квадрантов, упорядоченных по предпочтению, а список с явными значениями предпочтения. Таким образом, может поддерживаться случай, когда у клиента действительно нет предпочтения среди двух или трех квадрантов и он отдает решение серверу.

Если клиент или ретранслятор задает OPTION_SLAP_QUAD, сервер должен использовать значения quadrant-n/pref-n для упорядочения выбора квадрантов. Если сервер может предоставить адреса в одном из указанных квадрантов, ему следует выполнить это назначение. Если у сервера нет пула адресов, соответствующего какому-либо из указанных значений quadrant-n, или есть пул в нужном квадранте, но в нем нет доступных адресов, сервер должен вернуть опцию IA_LL со статусом NoAddrsAvail.

От клиента и ретранслятора не требуется упорядочивать значения quadrant/pref определенным образом, поэтому серверу недопустимо предполагать, что quadrant-1/pref-1 имеет высший приоритет (кроме случая, когда есть лишь один набор значений).

В случаях, когда сервер не может быть настроен с пулом адресов, соответствующим предпочтениям клиента или ретранслятора, тем следует указать в опции QUAD все квадранты, чтобы гарантировать получение клиентом адресов, если они имеются. Указание всех квадрантов приводит также к тому, что сервер, поддерживающий опцию QUAD, отвечает как сервер без поддержки опции, т. е. может возвратить адреса из любого доступного квадранта.

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

Агентство IANA выделило код опции QUAD (140) из субреестра Option Codes в реестре Dynamic Host Configuration Protocol for IPv6 (DHCPv6), доступном по ссылке http://www.iana.org/assignments/dhcpv6-parameters.

   Value:  140
   Description:  OPTION_SLAP_QUAD
   Client ORO:  No
   Singleton Option:  Yes
   Reference:  RFC 8948

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

Вопросы безопасности и конфиденциальности DHCPv6 рассмотрены в [RFC8415] и [RFC7227], а безопасность IPv6 – в [RFC8200].

Вопросы безопасности назначения адресов канального уровня с помощью DHCP рассмотрены в [RFC8947].

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

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

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words”, BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[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>.

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

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

[IEEE-P802.1CQ-Project] IEEE, “P802.1CQ – Standard for Local and Metropolitan Area Networks: Multicast and Local Address Assignment”, <https://standards.ieee.org/project/802_1CQ.html>.

[IEEEStd802] 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>.

[IEEEStd802c] 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>.

[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, “Guidelines for Creating New DHCPv6 Options”, BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <https://www.rfc-editor.org/info/rfc7227>.

[RFC7228] Bormann, C., Ersue, M., and A. Keranen, “Terminology for Constrained-Node Networks”, RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.

[RFC7548] Ersue, M., Ed., Romascanu, D., Schoenwaelder, J., and A. Sehgal, “Management of Networks with Constrained Devices: Use Cases”, RFC 7548, DOI 10.17487/RFC7548, May 2015, <https://www.rfc-editor.org/info/rfc7548>.

[RFC8200] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>.

Приложение A. Пример использования механизма выбора квадранта

В этом приложении рассмотрены некоторые примеры использования механизмов предпочтения квадрантов.

В качестве первого примера рассмотрим вариант IoT. Устройство IoT может самостоятельно выбрать квадрант SLAP для использования локального MAC-адреса, используя для выбора приведенные ниже сведения.

  • Тип развертывания IoT, например, промышленное, домашнее, сельское и т. п. Для небольших систем, например, в доме, устройство IoT может само выбрать квадрант AAI (это возможно даже без DHCP путем выбора случайного адреса самим устройством). Для больших систем, таких как промышленные, где могут быть тысячи устройств, могут использоваться квадранты ELI или SAI.

  • Мобильность. Если устройство IoT может перемещаться, оно может предпочесть выбор квадрантов SAI или AAI для минимизации адресных конфликтов при перемещении между сетями. Если устройство знает, что оно не будет перемещаться, лучшим решением может оказаться квадрант ELI.

  • Управляемость. В зависимости от того, управляется ли устройство IoT в течение своего срока действия или его конфигурацию нельзя изменить [RFC7548], решение о выборе подходящего квадранта может меняться. Например, если устройство IoT может управляться (например, настраиваться) и топология сети может меняться в течение срока службы (например, в результате изменения системы при добавлении устройств), это может влиять на выбор предпочтительного квадранта (например, для предотвращения будущих конфликтов).

  • Срок работы от батареи. В зависимости от возможной продолжительности работы устройства предпочтительный квадрант может изменяться (например, для минимизации возможных конфликтов).

Предыдущие параметры служат аспектами, которые производитель или администратор могут учитывать при выборе правил запроса MAC-адресов устройствами IoT (выбор квадранта SLAP). Устройства IoT обычно очень ограничены в ресурсах, поэтому в них может применяться лишь очень простой процесс выбора на основе заданных предпочтений.

Далее рассматривается вариант Wi-Fi с учетом, например, подключения ноутбука или смартфона к сети с использованием встроенного MAC-адреса. Из соображений конфиденциальности и безопасности устройство может пожелать использовать локальный MAC-адрес. При этом для устройства можно использовать разные параметры и данные контекста – квадрант SLAP для назначения локального MAC-адреса, условия смены адреса (например, может потребоваться неоднократная смена). Эта информация может включать перечисленные ниже аспекты, а также иное.

  • Тип сети, к которой подключается устройство – общественная, рабочая, домашняя.

  • Является ли сеть доверенной.

  • Является ли подключение к сети первым.

  • Местоположение сети.

  • Мобильность, т. е. возможность смены точки подключения устройства к сети.

  • Сетевой профиль операционной системы (OS), включая параметры безопасности и доверия. Многие современные OS хранят метаданные, связанные с сетями, к которым устройство может подключаться, например, уровень доверия, заданный для сети пользователем или администратором. Эта информация служит для настройки повердения устройства в плане анонсирования себя в сети, настройки межсетевого экранирования и т. п. Но эта информация может также служить для решения вопроса об использовании локального MAC-адреса, выборе для него квадранта SLAP и частоте назначения такого адреса.

  • Триггеры приложений, связанные с конфиденциальностью местоположения. Приложение может запросить у OS максимальную конфиденциальность местоположения (в силу прилоды этого приложения), а это может потребовать от OS использования или смены локального MAC-адреса.

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

Кроме того, информацию можно использовать для инициирования смены MAC-адреса с целью сохранения конфиденциальности местоположения. Смену квадранта SLAP можно также использовать для предотвращения отслеживания устройства.

В варианте ЦОД гипервизор может запросить выделение локальных MAC-адресов для виртуальных машин. Как и в описанных раньше вариантах, гипервизор может выбрать предпочтительный квадрант SLAP, используя данные системы управления облаком или менеджера виртуальной инфраструктуры. Примеры таких данных приведены ниже.

  • Перемещаемость VM. Возможность переноса функции, реализуемой VM, на другой физический сервер может влиять на выбор предпочтительного квадрант SLAP, поскольку квадранты ELI и SAI лучше подходят для поддержки переноса в крупных ЦОД.

  • Характеристики связности VM. Например, этом может быть автономная машина, часть пула или часть цепочки услуг. Если характеристики связности VM известны, гипервизор может использовать их при выборе квадранта SLAP.

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

Авторы благодарят Bernie Volz за полезные замечания к документу. Спасибо также Ian Farrer, Tomek Mrugalski, Éric Vyncke, Tatuya Jinmei, Carl Wallace, Ines Robles, Ted Lemon, Jaime Jimenez, Robert Wilton, Benjamin Kaduk, Barry Leiba, Alvaro Retana, Murray Kucherawy за подробные и полезные рецензии. Спасибо Roger Marks и Antonio de la Oliva за комментарии, связанные с работой IEEE, и ссылки.

Разработка этого документа поддержана проектами H2020 5GROWTH (Grant 856709) и 5G-DIVE (Grant 859881).

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

Carlos J. Bernardos

Universidad Carlos III de Madrid

Av. Universidad, 30

28911 Leganes, Madrid

Spain

Phone: +34 91624 6236

Email: cjbc@it.uc3m.es

URI: http://www.it.uc3m.es/cjbc/

Alain Mourad

InterDigital Europe

Email: Alain.Mourad@InterDigital.com

URI: http://www.InterDigital.com/

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

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

nmalykh@protokols.ru

1Media Access Control – управление доступом к среде.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

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