RFC 9035 A Routing Protocol for Low-Power and Lossy Networks (RPL) Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header

image_print
Internet Engineering Task Force (IETF)                   P. Thubert, Ed.
Request for Comments: 9035                                       L. Zhao
Updates: 8138                                              Cisco Systems
Category: Standards Track                                     April 2021
ISSN: 2070-1721

A Routing Protocol for Low-Power and Lossy Networks (RPL)

Destination-Oriented Directed Acyclic Graph (DODAG) Configuration Option for the 6LoWPAN Routing Header

Протокол RPL – опция DODAG Configuration для заголовка 6LoWPAN Routing

PDF

Аннотация

Этот документ обновляет RFC 8138, задавая бит в опции RPL1 DODAG2 Configuration для индикации применения сжатия в RPL Instance и задания поведения узлов, соответствующих RFC 8138, при установленном и сброшенном флаге.

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

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

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

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

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

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

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

Оглавление

Исключено в варианте HTML.

1. Введение

При создании сетей LLN5 обычно сосредотачиваются на экономии энергии, являющейся одним из наиболее дефицитных ресурсов. Оптимизация маршрутов в «RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks» [RFC6550], такая как маршрутизация по DODAG к корневому узлу и связанное с этим сжатие маршрутных заголовков, предложенное в [RFC8138], связаны с этой проблемой.

Включение [RFC8138] в работающей сети требует перехода (flag day), при котором сеть обновляется и перезагружается. В противном случае, являющиеся листьями узлы, не поддерживающие сжатие [RFC8138], не смогут взаимодействовать с сетью, а узлы, служащие маршрутизаторами, будут отбрасывать пакеты, делая часть сети «чёрной дырой». Эта спецификация обеспечивает возможность «горячего» обновления работающей сети, при котором сжатие активируется лишь после обновления всех узлов.

Этот документ дополняет [RFC8138] и указывает, следует ли использовать его в RPL DODAG с новым флагом опции RPL DODAG Configuration. Установка нового флага контролируется корнем и флаг распространяется по сети как обычные сигналы RPL. Флаг сбрасывается для отключения сжатия в процессе перехода, по завершении которого (например, по информации от системы управления сетью) флаг устанавливается для всего графа DODAG.

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

2.1. Связанные документы

Используемая в документе терминология включает определения из «Terms Used in Routing for Low-Power and Lossy Networks» [RFC7102]. Термины, связанные с LLN, определены в «Terminology for Constrained-Node Networks» [RFC7228].

Термины RPL, RPL Packet Information (RPI), RPL Instance (индексируется RPLInstanceID) определены в «RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks» [RFC6550]. RPI – это абстрактная информация, определяемая RPL для включения в пакеты данных, например, в опцию RPL [RFC6553] заголовка IPv6 Hop-By-Hop. Термин RPI часто применяется в расширенном смысле для обозначения RPL Option. Сообщения DODAG Information Solicitation (DIS), Destination Advertisement Object (DAO), DODAG Information Object (DIO) также определены в [RFC6550].

Термины RPL-Unaware Leaf (RUL) и RPL-Aware Leaf (RAL) применяются в соответствии с «Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane» [RFC9008]. RPL-Aware Node (RAN) указывает узел, являющийся RAL или маршрутизатором RPL и поддерживает доступность своих адресов и префиксов путём их вставки в RPL. RUL использует «Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery» [RFC8505] для получения услуг доступности от родительского маршрутизатора, как указано в «Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves» [RFC9010].

2.2. Глоссарий

6LoRH

6LoWPAN Routing Header – заголовок маршрутизации 6LoWPAN.

6LoWPAN

IPv6 over Low-Power Wireless Personal Area Network – IPv6 в персональной беспроводной сети со слабым питанием.

DIO

DODAG Information Object – информационный объект DODAG (сообщение RPL).

DODAG

Destination-Oriented Directed Acyclic Graph – ориентированный на адресата ациклический направленный граф.

LLN

Low-Power and Lossy Network – сеть со слабым питанием и потерями.

MOP

RPL Mode of Operation – режим работы RPL.

RAL

RPL-Aware Leaf – понимающий протокол RPL лист.

RAN

RPL-Aware Node – понимающий протокол RPL узел (маршрутизатор RPL или понимающий RPL лист).

RPI

RPL Packet Information – информация пакета RPL.

RPL

Routing Protocol for Low-Power and Lossy Networks – протокол маршрутизации для сетей LLN.

RUL

RPL-Unaware Leaf – не понимающий протокол RPL лист.

SRH

Source Routing Header – заголовок заданной источником маршрутизации.

Sub-DODAG

Субграфом DODAG для узла является DODAG с корнем в узле, являющийся частью графа DODAG, к которому относится узел. Граф формируется другими узлами основного DODAG, чьи пути к корню основного DODAG идут через этот узел.

2.3. Уровни требований

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

3. Расширение RFC 6550

Опция DODAG Configuration определена в параграфе 6.7.6 [RFC6550]. Назначение опции расширено для распространения конфигурационных данных, влияющих на создание и поддержку DODAG, а также распространение рабочих параметров RPL через DODAG. Исходная опция DODAG Configuration включала 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 0x04 |Opt Length = 14| | |T| |A|       ...           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
                                <- flags ->

Рисунок 1. Частичное представление опции DODAG Configuration.


В этой спецификации определён новый флаг сжатия RFC 8138 (T), устанавливаемый для включения поддержки [RFC8138] в графе DODAG. Флаг T занимает позицию 2 резервного поля флагов в опции DODAG Configuration (отсчёт с 0 для старшего бита) и сбрасывается (0) в унаследованных реализациях, как указано в параграфах 20.14 и 6.7.6 [RFC6550].

Параграф 4.1.2 в [RFC9008] обновляет [RFC6550] указанием применимости определения флагов лишь к режимам работы (Mode of Operation или MOP) от 0 до 6. Для MOP = 7 должно применяться сжатие заголовков 6LoWPAN [RFC8138], которое в других случаях недопустимо использовать.

Опция RPL DODAG Configuration обычно помещается в сообщения DIO, распространяемые вниз по DODAG для формирования и последующей поддержки графа. Опция DODAG Configuration копируется без изменений от родителей к потомкам. В [RFC6550] сказано: «Узлам, не являющимся корнем DODAG, недопустимо менять эту информацию при распространении опции DODAG Configuration.» Поэтому унаследованные родители распространяют установленный корнем флаг T и он попадает на все узлы DODAG.

4. Обновление RFC 8138

Узлу следует генерировать пакеты в сжатом формате [RFC8138] тогда и только тогда, когда установлен флаг T. Это поведение можно переопределить в конфигурации и системе управления сетью. Переопределение может потребоваться, например, для включения сжатия в сети, где все узлы поддерживают [RFC8138], но корень не поддерживает эту спецификацию и не может установить флаг T или сбросить его локально при наличии проблем.

Решение об использовании [RFC8138] принимается отправителем пакета в зависимости от его возможностей и сведений о состоянии флага T. Инкапсулирующий пакет маршрутизатор является источником результирующего пакета и отвечает за сжатие внешних заголовков в соответствии с [RFC8138], но сжимать инкапсулированный пакет недопустимо.

Предполагается, что внешняя цель [RFC9008] не поддерживает [RFC8138]. В большинстве случаев пакеты для внешней цели и от неё туннелируются между граничным маршрутизатором (6LoWPAN Router или 6LR), обслуживающим эту цель, и корнем, независимо от режима MOP в RPL DODAG. Внутренний пакет обычно не сжимается с помощью [RFC8138], поэтому для исходящих пакетов граничному маршрутизатору нужно просто декапсулировать (сжатый) внешний заголовок и переслать (декомпрессированный) внутренний пакет в направлении внешней цели.

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

RUL [RFC9010] является одновременно листом и внешней целью. Узел RUL не участвует в RPL и зависит от внешнего маршрутизатора, обеспечивающего подключение. В случае RUL пересылка в направлении внешней цели реально означает доставку пакета.

5. Варианты перехода

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

Целью этой спецификации является переход без использования flag day. В частности, цель заключается в отказе от флага T. Хотя возможен возврат к прежнему состоянию (см. параграф 5.3), операцию возврата следует завершить до того, как в сети появятся узлы, не поддерживающие [RFC8138].

5.1. Сосуществование

Поддерживающий эту спецификацию узел может работать в сети с включённым или отключённым сжатием 6LoRH [RFC8138] и соответствующим флагом T в сети, находящейся в процессе перехода (см. параграф 5.2).

Узел, не поддерживающий [RFC8138], может взаимодействовать с узлами сети, где сжатие 6LoRH [RFC8138] отключено. Если сжатие включено, для всех RAN предполагается способность обработки сжатых пакетов. Узел, не способный сделать это, может оставаться подключённым к сети в качестве RUL, как описано в [RFC9010].

5.2. Несогласованность состояний при переходе

Когда корень устанавливает флаг T, информация постепенно распространяется через DODAG по мере отправки сообщений DIO. Некоторые узлы увидят флаг и начнут передавать пакеты в сжатом формате, а другие узлы в том же RPL DODAG ещё не будут знать о них. В режиме Non-Storing корень начнёт применять [RFC8138] с заголовком SRH 6LoRH (SRH-6LoRH), который направит все пути к родительскому маршрутизатору или листу.

Для гарантированной пересылки пакета через RPL DODAG в исходной форме все узлы RPL должны поддерживать [RFC8138] на момент переключения. Ответственность за установку флага T ложится на администратора сети. Предполагается, что имеющиеся средства управления сетью и обновления позволят администратору сети узнать, что все узлы, которые могут присоединиться к DODAG, были обновлены. Для экземпляра RPL с несколькими корнями все узлы, участвующие в RPL Instance. Могут присоединяться к любому графу DODAG. Сеть должна работать со сброшенным флагом T, пока все узлы RPL не будут обновлены для поддержки этой спецификации.

5.3. Возврат

При отключении сжатия 6LoRH [RFC8138] в сети администратор должен дождаться, пока все узлы сбросят флаг T перед тем, как разрешить отказ от сжатия в сети. Информацию о режиме сжатия следует раскрывать в интерфейсе управления узлом.

Узлы, не поддерживающие [RFC8138], не следует развёртывать в сети со включённым сжатием заголовков. Если такой узел подключён к сети, он может работать лишь в качестве RUL.

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

Эта спецификация обновляет реестр «DODAG Configuration Option Flags for MOP 0..6» [RFC9008] (ранее «DODAG Configuration Option Flags» [RFC6550]), путём выделения нового флага (таблица 1).

Таблица 1. Новый флаг опции DODAG Configuration.

Номер бита

Описание

Документ

2

Включение сжатия RFC 8138 (T)

RFC 9035

Агентство IANA добавило этот документ в качестве ссылки для строки MOP 7 в реестре RPL «Mode of Operation».

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

Следует отметить, что в RPL [RFC6550] каждый узел LLN, понимающий RPL и имеющий доступ в домен RPL, может организовать любую атаку, основанную на RPL (см. [RFC7416]). Этот документ обычно применяется к развёрнутым системам и не меняет для них требований к защите и операциям. Предполагается применение механизмов защиты, определённых для RPL.

Установка флага T до обновления всех маршрутизаторов может приводить к потере пакетов. Для нового флага применяется та же защита, что и для остальной информации в содержащей флаг опции DODAG Configuration. Доступ к новому флагу является лишь одной из многих атак, возможных в случае отправки злоумышленником в сеть повреждённых опций конфигурации.

Установка или сброс флага T может нарушать согласованность сети, но до завершения обновления всех узлов для поддержки [RFC8138] они могут пересылать обе формы. Источник отвечает за управление сжатием пакета, а все маршрутизаторы должны использовать выбранный источником формат. Поэтому результатом несогласованности может быть лишь присутствие в сети обеих форм пакетов, что ведёт к дополнительному расходу пропускной способности для пакетов без сжатия.

Атакующий может сбросить флаг T, чтобы вынудить дочерние или нижележащие узлы субграфа DODAG потреблять больше энергии. И наоборот, он может установить флаг T, чтобы узлы нисходящего направления сжимали пакеты даже при нежелательности компрессии, что может приводить к потере пакетов. В дереве атакующий может отбрасывать пакеты, идущие к объекту атаки или от него. Таким образом, упомянутые выше атаки будут более сложными и более заметными, чем простое отбрасывание выбранных пакетов. Узел нисходящего направления может иметь других родителей и видеть бит в обоих состояниях – такую ситуацию можно обнаружить и выдать сигнал.

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

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

[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, “RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks”, RFC 6550, DOI 10.17487/RFC6550, March 2012, <https://www.rfc-editor.org/info/rfc6550>.

[RFC7102] Vasseur, JP., “Terms Used in Routing for Low-Power and Lossy Networks”, RFC 7102, DOI 10.17487/RFC7102, January 2014, <https://www.rfc-editor.org/info/rfc7102>.

[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, “IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing Header”, RFC 8138, DOI 10.17487/RFC8138, April 2017, <https://www.rfc-editor.org/info/rfc8138>.

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

[RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. Perkins, “Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery”, RFC 8505, DOI 10.17487/RFC8505, November 2018, <https://www.rfc-editor.org/info/rfc8505>.

[RFC9010] Thubert, P., Ed. and M. Richardson, “Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves”, RFC 9010, DOI 10.17487/RFC9010, April 2021, <https://www.rfc-editor.org/info/rfc9010>.

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

[RFC6282] Hui, J., Ed. and P. Thubert, “Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks”, RFC 6282, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-editor.org/info/rfc6282>.

[RFC6553] Hui, J. and JP. Vasseur, “The Routing Protocol for Low-Power and Lossy Networks (RPL) Option for Carrying RPL Information in Data-Plane Datagrams”, RFC 6553, DOI 10.17487/RFC6553, March 2012, <https://www.rfc-editor.org/info/rfc6553>.

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

[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., and M. Richardson, Ed., “A Security Threat Analysis for the Routing Protocol for Low-Power and Lossy Networks (RPLs)”, RFC 7416, DOI 10.17487/RFC7416, January 2015, <https://www.rfc-editor.org/info/rfc7416>.

[RFC9008] Robles, M.I., Richardson, M., and P. Thubert, “Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane”, RFC 9008, DOI 10.17487/RFC9008, April 2021, <https://www.rfc-editor.org/info/rfc9008>.

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

Авторы признательны Murray Kucherawy, Meral Shirazipour, Barry Leiba, Tirumaleswar Reddy, Nagendra Kumar Nainar, Stewart Bryant, Carles Gomez, Éric Vyncke, Roman Danyliw и особенно Benjamin Kaduk, Alvaro Retana, Dominique Barthel, Rahul Jadhav за глубокий обзор и конструктивные предложения.

Большое спасибо Michael Richardson, который всегда был готов прийти на помощь.

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

Pascal Thubert (редактор)

Cisco Systems, Inc.

Building D

45 Allee des Ormes – BP1200

06254 MOUGINS – Sophia Antipolis

France

Phone: +33 497 23 26 34

Email: pthubert@cisco.com

Li Zhao

Cisco Systems, Inc.

Xinsi Building

No. 926 Yi Shan Rd

Shanghai

200233

China

Email: liz3@cisco.com


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

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

nmalykh@protocols.ru

1Routing Protocol for Low-Power and Lossy Networks – протокол маршрутизации для сетей LLN.

2Destination-Oriented Directed Acyclic Graph – ориентированный на получателя направленный ациклический граф.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Low-Power and Lossy Network – сеть со слабым питанием и потерями.

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

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