RFC 9010 Routing for RPL (Routing Protocol for Low-Power and Lossy Networks) Leaves

Internet Engineering Task Force (IETF)                   P. Thubert, Ed.
Request for Comments: 9010                                 Cisco Systems
Updates: 6550, 6775, 8505                                  M. Richardson
Category: Standards Track                                      Sandelman
ISSN: 2070-1721                                               April 2021

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

Маршрутизация для листьев RPL

PDF

Аннотация

В этом документе определен механизм для хостов, реализующих независимый от маршрутизации интерфейс на основе обнаружения соседей 6LoWPAN, для определения доступности в сети, использующей маршрутизацию RFC 6550. Документ обновляет RFC 6550, RFC 6775 и RFC 8505.

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

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

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

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

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

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

1. Введение

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

В IETF разработан документ «RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks» [RFC6550] для обеспечения маршрутизации IPv6 [RFC8200] с учётом этих ограничений. Протокол RPL относится к протоколам маршрутизации на основе вектора удалённости, которые в отличие от протоколов на основе состояния канала (link-state), ограничивают объем топологической информации, которую нужно поддерживать на каждом узле, и не требует схождения для предотвращения микропетель.

Для хранения состояний сигнализации и маршрутизации в сетях с ограничениями RPL поддерживает растяжение путей (path stretch, см. [RFC6687]), при этом маршрутизация выполняется лишь по ориентированному на адресата направленному ациклическому графу (Destination-Oriented Directed Acyclic Graph или DODAG), оптимизированному для достижения корневого узла, а не по кратчайшему пути между двумя партнёрами, что бы это не означало в данной сети LLN. При этом вместо качества путей между партнёрами (peer-to-peer или P2P) выполняется обмен значительно меньшим объёмом управляющего трафика и состояний маршрутизации для работы протокола по кратчайшему пути «каждый с каждым». Кроме того, можно «неторопливо» исправлять по запросу оборванные пути на основе обнаружения несогласованности доставки в плоскости данных, что позволяет избавиться от расхода энергии на проактивное восстановление неиспользуемых путей.

Для многих (но не всех) узлов DODAG обеспечивает множество вариантов пересылки в направлении корня через так называемых родителей (parent). RPL организует маршруты заранее (проактивно), но приспособлен к «нечётким» соединениям (когда не предполагается стабильность физической топологии) и использует «неторопливую» поддержку маршрутов, исправляя их по факту (реактивно) наличия реального трафика. В результате RPL обеспечивает связность для большинства узлов LLN большую часть времени, но не обеспечивает сходимости в классическом понимании.

RPL можно развернуть вместе с обнаружением соседей IPv6 (Neighbor Discovery или ND) [RFC4861] [RFC4862] и 6LoWPAN ND [RFC6775] [RFC8505] для поддержки доступности внутри многоканальной подсети NBMA. В этом режиме адреса IPv6 анонсируются индивидуально как маршруты к хостам. Некоторые узлы могут служить маршрутизаторами и участвовать в пересылке, тогда как другие лишь передают и принимают пакеты, выступая в плоскости данных лишь в качестве хостов. В соответствии с терминологией [RFC6550] хост IPv6 [RFC8504], достижимый через сеть RPL, называется листом (leaf).

В разделе 2 [RFC9008] определены термины RPL leaf, RPL-Aware Leaf (RAL), RPL-Unaware Leaf (RUL). Лист RPL является хостом, подключённым к одному или нескольким маршрутизаторам RPL. Лист полагается на маршрутизаторы RPL для пересылки своего трафика через домен RPL, но сам не пересылает трафик других узлов. В отличие от RAL, лист RUL не участвует в RPL и полагается на свои маршрутизаторы RPL для вставки маршрутов к своим адресам IPv6 в домене RPL.

      ------+---------
            |          Internet
            |
         +-----+
         |     | <------------- Корень 6LBR / RPL DODAG
         +-----+                     ^
            |                        |
      o    o   o  o                  | RPL
  o o   o  o   o  o     o    o       |
 o  o o  o o    o   o  o   o  o      |  +
 o   o      o     o   o   o    o     |
o  o   o  o   o  o    o    o  o      | 6LoWPAN ND
   o  o  o  o        o   o           |
  o       o            o    o        v
o      o     o <------------- 6LR / Граничный маршрутизатор RPL
                                     ^
                                     | Только 6LoWPAN ND
                                     v
             u <------------- 6LN / не знающий RPL лист

Рисунок 1. Вставка маршрутов от имени RUL.

Устройство RUL может быть не в состоянии участвовать в работе по причине сильных ограничений по питанию или размеру кода, а также небезопасности вставки таким узлом маршрутов в RPL. Использование 6LoWPAN ND вместо RPL в качестве интерфейса между хостом и маршрутизатором ограничивает фронт возможных атак со стороны RUL на домен RPL. Если все RUL и понимающие RPL узлы (RPL-Aware Node или RAN) используют для обнаружения соседей 6LoWPAN ND, можно также защитить владение адресами для всех узлов, включая RUL.

В этом документе описана вставка маршрутизатором маршрутов к хостам в домен RPL от имени RUL. В разделе 5 описано, как RUL может воспользоваться 6LoWPAN ND для получения услуг маршрутизации. В этой модели RUL является также узлом 6LoWPAN (6LN), а понимающий RPL маршрутизатор – маршрутизатором 6LoWPAN (6LR). Используя механизм регистрации адресов 6LoWPAN ND, RUL сообщает, что маршрутизатор должен ввести маршрут к хосту для зарегистрированного адреса.

Механизм режима RPL Non-Storing применяется для расширения состояния маршрутизации связностью с RUL даже при работе DODAG в режиме Storing. Операция пересылки индивидуальных пакетов в 6LR обслуживает RUL, как описано в параграфе 4.1.1 [RFC9008].

Примерами RUL являются некоторые датчики с очень ограниченным питанием (например, датчики повреждения стёкол в окнах и выключатели света с кинетическим питанием). Другие применения этой спецификации могут включать интеллектуальные сети управления бытовыми приборами, такими как стиральные машины и домашние системы отопления. Бытовые электроприборы не могут участвовать в работе протокола RPL в интеллектуальной сети управления, но могут взаимодействовать с такой сетью для контроля и измерений.

Данная спецификация может разворачиваться постепенно в сети, реализующей [RFC9008], при этом обновлять требуется лишь корень и маршрутизаторы 6LR, соединённые с RUL. Маршрутизаторы RPL на пути будут видеть лишь индивидуальный трафик IPv6 между корнем и 6LR.

Организация оставшейся части документа описана ниже.

В разделах 3 и 4 приведено ненормативное описание основных аспектов RPL и 6LoWPAN ND, используемых в спецификации для подключения 6LN, являющихся RUL, через сеть RPL.
В разделе 5 даны требования к RUL для обслуживания этих листьев маршрутизатором RPL, соответствующим данной спецификации.
В разделе 6 представлены изменения по отношению к [RFC6550] – новое поведение, когда 6LR анонсирует адреса 6LN в сообщении RPL DAO на основе регистрации ND узлом 6LN, а корень RPL DODAG выполняет обмен EDAR/EDAC с граничным маршрутизатором 6LoWPAN (6LBR) от имени 6LR и изменения некоторых опций RPL и RPL Status для облегчения интеграции протоколов.
В разделе 7 представлены изменения по отношению к [RFC9009] – использование сообщения DCO расширено на режим работы Non-Storing для передачи сведений об асинхронных передачах из корня в 6LR.
В разделе 8 представлены изменения по отношению к [RFC6775] и [RFC8505] – диапазон значений статуса ARO/EARO сужен до 64, а оставшиеся биты переведены в резервные.
В разделах 9 и 10 представлена работа этой спецификации для индивидуальных и групповых потоков, а раздел 11 посвящён вопросам безопасности.

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

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

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

2.2. Глоссарий

6BBR

6LoWPAN Backbone Router – магистральный маршрутизатор 6LoWPAN.

6CIO

6LoWPAN Capability Indication Option – опция индикации совместимости 6LoWPAN.

6LBR

6LoWPAN Border Router – граничный маршрутизатор 6LoWPAN.

6LN

6LoWPAN Node – узел 6LoWPAN (хост или маршрутизатор с ограниченным питанием).

6LoRH

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

6LoWPAN

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

6LR

6LoWPAN Router – маршрутизатор 6LoWPAN.

AP-ND

Address-Protected Neighbor Discovery – обнаружение соседей с защитой адреса.

ARO

Address Registration Option – опция регистрации адреса.

DAC

Duplicate Address Confirmation – подтверждение дубликата адреса.

DAD

Duplicate Address Detection – обнаружение дубликатов адресов.

DAO

Destination Advertisement Object – объект анонсирования адресата (сообщение RPL).

DAR

Duplicate Address Request – запрос о дубликатах адреса.

DCO

Destination Cleanup Object – объект очистки адресата (сообщение RPL).

DIO

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

DODAG

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

EARO

Extended Address Registration Option – расширенная опция регистрации адреса.

EDAC

Extended Duplicate Address Confirmation – расширенное подтверждение дубликата адреса.

EDAR

Extended Duplicate Address Request – расширенный запрос о дубликатах адреса.

EUI

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

LLN

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

MLD

Multicast Listener Discovery – обнаружение «слушателей» группового трафика.

MOP

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

Neighbor Advertisement – анонсирование соседа.

NBMA

Non-Broadcast Multi-Access – множественный доступ без широковещания.

NCE

Neighbor Cache Entry – запись кэша соседа.

Neighbor Discovery – обнаружение соседей.

Neighbor Solicitation – запрос (ходатайство) о соседстве.

PIO

Prefix Information Option – опция сведений о префиксе.

Router Advertisement – анонсирование маршрутизатора.

RAL

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

RAN

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

RH3

Routing Header for IPv6 (type 3) – заголовок маршрутизации для IPv6 (тип 3).

ROVR

Registration Ownership Verifier – проверяющий владение регистрацией.

RPI

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

RPL

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

RUL

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

SAVI

Source Address Validation Improvement – улучшение проверки адреса источника.

SLAAC

Stateless Address Autoconfiguration – автоматическая настройка адреса без учёта состояния.

SRH

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

TID

Transaction ID – идентификатор транзакции (счётчик в EARO).

TIO

Transit Information Option – опция транзитной информации.

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

Используемая в документе терминология соответствует «Terms Used in Routing for Low-Power and Lossy Networks» [RFC7102]. Глоссарий принятых в 6LoWPAN сокращений дан в параграфе 2.2. Другие термины, применяемые в LLN, определены в «Terminology for Constrained-Node Networks» [RFC7228]. В этой спецификации термины 6LN и 6LR служат для обозначения узлов, играющих соответствующую роль в 6LoWPAN ND, от которых не ожидается иной функциональности, такой как сжатие заголовков 6LoWPAN [RFC6282].

Термины RPL, RPI, RPL Instance (указывается RPLInstanceID), «вверх» (up) и «вниз» (down) определены в «RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks» [RFC6550]. RPI является абстрактной информацией, определённой в RPL для размещения в пакетах данных (например, опция RPL Option [RFC6553] в заголовке IPv6 Hop-By-Hop). В более широком смысле RPI часто указывает саму опцию RPL. Сообщения DAO и DIO определены в [RFC6550], а DCO – в [RFC9009].

Термины RUL, RAN, RAL в документе применяются в соответствии с [RFC9008]. RAN указывает лист RAL или маршрутизатор RPL. В отличие от RUL, узел RAN управляет доступностью своих адресов и префиксов путём самостоятельной их вставки в RPL.

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

Classical IPv6 ND – классическое обнаружение соседей IPv6

«Neighbor Discovery for IP version 6 (IPv6)” [RFC4861] and “IPv6 Stateless Address Autoconfiguration» [RFC4862].

6LoWPAN

«Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing» [RFC6606] и «IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals» [RFC4919].

6LoWPAN ND – обнаружение соседей 6LoWPAN

«Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)» [RFC6775], «Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery» [RFC8505], «Address-Protected Neighbor Discovery for Low-Power and Lossy Networks» [RFC8928] и «IPv6 Backbone Router» [RFC8929].

3. Внешние маршруты RPL и «артефакты» плоскости данных

Протокол RPL изначально был предназначен для оконечных (stub) сетей, в который единственным граничным маршрутизатором является корень RPL DODAG (обычно совмещённый с 6LBR) и все узлы сети понимают RPL. Но спецификация [RFC6550] поддерживает расширения для внешних маршрутов (target – цель в терминологии RPL) с помощью флага E (External) в опции TIO (Transit Information Option). Внешние цели обеспечивают возможность взаимодействия с адресатами вне домена RPL и соединёнными с этим доменом через граничные маршрутизаторы RPL, не являющиеся корнями. В параграфе 4.1 [RFC9008] приведён набор правил (кратко изложены ниже), которые применяются для маршрутизации пакетов во внешние сети и из них. Лист RUL является особым случаем внешней цели, которая также является хостом, напрямую подключённым к домену RPL.

6LR, выступающий граничным маршрутизатором для внешних маршрутов, анонсирует их, используя сообщения DAO режима Non-Storing, которые передаются по индивидуальному адресу напрямую в корень, даже при работе DODAG в режиме Storing. Маршруты режима Non-Storing не видны в домене RPL и все пакеты маршрутизируются через корень. Корень RPL DODAG туннелирует пакеты данных напрямую маршрутизатору 6LR, анонсировавшему внешний маршрут, где эти пакеты декапсулируются и пересылаются.

Сигнализация RPL Non-Storing MOP и инкапсулированные пакеты IPv6-in-IPv6 представляются промежуточным устройствам как обычный трафик. Поддержка внешних маршрутов влияет лишь на корень и 6LR. Это может работать с унаследованными промежуточными маршрутизаторами и не добавляет состояний, которые эти маршрутизаторы должны поддерживать. RUL является примером адресата, доступного через внешний маршрут, который служит также маршрутом к хосту.

Пакеты данных RPL обычно содержат заголовок Hop-by-Hop с опцией RPL [RFC6553], включающей RPI (RPL Packet Information, см. параграф 11.2 в [RFC6550]). Пока лист RUL ещё не поместил RPL Option во внешнюю цепочку заголовков, пакеты от RUL и к нему инкапсулируются в туннель IPv6-in-IPv6 между корнем и 6LR, обслуживающим RUL (см. разделы 7 и 8 в [RFC9008]). Если пакет от RUL включает RPI, 6LR, служащий граничным маршрутизатором RPL, переписывает RPI для указания RPL Instance и установки флагов, но не обязан инкапсулировать пакет (см. параграф 9.2.2).

В режиме Non-Storing идущие вниз по DODAG пакеты содержат заголовок Source Routing (SRH). Инкапсуляцию IPv6-in-IPv6, RPI и SRH вместе называют артефактами RPL, их можно сжать с помощью метода, описанного в [RFC8138]. В Приложении A дан пример сжатого формата для пакетов, пересылаемых корнем узлу RUL в DODAG режима Storing.

Внутренний пакет, пересылаемый листу RUL, может включать артефакты RPL, например, RPI при наличии этой опции в исходном пакете и SRH в DODAG с режимом Non-Storing. В [RFC9008] предполагается, что RUL поддерживает базовые требования к узлам IPv6 в соответствии с [RFC8504], в частности, требования параграфов 4.2 и 4.4 в [RFC8200]. Поэтому предполагается, что RUL игнорирует артефакты RPL, которые могут оставаться, – SRH с Segments Left = 0 или RPL Option в заголовке Hop-by-Hop (может быть пропущен, если не удалось распознать, см. параграф 5.3).

От RUL не ожидается поддержка сжатия, заданного в [RFC8138], поэтому граничный маршрутизатор (здесь 6LR) распаковывает пакет перед его отправкой RUL по внешнему маршруту [RFC9008].

4. Обнаружение соседей 6LoWPAN

В этом разделе рассматриваются используемые спецификацией механизмы 6LoWPAN ND в качестве справки для читателей. Полное описание этих механизмов представлено в [RFC6775], [RFC8505] и [RFC8928].

4.1. Регистрация адреса в соответствии с RFC 6775

Классический протокол обнаружения соседей IPv6 (IPv6 Neighbor Discovery или IPv6 ND) [RFC4861] [RFC4862] был разработан для последовательных каналов и транзитных сред, таких как Ethernet. Это реактивный протокол, в значительной степени зависящий от групповых операций для обнаружения адресов (Address Discovery) и дубликатов адресов (Duplicate Address Detection или DAD).

В документе «Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)» [RFC6775] механизмы IPv6 ND расширены для работы в ограниченных по питанию сетях LLN. Основной функцией [RFC6775] является упреждающее создание записей кэширования соседей (Neighbor Cache Entry или NCE) в 6LR и предотвращения дублирования адресов, для чего добавлен unicast-механизм регистрации адресов, сокращающий применение групповых сообщений по сравнению с классическим протоколом IPv6 ND.

В [RFC6775] также задана опция регистрации адресов (Address Registration Option или ARO), передаваемая в индивидуальных сообщениях NS³ и NA⁴ между узлом 6LoWPAN (6LN) и маршрутизатором 6LoWPAN (6LR). Определены также сообщения для запроса (Duplicate Address Request или DAR) и подтверждения (Duplicate Address Confirmation или DAC) дубликатов адреса между 6LR и 6LBR. В сети LLN маршрутизатор 6LBR является центральным хранилищем зарегистрированных адресов домена и источником достоверных данных о владении и уникальности.

4.2. Расширенная регистрация адреса в соответствии с RFC 8505

«Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery» [RFC8505] обновляет RFC 6775 базовым механизмом регистрации адресов, который может служить для доступа к таким функциям, как маршрутизация и ND прокси. Для этого в [RFC8505] определена опция расширенной регистрации адреса (Extended Address Registration Option или EARO), как показано на рисунке 2.

 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      |     Length    |    Status     |    Opaque     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Rsvd | I |R|T|     TID       |     Registration Lifetime     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~          Registration Ownership Verifier (ROVR)               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Формат опции EARO.

4.2.1. Флаг R

[RFC8505] определяет флаг R для опции EARO. Регистрирующий узел устанавливает флаг R для указания маршрутизатору 6LR обеспечения доступности для зарегистрированного адреса. При сброшенном флаге R регистрирующий узел обрабатывает доступность Registered Address иными путями. В сети RPL это означает, что узел RAN вносит маршрут самостоятельно или использует другой маршрутизатор RPL для служб доступности.

Этот документ задаёт использование флага R в контексте RPL. Узел RPL с функциональностью 6LN [RFC8505] требует служб доступности для адреса IPv6 тогда и только тогда, когда он устанавливает флаг в R в NS(EARO), служащем для регистрации адреса в 6LR, служащем граничным маршрутизатором RPL. При получении NS(EARO) маршрутизатор RPL создаёт сообщение DAO для Registered Address тогда и только тогда, когда установлен (1) флаг R.

В параграфе 9.2 описаны дополнительные операции, вызываемые наличием флага R в EARO сообщения NS или NA.

4.2.2. TID, флаг I и поле Opaque

При установленном (1) флаге T опция EARO включает значение счётчика, называемое идентификатором транзакции (Transaction ID или TID), которое требуется для заполнения поля Path Sequence в опции RPL Transit Information (TIO). По этой причине поддержка поддержка узлом RUL требований [RFC8505], а не только [RFC6775] является предварительным условием в данной спецификации (см. 5.1. Поддержка 6LoWPAN ND). Опция EARO включает также поле Opaque и связанное с ним поле I, определяющее содержимое и применение поля Opaque (см. параграф 9.2.1).

4.2.3. Проверка владельца маршрута

В параграфе 5.3 [RFC8505] введено поле проверки регистрации владения (Registration Ownership Verifier или ROVR) размером от 64 до 256 битов. ROVR заменяет 64-битовые расширенные уникальные идентификаторы (EUI-64) в опции ARO [RFC6775], которые служили для однозначного указания регистрации адресов канального уровня, но не обеспечивали защиты от подделки.

«Address-Protected Neighbor Discovery for Low-Power and Lossy Networks» [RFC8928] использует поле ROVR как криптографическое подтверждение владения для предотвращения регистрации другими адреса, который уже выделен. Применение поля ROVR позволяет маршрутизатору 6LR блокировать трафик, исходящий от чужого адреса.

Эта спецификация не решает вопрос расширения защиты [RFC8928] на RPL. С другой стороны, документ добавляет ROVR в сообщение DAO для создания в корне проксируемого EDAR (6.1. Обновлённая опция RPL Target), что позволяет узлам, знающим маршрут к хосту, знать значение ROVR, связанное с Target Address.

4.3. EDAR/EDAC в соответствии с RFC 8505

[RFC8505] заменяет сообщения DAR/DAC сообщениями EDAR/EDAC для включения поля ROVR. Обмен EDAR/EDAC происходит между 6LR и 6LBR и запускается сообщением NS(EARO) от 6LN для создания, обновления или удаления соответствующего состояния в 6LBR. Обмен защищён механизмом повтора, описанным в параграфе 8.2.6 [RFC6775], хотя в LLN, где по умолчанию принято значение RetransTimer (RETRANS_TIMER) [RFC4861] в 1 секунду, может потребоваться большее значение для учёта времени кругового обхода между 6LR и 6LBR.

В RPL [RFC6550] задана периодическая отправка DAO от 6LN по всем путям до корня, поддерживающего состояние маршрутизации в сети RPL, в течение всего срока действия, указанного источником DAO. Это означает, что для каждого адреса имеется два сообщения keep-alive, проходящие через всю сеть, – одно к корню, другое к 6LBR.

Эта спецификация не задаёт периодического обмена EDAR/EDAC через LLN. 6LR превращает периодические NS(EARO) от RUL в сообщение DAO для корня при каждом обновлении, но EDAR создаётся лишь при первой регистрации для DAD, требуемого до введения адреса в RPL. При получении сообщения DAO корень проксирует обмен EDAR для обновления состояния 6LBR от имени 6LR, как показано на рисунке 8 в параграфе 9.1.

4.3.1. Опция Capability Indication в соответствии с RFC 7400

В «6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)» [RFC7400] добавлена опция индикации возможностей (6LoWPAN Capability Indication Option или 6CIO), позволяющая узлу раскрывать свои возможности в сообщениях RA (Router Advertisement). В [RFC8505] определены биты 6CIO, включая перечисленные ниже.

Узел является маршрутизатором 6LR.

Узел является регистратором IPv6 ND, т. е. поддерживает регистрацию на основе EARO.

Узел является регистратором маршрутизации, т. е. регистратором IPv6 ND, обеспечивающим сведения о доступности для зарегистрированных адресов.

 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      |   Length = 1  |     Reserved      |D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Флаги 6CIO.

6LR, обеспечивающий услуги доступности RUL в сети RPL, как указано в этом документе, включает опцию 6CIO в свои сообщения RA и устанавливает (1) флаги L, P, E, как предписано [RFC8505] (см. 9.2. Детали работы).

5. Требования для листа, не знающего о RPL

Этот документ описывает расширение маршрутизации RPL для доступа к листьям RUL. В этом разделе описана минимальная реализация независимой от RPL функциональности, которую нужно реализовать в RUL для получения услуг маршрутизации своих адресов.

5.1. Поддержка 6LoWPAN ND

Для получения услуг маршрутизации от реализующего эту спецификацию маршрутизатора лист RUL должен поддерживать [RFC8505] и установить флаги R и T в опции EARO, как указано в параграфах 4.2.1 и 4.2.2. В параграфе 9.2.1 описано новое поведение для листа RUL, например, когда установленный в NS(EARO) флаг R не возвращается в NA(EARO), что говорит об отказе при вставке маршрута.

Предполагается, что RUL запрашивает услуги маршрутизации лишь в том случае, когда маршрутизатор является источником сообщений RA с опцией 6CIO, где установлены (1) флаги L, P и E, как описано в параграфе 4.3.1, если это не отменено в конфигурации. Предполагается также реализация листом RUL требований [RFC8928] для защиты владения его адресом.

Для листа RUL, который может быть подключён к нескольким 6LR, ожидается предпочтение маршрутизаторов, обеспечивающих услуги маршрутизации. Листу RUL нужно зарегистрироваться на всех 6LR, где он хочет получить услуги маршрутизации.

Параллельную регистрацию адреса на нескольких 6LR следует выполнять достаточно быстро с использованием одной и той же опции EARO для данного адреса. Интервал между регистрациями адреса будет аннулировать некоторые из маршрутов, пока регистрация адреса не отобразится на них.

В [RFC8505] заданы значения Status для ошибок в NA(EARO), которые могут приниматься синхронно по NS(EARO) или асинхронно. Лист RUL должен поддерживать оба варианта и воздерживаться от использования адреса, если поле Status показывает, что он был отвергнут (6.3. Обновлённое поле RPL Status).

5.2. Поддержка инкапсуляции IPv6

В параграфе 4.1.1 [RFC9008] заданы правила сигнализации о внешнем получателе (например, RUL) и туннелирования к подключающему его маршрутизатору (6LR). Для завершения туннеля IPv6-in-IPv6 лист RUL, как кост IPv6, способен декапсулировать туннельные пакеты и отбрасывать инкапсулированные пакеты, если они не адресованы ему, или передавать вышележащему уровню для дальнейшей обработки. Как указано в параграфе 4.1 [RFC9008], это не требуется [RFC8504] и туннель IPv6-in-IPv6 от корня завершается на родительском 6LR, поэтому от RUL не требуется поддержка декапсуляции IPv6-in-IPv6.

5.3. Поддержка заголовка Hop-by-Hop

Предполагается, что RUL обрабатывает Option Type в заголовке Hop-by-Hop в соответствии с параграфом 4.2 [RFC8200]. Опции RPI с Option Type = 0x23 [RFC9008] пропускаются, если не распознаны.

5.4. Поддержка заголовка Routing

Предполагается обработка листом RUL неизвестных типов Routing Header в соответствии с параграфом 4.4 [RFC8200]. Это предполагает, что заголовок SRH, имеющий тип 3 [RFC6554], игнорируется при Segments Left = 0. При ином значении Segments Left лист RUL отбрасывает пакет и передаёт по адресу отправителя пакета сообщение ICMP Parameter Problem с кодом 0, указывающее нераспознанный тип маршрутизации.

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

Этот документ задаёт новое поведение, при котором 6LR передаёт сообщения DAO по индивидуальным (раздел 9) и групповым (раздел 10) адресам от имени листьев, не знающих о RPL. Адреса RUL раскрываются как внешние цели [RFC6550]. В соответствии с [RFC9008] применяется инкапсуляция IPv6-in-IPv6 между 6LR и корнем RPL DODAG для передачи артефактов RPL и их удаления при пересылке за пределы домена RPL, например, листьям RUL.

Документ также синхронизирует отслеживание жизнеспособности корня и 6LBR. Для обоих задаётся одинаковый срок действия и одно сообщение keep-alive – RPL DAO, проходящее через сеть RPL. Другой новинкой в поведении является проксирование корнем RPL DODAG сообщений EDAR маршрутизатору 6LBR от имени 6LR (раздел 8) для любого узла, реализующего функциональность 6LN, описанную в [RFC8505].

В параграфе 6.7.7 [RFC6550] определена опция RPL Target, которую можно применять в управляющих сообщениях RPL (таких как DAO) для передачи префикса адресата. Этот документ добавляет возможность передачи поля ROVR (4.2.3. Проверка владельца маршрута) и адреса IPv6 для анонсирующего префикс узла, когда Target содержит более короткий префикс. Их использование указывается отличным от 0 полем ROVR Size и новым флагом F (параграф 6.1).

Эта спецификация определяет флаг P в опции RPL DODAG Configuration (параграф 6.2). Кроме того, спецификация обеспечивает возможность передачи поля EARO Status, определённого для 6LoWPAN ND в сообщениях RPL DAO DCO и встраиваемого в поле RPL Status (параграф 6.3).

В разделе 12 [RFC6550] описана поддержка в RPL групповых потоков, когда RPL Instance работает в режиме MOP = 3 (режим Storing с поддержкой группового трафика). Эта спецификация расширяет операции корня RPL DODAG для прокси-трансляции операции MLDv2 [RFC3810] между RUL и 6LR (10. Операции протокола для групповых адресов).

6.1. Обновлённая опция RPL Target

Эта спецификация обновляет опцию RPL Target для доставки поля ROVR, заданного для сообщений 6LoWPAN ND, что позволяет корню RPL DODAG генерировать проксируемые сообщения EDAR для 6LBR.

Target Prefix в опции RPL Target размещается слева (старшие биты) и содержит анонсируемый префикс. Префикс размером менее 128 битов указывает маршрут. В поле Prefix Length указывается число битов анонсируемого префикса – 128 для маршрута к хосту, меньшее значение для маршрута к префиксу. Остальное сохранено без изменений.

Данная спецификация добавляет флаг F, при установке которого размер Target Prefix должен быть 128, а само поле должно содержать адрес IPv6 анонсирующего узла, взятый из анонсируемого префикса. В этом случае поле Target Prefix содержит две части информации – маршрут, который может вести к хосту (в зависимости от поля Prefix Length) и адрес IPv6, который может служить для достижения анонсирующего узла и проверки маршрута.

Если флаг F сброшен (0), поле Target Prefix может быть короче 128 битов и должно выравниваться по следующей границе байта после завершения префикса. Дополнительные биты справа заполняются значением 0, как указано в параграфе 6.7.7 [RFC6550].

В соответствии с этой спецификацией поле ROVR составляет оставшуюся часть опции RPL Target. Размер ROVR задаёт новое поле ROVR Size которое взаимно однозначно сопоставляется с полем Code Suffix в сообщении EDAR (таблица 4 в [RFC8505]). Поле ROVR Size берётся из поля Flags, обновлённого в реестре IANA RPL Target Option Flags.

Обновленный формат показан на рисунке 4 и совместим с опцией Target, определённой в [RFC6550]. Рекомендуется применять обновленный формат в новых реализациях для всех режимов MOP с целью подготовки к будущим механизмам проверки владения на основе ROVR, если ограничения устройства не препятствуют этому.

 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 = 0x05 | Option Length |F|X|Flg|ROVRsz | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                Target Prefix (Variable Length)                |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
...            Registration Ownership Verifier (ROVR)         ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Обновленная опция Target.

Флаг указывающий, что поле Target Prefix содержит полный (128 битов) адрес IPv6 анонсирующего узла.

Флаг, устанавливаемый для запроса у корня выполнение проки-обмена EDAR/EDAC. Флаг устанавливается лишь в случае работы DODAG в режиме Non-Storing и установки узлом флага P в опции DODAG Configuration (параграф 6.2). Флаг может устанавливаться для хост-маршрутов к RUL и RAN, а также устанавливается для внутренних маршрутов к префиксам при установленном флаге F с использованием адреса узла в поле Target Prefix для формирования EDAR. В других случаях флаг не может устанавливаться (1).

Flg (Flags)

Два свободных бита флагов, которые отправитель должен сбрасывать (0), а получатель должен игнорировать.

ROVRsz (ROVR Size)

Размер поля ROVR в 64-битовых словах. В устаревшей опции Target поле должно иметь значение 0, как указано в [RFC6550]. Если значение поля превышает 4, размер ROVR становится неопределённым и узел не сможет проверить ROVR. Реализациям следует распространять опцию Target в восходящем направлении без изменений, для обеспечения возможности её проверки узлом-предком, поддерживающим обновлённое поле ROVR.

Registration Ownership Verifier (ROVR)

То же поле, что и в EARO [RFC8505].

6.2. Дополнительные флаги в опции RPL DODAG Configuration

Опция DODAG Configuration, определённая в параграфе 6.7.6 [RFC6550], расширена здесь для распространения данных конфигурации, влияющих на создание и поддержку DODAG, а также рабочих параметров RPL в DODAG через граф DODAG. В исходном определении 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| |P| | |A|       ...           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
                                  |4 бита |

Рисунок 5. Опция DODAG Configuration (частичное представление).

Эта спецификация определяет новый флаг P (Root Proxies EDAR/EDAC), размещённый в позиции 1 резервного поля флагов в опции DODAG Configuration (отсчёт с 0 для старшего бита), для которого установлено значение 0 в унаследованных реализациях, как указано в параграфах 20.14 и 6.7.6 [RFC6550]. Флаг P устанавливается (1) для индикации выполнения корнем операций посредника, что предполагает поддержку этой спецификации и обновлённой опции RPL Target (6.1. Обновлённая опция RPL Target).

Параграф 4.1.3 в [RFC9008] обновляет [RFC6550] для указания того, что определение флагов применимо лишь к значениям MOP от 0 до 6. Для MOP = 7 реализация должна предполагать выполнение корнем функций посредника.

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

6.3. Обновлённое поле RPL Status

Поле RPL Status определено в параграфе 6.5.1 [RFC6550] для использования в сообщениях DAO-ACK. Заданные значения приведены в таблице 1.

Таблица 1. Определение RPL Status в RFC 6550.

Диапазон	Назначение
0	Безусловное восприятие
1-127	Непрямой отказ
128-255	Отказ

Поле 6LoWPAN ND Status определено для использования в EARO (см. параграф 4.1 в [RFC8505]). Эта спецификация добавляет возможность разрешить перенос значений 6LoWPAN ND Status в сообщения RPL DAO и DCO, встраивая их в поле RPL Status.

Для решения этой задачи диапазон значений ARO/EARO Status сужен до 0-63 с обновлением реестра IANA, созданного для [RFC6775]. Это обеспечивает поддержку значений RPL Status, как показано на рисунке 6. Реестры IANA описаны в параграфах 12.2, 12.5, 12.6. Эти обновления допустимы, поскольку для реестров задана политика Standards Action в соответствии с [RFC8126] и пока распределены значения, не превышающие 10.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U|A|StatusValue|
+-+-+-+-+-+-+-+-+

Рисунок 6. Формат RPL Status.

Эта спецификация обновляет поле RPL Status, как показано ниже.

Флаг, установка (1) которого задаёт отказ (reject). При нулевом значении флага StatusValue = 0 указывает успешное восприятие, иные значения – неявный отказ (Not an outright rejection в RFC 6550).

Флаг, указывающий тип RPL StatusValue.

Status Value

6-битовое целое число без знака. При установленном (1) флаге A это поле содержит значение, определённое для 6LoWPAN ND EARO Status, при сброшенном (0) – StatusValue для RPL.

При создании сообщения DCO или DAO-ACK в ответ на IPv6 ND NA или EDAC корень RPL DODAG должен копировать код статуса 6LoWPAN ND без изменения в поле RPL Status Value и устанавливать (1) флаг A. Корень RPL DODAG должен устанавливать (1) флаг U для всех кодов отказа и неизвестного состояния. Коды из диапазона 1-10 [RFC8505] считаются индикацией отказа.

В свою очередь, при получении от корня RPL DODAG сообщения DCO или DAO-ACK с RPL Status, где установлен флаг A, маршрутизатор 6LR должен копировать значение RPL Status без изменения в поле Status опции EARO при генерации NA для RUL.

7. Расширение RFC 9009

В [RFC9009] определено сообщение DCO лишь для режима RPL Storing с областью действия на локальном канале (link-local). От всех узлов сети RPL ожидается поддержка этой спецификации, поскольку сообщение обрабатывается на каждом этапе пересылки по очищаемому пути.

Данная спецификация расширяет использование DCO на режим Non-Storing, при этом сообщения DCO передаются насквозь от корня напрямую узлу RAN, отправившему сообщение DAO для рассматриваемой цели. В этом случае от промежуточных узлов не требуется поддержка [RFC9009], они пересылают сообщение DCO как обычный пакет IPv6 между корнем и RAN.

В случае RUL обслуживающий лист маршрутизатор 6LR выступает в качестве узла RAN, получающего Non-Storing DCO. Эта спецификация применяет Non-Storing DCO между корнем и 6LR, служащим точкой присоединения RUL. Поддерживающие эту спецификацию 6LR и корень должны реализовать Non-Storing DCO.

8. Расширение RFC 6775 и RFC 8505

Этот документ обновляет [RFC6775] и [RFC8505], сужая диапазон значений ARO/EARO Status до 64. Два старших (слева) бита исходного поля ND Status сделаны резервными, они должны сбрасываться (0) отправителем и игнорироваться получателем.

Документ также обновляет поведение 6LR, служащего маршрутизатором RPL, и 6LN, служащего листом RUL в 6LoWPAN ND Address Registration, как указано ниже.

Если корень RPL DODAG анонсирует способность быть посредником в обмене EDAR/EDAC для 6LBR, маршрутизатор 6LR воздерживается от передачи сообщений EDAR keep-alive. Будучи отделенным от 6LBR, корень периодически создаёт сообщения EDAR для 6LBR по сообщению DAO, говорящему об активности адреса.
Применение флага R расширяется на сообщения NA(EARO) для подтверждения установки маршрута.

9. Протокольные операции для индивидуальных адресов

В приведённом ниже описании предполагается, что корень управляет флагом P в опции DODAG Configuration и выполняет операции посредника EDAR, описанные в параграфе 4.3. EDAR/EDAC в соответствии с RFC 8505.

Если флаг P сброшен (0), маршрутизатор 6LR должен периодически генерировать сообщения EDAR и обрабатывать возвращённый статус в соответствии с [RFC8505]. Если EDAC показывает успех, остальная часть потока выполняется, как представлено, но без проксирования обмена EDAR/EDAC.

В параграфе 9.1 приведён обзор внедрения маршрута в RPL, а в параграфе 9.2 – более подробное описание с точки зрения различных устройств, вовлечённых в поток.

9.1. Базовый поток

Эта спецификация отменяет необходимость обмена сообщениями keep-alive для EDAR и EDAC на всем пути от 6LN до 6LBR через mesh-сеть RPL. Вместо этого для обмена EDAR/EDAC с 6LBR корень RPL DODAG выступает посредником (прокси) по сообщениям DAO, обновляющим состояние маршрутизации RPL. Первое сообщение EDAR при новом Address Registration не может быть проксировано, хотя его создание для целей DAD, требует проверки до внесения адреса в RPL.

В сети RPL со включённой функцией за обновление состояния в 6LBR отвечает корень. В результате корень RPL DODAG будет сохранять на 6LBR лишь адреса, внедрённые в RPL. Поскольку листья RUL анонсируются с применением режима Non-Storing, поток DAO и EDAR/EDAC keep-alive может быть вложен в поток (пере)регистрации адресов. На рисунке 7 это показано для первой регистрации адреса с указанием обменов DAD и EDAR/EDAC keep-alive в одной последовательности.

6LN/RUL            6LR   <6LR*>   Корень             6LBR
   |<--Использ ND-->|<-Использ RPL>|<----Использ ND--->|
   |                |<----------Использ ND------------>|
   |                |              |                   |
   |   NS(EARO)     |              |                   |
   |--------------->|                                  |
   |                |            EDAR                  |
   |                |--------------------------------->|
   |                |                                  |
   |                |             EDAC                 |
   |                |<---------------------------------|
   |                |                                  |
   |                |   DAO(X=0)   |                   |
   |                |------------->|                   |
   |                |                                  |
   |                |    DAO-ACK   |                   |
   |                |<-------------|                   |
   |   NA(EARO)     |              |                   |
   |<---------------|              |                   |
   |                |              |                   |

Рисунок 7. Поток регистрации первого RUL.

Для этого потока требуется согласование сроков действия и порядковых номеров в 6LoWPAN ND и RPL. Для согласования значения Path Sequence и Path Lifetime в сообщении DAO берутся из полей Transaction ID и Address Registration lifetime в сообщении NS(EARO) от 6LN.

При первом сообщении Address Registration, показанном на рисунке 7 для режима RPL Non-Storing, обмен EDAR/EDAC выполняется в соответствии с [RFC8505]. При отказе 6LR возвращает сообщение NA с ненулевым статусом узлу 6LN, NCE не создаётся и адрес не передаётся в RPL. В иных случаях 6LR создаёт NCE и внедряет зарегистрированный адрес в маршрутизацию RPL, используя обмен DAO/DAO-ACK с корнем RPL DODAG.

6LN/RUL   <-ND->   6LR   <-RPL->  Root   <-ND->      6LBR
   |                |              |                   |
   |   NS(EARO)     |              |                   |
   |--------------->|              |                   |
   |                |   DAO(X=1)   |                   |
   |                |------------->|                   |
   |                |              |       EDAR        |
   |                |              |------------------>|
   |                |              |       EDAC        |
   |                |              |<------------------|
   |                |    DAO-ACK   |                   |
   |                |<-------------|                   |
   |   NA(EARO)     |              |                   |
   |<---------------|              |                   |

Рисунок 8. Поток регистрации следующего RUL.

6LN обновляет Address Registration для сохранения NCE в 6LR до завершения срока действия. После обновления регистрации 6LR заново внедряет соответствующий маршрут в RPL до завершения срока действия (рисунок 8).

Это заставляет корень RPL DODAG обновить состояние в 6LBR с помощью сообщения EDAC. При возникновении ошибки в проксируемом потоке EDAR код ошибки возвращается в DAO-ACK с использованием RPL Status с установленным (1) флагом A, встроенного в 6LoWPAN Status, как описано в параграфе 6.3.

6LR может получить запрошенное сообщение DAO-ACK после приёма асинхронного Non-Storing DCO, но ненулевой статус в DCO заменяет положительный статус из DAO-ACK независимо от порядка приёма. При получении первого из DAO-ACK или DCO маршрутизатор 6LR отвечает листу RUL сообщением NA(EARO).

Проблема может быть обнаружена позднее, например при переносе адреса в другой граф DODAG с 6LBR, подключённым к другому магистральному маршрутизатору 6BBR (6LoWPAN Backbone Router), как показано на рисунке 5 в параграфе 3.3 [RFC8929]. 6BBR может передать негативный статус ND, например, в асинхронном NA(EARO) для 6LBR.

В [RFC8929] предполагается, что 6LBR совмещён с корнем RPL DODAG, но если это не так, 6LBR должен переслать код состояния источнику EDAR (6LR или служащий посредником корень RPL DODAG). Код статуса ND отображается корнем RPL DODAG в поле RPL Status, а затем обратно в ND Status маршрутизатором 6LR для 6LN. Отметим, что унаследованный узел RAN, получивший сообщение Non-Storing DCO, которое он не поддерживает, будет игнорировать его в соответствии с разделом 6 в [RFC6550]. В результате он не будет знать о своей недоступности, пока не произойдёт следующий обмен RPL. Это состояние будет сбрасываться при следующем обмене Non-Storing DAO, если в DAO-ACK будет возвращена ошибка.

На рисунке 9 показан случай, где 6LBR и корень не совмещены и корень служит посредником для потока EDAR/EDAC.

6LN/RUL  <-ND->  6LR  <-RPL->  Root  <-ND->  6LBR  <-ND->  6BBR
   |              |             |              |             |
   |              |             |              |   NA(EARO)  |
   |              |             |              |<------------|
   |              |             |     EDAC     |             |
   |              |             |<-------------|             |
   |              |     DCO     |              |             |
   |              |<------------|              |             |
   |   NA(EARO)   |             |              |             |
   |<-------------|             |              |             |
   |              |             |              |             |

Рисунок 9. Асинхронное внедрение адреса.

Если корень не является посредником, EDAC с ненулевым статусом приходит в 6LR напрямую. В этом случае 6LR должен сбросить маршрут, используя DAO с Lifetime = 0 и должен распространить статус обратно в RUL через сообщение NA(EARO) со сброшенным флагом R.

RUL может прервать регистрацию в любой момент, воспользовавшись Registration Lifetime = 0. Эта спецификация требует от опции RPL Target доставки ROVR. За счёт этого потока, служащего для heartbeat, достаточно для информирования 6LBR об использовании корня в качестве посредника, как показано на рисунке 8.

Любая комбинация 6LR, корня и 6LBR может быть сжата в один узел.

9.2. Детали работы

В следующих параграфах описано поведение (1) 6LN в качестве RUL, (2) 6LR в качестве граничного маршрутизатора, обслуживающего 6LN, (3) корня RPL DODAG и (4) 6LBR в потоках управления, включающего маршрутизацию RPL в направлении RUL.

9.2.1. 6LN в качестве RUL

Эта спецификация основана на работе совместимого с 6LoWPAN ND узла 6LN/RUL, от которого ожидается указанное ниже поведение.

6LN выбирает 6LR обеспечивающий услуги доступности для RUL, указывая его опцией 6CIO в сообщениях RA с установленными (1) флагами L, P и E, как предписывает [RFC8505].
6LN получает глобальный адрес IPv6 через (1) автоматическую настройку без учёта состояния (SLAAC) [RFC4862] из опции PIO [RFC4861] в сообщении RA или (2) другим путём, например DHCPv6 [RFC8415].
После получения адреса 6LN регистрирует его и периодически обновляет регистрацию заранее в течение срока действия предыдущей регистрации, как предписано [RFC6775], для обновления NCE до завершения срока действия, указанного в EARO. 6LN устанавливает (1) флаг T, как предписано в [RFC8505]. TID увеличивается каждый раз в соответствии с параграфом 5.2.1 в [RFC8505], что полностью совместимо с параграфом 7.2 в [RFC6550]).
Как указано в параграфе 5.2 [RFC8505], 6LN может одновременно регистрировать несколько 6LR. В этом случае для всех полей в EARO устанавливаются одни значения для каждой параллельной регистрации адреса, за исключением поля Registration Lifetime и флага R, которые могут различаться. 6LN может отменить часть регистраций или перенести регистрацию с одних 6LR на другие. Для этого 6LN передаёт серию сообщений NS(EARO) с одинаковым TID, устанавливая Registration Lifetime = 0 для прежних 6LR и ненулевое значение для новых 6LR. В этом процессе узлу 6LN следует передавать NS(EARO) с ненулевым Registration Lifetime и убедиться, что хотя бы один раз был достигнут успех, прежде чем передавать NS(EARO) для прерывания другой регистрации. Это позволяет избежать оттока, связанного с временным аннулированием маршрута в сети RPL над общим родителем вовлечённых 6LR.
В соответствии с параграфом 5.1 в [RFC8505] узел 6LN, действующий как RUL, устанавливает флаг R в EARO своих регистрация, для которых нужны услуги маршрутизации. Если флаг R не возвращается в NA, лист RUL должен считать, что организация маршрутов через данный 6LR привела к отказу и следует попытаться использовать другой 6LR. Листу RUL следует обеспечить успешное завершение регистрации до сброса флага R. В случае конфликта с предшествующим правилом по сроку действия, правило для срока имеет приоритет.
6LN может использовать любой из маршрутизаторов 6LR, где он зарегистрирован, в качестве принятого по умолчанию шлюза. Использование 6LR, на котором 6LN не зарегистрирован, может приводить к отбрасыванию пакетов в 6LR функцией проверки отправителя SAVI [RFC7039], поэтому не рекомендуется.

Даже без поддержки RPL можно настроить в RUL необрабатываемое (opaque) значение, предоставляемое протоколу маршрутизации. Если RUL знает RPL Instance, куда следует поместить пакет, листу следует установить в поле Opaque опции EARO значение RPLInstanceID. В оном случае лист должен оставить в поле Opaque значение 0.

Независимо от установки поля Opaque, узел 6LN должен установить I = 0 для указания «топологической информации для передачи протоколу маршрутизации» как указано в параграфе 5.1 [RFC8505].

От RUL не ожидается создание артефактов RPL в пакетах данных, но это возможно. Например, при наличии у RUL минимальных сведений о RPL Instance, лист может создать RPI. Листу RUL, помещающему RPI в пакет данных, следует указывать RPLInstanceID экземпляра RPL, которому следует переслать пакет. Маршрутизатор 6LR принимает решение (например, в соответствии с правилами) использовать данные RPLInstanceID, предоставленные RUL, или заменить их выбранным RPLInstanceID для пересылки внутри домена RPL. Для всех флагов и поля SenderRank устанавливается значение 0, как указано в параграфе 11.2 [RFC6550].

9.2.2. 6LR в качестве граничного маршрутизатора

Маршрутизатор 6LR, обеспечивающий доступность RUL в сети RPL, как указано в этом документе, должен включать 6CIO в свои сообщения RA и устанавливать (1) флаги L, P и E, как предписано [RFC8505]. В соответствии с [RFC8505] маршрутизатор 6LR создаёт EDAR при получении действительного сообщения NS(EARO) для регистрации нового адреса IPv6 узлом 6LN. При успешном начальном обмене EDAR/EDAC маршрутизатор 6LR устанавливает в NCE значение Registration Lifetime.

При установленном флаге R в NS(EARO) маршрутизатору 6LR следует внедрить в RPL маршрут к хосту, если это не запрещено по иным причинам, таким как максимальное число родителей RPL. 6LR должен использовать сигнализацию RPL Non-Storing и обновлённую опцию Target (параграф 6.1). Для предотвращения избыточного потока EDAR/EDAC к 6LBR маршрутизатору 6LR следует воздерживаться от установки флага X. 6LR должен запросить DAO-ACK путём установки флага K в сообщении DAO. Успешное внедрение маршрута к адресу RUL указывается сбросом флага U в поле RPL Status сообщения DAO-ACK.

Если при обновлении регистрации корень RPL DODAG устанавливает флаг P в опции DODAG Configuration, 6LR должен воздерживаться от передачи EDAR keep-alive и взамен должен устанавливать флаг X в опции Target сообщений DAO для запроса обмена EDAR/EDAC keep-alive с 6LBR (параграф 6). Если флаг P сброшен, 6LR должен сбросить флаг X для самостоятельной обработки потока EDAR/EDAC.

Поле Opaque в EARO позволяет указать RPL Instance для применения в анонсах DAO и пересылки пакетов, исходящих от Registered Address, при отсутствии в пакете RPI.

Как указано в [RFC8505], при I = 0 в поле Opaque предполагается значение RPLInstanceID, предложенное 6LN, в противном случае не будет предложенного экземпляра RPL. Если 6LR участвует в предложенном RPL Instance, он должен использовать этот экземпляр RPL для Registered Address. Если нет предложенного RPL Instance или 6LR не участвует в предложенном экземпляре RPL, предполагается, что пакеты от 6LN «можно будет однозначно связать хотя бы с одним RPL Instance» [RFC6550] посредством 6LR, например, по правилу сопоставления 6-tuple с RPL Instance.

Сообщение DAO, анонсирующее Registered Address, должно создаваться, как описано ниже.

Registered Address указывается как Target Prefix в обновлённой опции Target сообщения DAO с установкой Prefix Length = 128 и сбросом флага F, поскольку анонсирующий узел не является RUL. Поле ROVR копируется из EARO (6.1. Обновлённая опция RPL Target).
6LR указывает один из глобальных или локальной уникальных unicast-адресов IPv6 как Parent Address в опции TIO, связанной с опцией Target.
6LR устанавливает флаг E в TIO для индикации распространения внешнего маршрута в сеть RPL.
Path Lifetime в TIO рассчитывается по Registration Lifetime в EARO с преобразованием секунд в единицы Lifetime Unit сети RPL. Это задаёт ограничение для развёртывания требованием совместимости Lifetime Unit с выражением Registration Lifetime, например, Lifetime Unit = 0x4000 отображает старший бит Registration Lifetime на Path Lifetime. Значение Path Lifetime должно обеспечить срок действия пути, не превышающий регистрацию и охватывающий время кругового обхода на пути к корню.

При Registration Lifetime = 0 значением Path Lifetime также будет 0 и сообщение DAO становится No-Path DAO, очищая нисходящие маршруты к RUL, а также заставляя корень быть посредником при передаче сообщения EDAR с Lifetime = 0 маршрутизатору 6LBR.
В Path Sequence опции TIO устанавливается значение TID из EARO.

При получении DAO-ACK или тайм-ауте после заданного реализацией числа попыток 6LR должен передать RUL соответствующее сообщение NA(EARO). При получении асинхронного сообщения DCO он должен сразу же передать RUL асинхронное сообщение NA(EARO), сохраняя способность обработки сообщения DAO-ACK, если оно ожидается.

6LR должен установить флаг R в NA(EARO), передаваемом обратно 6LN тогда и только тогда, когда флаг U в RPL Status сброшен, указывая, что Registered Address успешно внедрён маршрутизатором 6LR в RPL и проксирование EDAR завершилось успехом.

Если установлен флаг A в RPL Status, встроенное значение Status возвращается листу RUL в EARO Status. Если установлен также флаг U, регистрация завершается отказом по связанным с 6LoWPAN-ND причинам и NCE удаляется.

Ошибка при внедрении маршрута ведёт к установке флага U. Если ошибка не связана с ND, флаг A сбрасывается. В этом случае регистрация будет успешной, но маршрут RPL не устанавливается. В результате NA(EARO) возвращается с кодом успеха и сброшенным флагом R, означающими, что узел 6LN получил привязку, но не получил маршрута.

Сброшенный флаг A в RPL Status статус DAO-ACK говорит, что операция 6LoWPAN ND успешна и узлу 6LN должно возвращаться EARO Status = 0 (Success). Значение EARO Status = 0 должно использоваться также в случаях, когда 6LR не пытается внедрить маршрут но может создать привязку после успешного обмена EDAR/EDAC или обновить её.

Установка флага U в RPL Status сообщения DAO-ACK говорит, что маршрут не был установлен и флаг R должен быть сброшен в NA(EARO). Флаг R должен также сбрасываться, если 6LR не пытается внедрить маршрут.

В сети со включённым механизмом AP-ND⁵ в случае DAO-ACK или DCO со EARO Status = 5 (Validation Requested) маршрутизатор 6LR должен спросить у 6LN о владении адресом, как указано в параграфе 6.1 [RFC8928], до завершения регистрации. Этот поток (рисунок 10) обеспечивает проверку адреса до внедрения в маршрутизацию RPL.

6LN                                       6LR        Root        6LBR
 |                                         |           |           |
 |<--------------- RA ---------------------|           |           |
 |                                         |           |           |
 |------ NS(EARO) (ROVR=Crypto-ID) ------->|           |           |
 |                                         |           |           |
 |<-NA(EARO) (Status=Validation Requested)-|           |           |
 |                                         |           |           |
 |---- NS(EARO) и подтвержд. владения ---->|           |           |
 |                                         |           |           |
 |                            <проверка подтверждения> |           |
 |                                                     |           |
 |<------- NA(EARO) (Status=10) -----<отказ>           |           |
 |                                                     |           |
 |                                       <иначе>       |           |
 |                                         |           |           |
 |                                         |--------- EDAR ------->|
 |                                         |                       |
 |                                         |<-------- EDAC --------|
 |                                         |                       |
 |                                         |           |           |
 |                                         |-DAO(X=0)->|           |
 |                                         |           |           |
 |                                         |<- DAO-ACK-|           |
 |                                         |           |           |
 |<---------- NA(EARO) (Status=0) ---------|           |           |
 |                                         |           |           |
                                     ...
 |                                         |           |           |
 |------ NS(EARO) (ROVR=Crypto-ID) ------->|           |           |
 |                                         |-DAO(X=1)->|           |
 |                                         |           |-- EDAR -->|
 |                                         |           |           |
 |                                         |           |<-- EDAC --|
 |                                         |<- DAO-ACK-|           |
 |<---------- NA(EARO) (Status=0) ---------|           |           |
 |                                         |           |           |
                                     ...

Рисунок 10. Защита адреса.

При подтверждённом владении адресом операции продолжаются обычным путём. В частности, создаётся сообщение DAO в ответ на NS(EARO) с подтверждением владения адресом. При отказе подтверждения 6LR отвергает регистрацию, как предписано AP-ND, и может выполнить действия по защите себя от атаки на отказ в обслуживании (Denial-Of-Service или DoS) со стороны обманного 6LN (см. раздел 11. Вопросы безопасности).

6LR может в любой момент передать индивидуальное асинхронное сообщение NA(EARO) со сброшенным флагом R для индикации прекращения услуг маршрутизации и/или с EARO Status = 2 (Neighbor Cache Full) для индикации удаления NCE. Маршрутизатор может также передать финальный анонс RA (индивидуальный или групповой) с полем Lifetime = 0 для индикации прекращения работы в качестве маршрутизатора, как указано в параграфе 6.2.5 [RFC4861]. Это может быть ответом на сообщение DCO или DAO-ACK, указывающее, что путь уже удалён. В иных случаях 6LR должен удалить хост-маршрут к 6LN, используя сообщение DAO с Path Lifetime = 0.

Действительное сообщение NS(EARO) со сброшенным флагом R и отличным от 0 полем Registration Lifetime указывает, что 6LN хочет поддерживать привязку, но больше не требует услуг маршрутизации от 6LR. После приёма такого сообщения, если в соответствии с предыдущим NS(EARO) с установленным флагом R, маршрутизатор 6LR внедрял хост-маршрут к Registered Address в RPL, используя сообщения DAO, 6LR должен аннулировать хост-маршрут в RPL, используя DAO с Path Lifetime = 0. С этого момента поддержка соответствующего маршрута становится задачей 6LN, которая решается (1) сохранением активности через другой 6LR или (2) поддержкой роли RAN с самостоятельным обеспечением доступности.

При пересылке от RUL в домен RPL пакета без RPI маршрутизатор 6LR должен инкапсулироваться пакет в корень и добавить RPI. Если в пакете есть RPI, 6LR должен переписать RPI, но инкапсуляция не требуется.

9.2.3. Корень RPL DODAG

Корень RPL DODAG должен устанавливать флаг P в опции RPL DODAG Configuration создаваемых сообщений DIO (раздел 6) для указания своей роли посредника в обмене EDAR/EDAC и поддержки обновлённой опции RPL Target.

При получении DAO для каждой обновлённой опции RPL Target (параграф 6.1) с установленным флагом X корень должен уведомить 6LBR, используя обмен EDAR/EDAC. Если корень RPL DODAG совмещён с 6LBR, можно применять внутренний API.

Сообщение EDAR должно создаваться в соответствии с приведённым ниже описанием.

Целевой адрес IPv6 из опции RPL Target помещается в поле Registered Address сообщения EDAR.
Значение Registration Lifetime преобразуется из Path Lifetime версии TIO в соответствии с Lifetime Unit в сети RPL и единицей 60 секунд а сообщениях 6LoWPAN ND.
В поле TID устанавливается значение Path Sequence из TIO и указывается код ICMP 1 в сообщении EDAR.
ROVR из опции RPL Target копируется в EDAR, а для ICMP Code Suffix устанавливается подходящее значение в соответствии с таблицей 4 в [RFC8505], в зависимости от размера поля ROVR.

При получении сообщения EDAC от 6LBR корень должен передать DAO-ACK маршрутизатору 6LR, если ожидается DAO. В иных случаях корень должен передать асинхронное сообщение DCO маршрутизатору 6LR, если статус в сообщении EDAC отличается от Success. В любом случае EDAC Status встраивается в RPL Status с установленным флагом A.

Обмен EDAR/EDAC через прокси должен быть защищён таймером, для которого продолжительность и число попыток (1) зависят от реализации (2) и их следует делать настраиваемыми, поскольку корень и 6LBR обычно являются узлами с более высокой производительностью и управляемостью, чем 6LR. При тайм-ауте корень должен вернуть ошибку маршрутизатору 6LR, как указано выше, используя подходящее из сообщений DAO-ACK и DCO с установленными в RPL Status флагами A и U, а также значением RPL Status «6LBR Registry Saturated» [RFC8505].

9.2.4. 6LBR

6LBR не знают о том, что корень RPL DODAG не является новым соединением 6LR с RUL, поэтому данная спецификация не относится к ним. При получении EDAR маршрутизатор 6LBR ведёт себя в соответствии с [RFC8505] и возвращает отправителю сообщение EDAC.

10. Операции протокола для групповых адресов

Поддержка групповых потоков в RPL подробно описана в разделе 12 [RFC6550]. Эта поддержка активируется установкой MOP = 3 (режим Storing с поддержкой групповой адресации) в сообщениях DIO, формирующих DODAG. Этот раздел относится лишь к RPL Instance с режимом MOP = 3. Поддержка группового трафика в RPL не зависит от источника и работает лишь как расширение режима Storing для индивидуальных пакетов. В этой модели RPL групповые пакеты копируются и передаются как индивидуальные кадры L2 для каждого заинтересованного потомка. Это остаётся верным при пересылке между 6LR и слушателем 6LN.

Документ «Multicast Listener Discovery Version 2 (MLDv2) for IPv6» [RFC3810] обеспечивает слушающему узлу интерфейс для регистрации в групповых потоках. В модели MLD маршрутизатор является запрашивающим (querier), а хост – слушателем, который регистрируется у запрашивающего для получения копии нужного потока.

Эквивалент первой регистрации адреса показан на рисунке 11. 6LN, как слушатель MLD, передаёт незапрошенное сообщение Report маршрутизатору 6LR и это позволяет ему сразу же начать приём потока, заставляя 6LR внедрить групповой маршрут в RPL.

6LN/RUL                6LR             Root                   6LBR
   |                    |               |                       |
   | Незапрошен. Report |               |                       |
   |------------------->|               |                       |
   |                    | DAO           |                       |
   |                    |-------------->|                       |
   |                    |    DAO-ACK    |                       |
   |                    |<--------------|                       |
   |                    |               | <Если еще не Done>    |
   |                    |               | Незапрошен.  Report   |
   |                    |               |---------------------->|
   |                    |               |                       |

Рисунок 11. Поток первой групповой регистрации.

Данная спецификация не меняет MLD, но будет работать более эффективно, если асинхронные сообщения для незапрошенных Report и Done передаются узлом 6LN как индивидуальные кадры L2 маршрутизатору 6LR, особенно в беспроводной сети. 6LR выступает как базовый MLD querier с создаёт DAO с групповым адресом в Target Prefix, как указано в разделе 12 [RFC6550]. Как и для индивидуальных хост-маршрутов Path Lifetime для Target отображается из Query Interval и имеет большее значение для учёта переменной задержки распространения к корню. Корень служит посредником в обмене MLD как слушатель, а 6LBR как запрашивающий, чтобы получать пакеты извне домена RPL.

При получении DAO с опцией Target для группового адреса корень RPL DODAG проверяет регистрацию адреса в качестве слушателя и при отсутствии создаёт незапрошенное сообщение Report для группового адреса, как указано в параграфе 6.1 [RFC3810]. Сообщение Report не зависит от источника, поэтому адрес отправителя в нем не указан.

Эквивалент обновления регистрации периодически выполняет запрашивающий маршрутизатор 6LR. По истечении Query Interval маршрутизатор 6LR передаёт Multicast Address Specific Query каждому из слушателей для каждого группового адреса. Слушатели отвечают сообщениями Report, на основе которых 6LR поддерживает объединённый список групповых адресов, где есть слушатели, и анонсирует его в DAO, как указано в разделе 12 [RFC6550]. 6LR может передать General Query с нулевым значением Multicast Address. В этом случае групповой пакет передаётся заинтересованным слушателям в индивидуальных кадрах L2.

При получении Report маршрутизатор 6LR создаёт DAO с опциями Target по числу записей Multicast Address в сообщении Report, копируя поле Multicast Address в Target Prefix опции RPL Target. Сообщение DAO для режима Storing передаётся выбранным родителям 6LR. Аналогичная процедура выполняется асинхронно от описанной между корнем и маршрутизатором (например, 6LBR), обслуживающим групповые потоки на канале, где размещён корень. Сообщения Query и Report также не зависят от источника. Корень один раз включает в список каждый групповой адрес, для которого имеется хотя бы одно активное состояние группового DAO, копирую групповой адрес из DAO в поле Multicast Address записей групповых адресов в Report, как показано на рисунке 12.

6LN/RUL                6LR            Корень               6LBR
   |                    |               |                    |
   |       Query        |               |                    |
   |<-------------------|               |                    |
   |       Report       |               |                    |
   |------------------->|               |                    |
   |                    | DAO           |                    |
   |                    |-------------->|                    |
   |                    |    DAO-ACK    |                    |
   |                    |<--------------|                    |
   |                    |               |       Query        |
   |                    |               |<-------------------|
   |                    |               |       Report       |
   |                    |               |------------------->|
   |                    |               |                    |

Рисунок 12. Поток следующей регистрации.

Любая комбинация 6LR, корня и 6LBR может размещаться на одном узле и в этом случае описанные выше поток обрабатывается внутри узла и могут использоваться вызовы внутреннего API вместо передачи сообщений.

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

Следует отметить, что в [RFC6550] каждый узел LLN понимает протокол RPL и может быть точкой атаки на сеть через RPL. Данная спецификация улучшает ситуацию за счёт выделения краевых узлов, которые могут взаимодействовать лишь с маршрутизаторами RPL, используя 6LoWPAN ND, что не позволяет организовать атаку из сети RPL.

Работа узлов LLN зависит от 6LBR и участников RPL. Нужна модель доверия, обеспечивающая исполнение этих ролей «правильными» устройствами, для предотвращения таких атак, как «чёрные дыры» (см. раздел 7 в [RFC7416]), DoS-атаки, где мошеннический маршрутизатор 6LR создаёт «мешанину» в сети RPL, анонсируя и удаляя множество фиктивных адресов, «бомбардировка», в которой злонамеренный маршрутизатор 6LBR разрушает состояния сети, используя код состояния 4 (“Removed”) [RFC8505]. Такая модель доверия может быть основана на защищённых подключениях L2 и защите канального уровня, что является базовым требованием к 6LoWPAN (см. требование 5.1 в Приложении B.5 [RFC8505]).

К данной спецификации в целом применимы разделы «Вопросы безопасности» [RFC6550], [RFC7416], [RFC6775], [RFC8505]. В частности, нужна защита на канальном уровне для предотвращения DoS-атак, в которых злонамеренный узел 6LN создаёт «мешанину» в сети RPL, постоянно регистрируя и отменяя адреса путём установки флага R в EARO.

В [RFC8928] к 6LoWPAN ND добавлен механизм AP-ND, защищающий владельца адреса от «кражи» адреса и атак с подставными устройствами в LLN. Поддерживающие расширение узлы рассчитывают криптографический идентификатор (Crypto-ID) и применяют его с одним или несколькими зарегистрированными адресами. Crypto-ID указывает владельца Registered Address и может служить для подтверждения владения зарегистрированными адресами. После регистрации адреса с Crypto-ID и подтверждения владения им регистрационные данные может менять лишь владелец, фактически реализуя SAVI. [RFC8928] дополнительно сужает фронт атак для граничных узлов и данная спецификация предлагает использовать это.

Модель доверия может также включать проверку ролей (например, контроль полномочий по роли) для того, чтобы функциональность 6LBR или корня RPL DODAG была доступна лишь уполномоченным устройствам.

Поле Opaque в EARO позволяет листу RUL указать RPLInstanceID для размещения трафика. RUL злоумышленника может включать в пакет опцию RPI, что открывает дверь для атак при резервировании RPL Instance для критического трафика, например, путём резервирования пропускной способности, когда трафик злоумышленника может нарушать работу. Такую атаку можно ослабит обычными механизмами контроля доступа и формовки трафика, где 6LR контролирует входящий трафик от 6LN. Более важно, что 6LR является узлом, внедряющим трафик в домен RPL, поэтому последним словом является выбор экземпляра RPL для трафика, входящего от RUL в соответствии с политикой. В частности, политика может переопределять формальный язык, который заставляет использовать поле Opaque или переписывать опцию RPI, предоставленную RUL, когда администратор сочтёт это нужным.

На момент создания этого документа в RPL не было модели проверки владения маршрутом, позволяющей проверить источник адреса, внедрённого в DAO. Эта спецификация делает первый шаг в данном направлении, позволяя корню запрашивать RUL через обслуживающий лист маршрутизатор 6LR.

В параграфе 6.1 указано, что при неизвестном размере поля ROVR опция RPL Target должна передаваться в том виде, как она получена в режиме RPL Storing. Это позволяет использовать сообщения DAO в качестве скрытого канала. Сообщения DAO достаточно редки и чрезмерное использованием канала может быть обнаружено. Реализации следует уведомлять систему управления сетью при получении опции RPL Target с неизвестным размером поля ROVR, чтобы администратор знал о таких ситуациях.

[RFC9009] позволяет любому фиктивному узлу общего предка аннулировать маршрут от имени целевого узла. В таком случае RPL Status в DCO имеет сброшенный флаг A, а NA(EARO) возвращается узлу 6LN со сброшенным флагом R. Это заставляет 6LN попытаться использовать другой маршрутизатор 6LR. При наличии 6LR, не пользующегося обманным общим предком, 6LN в конечном итоге добъётся доступности через сеть RPL вопреки обманному узлу.

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

12.1. Реестр флагов опции Address Registration

Раздел 9.1 в [RFC8505] создал реестр 8-битовых значений поля Address Registration Option Flags. Агентство IANA переименовало первых столбец этого реестра (ARO Status) в Bit Number.

12.2. Изменение числа значений ARO Status

Раздел 12 в [RFC6775] создал реестр Address Registration Option Status Values со значениями от 0 до 255. Данная спецификация сужает диапазон до 0-63 (параграф 6.3) и агентство IANA изменило реестр, задав верхнюю границу 63 и добавило ссылку на данный документ. Процедура регистрации не изменилась.

12.3. Новый флаг опции RPL DODAG Configuration

Агентство IANA выделило указанный в таблице 2 флаг в реестре DODAG Configuration Option Flags for MOP 0..6 [RFC9008].

Таблица 2. Флаг опции DODAG Configuration.

Номер бита	Описание	Документ
1	Root Proxies EDAR/EDAC (P)	RFC 9010

В реестр RPL Mode of Operation добавлена ссылка на данный документ для MOP 7.

12.4. Реестр флагов опции RPL Target

Этот документ обновляет реестр RPL Target Option Flags, заданный параграфом 20.15 в [RFC6550]. Сейчас этот реестр включает лишь 4 бита (параграф 6.1) и содержит ссылку на данный документ. Процедура регистрации не изменилась.

В параграфе 6.1 определены две новых записи (таблица 3).

Таблица 3. Флаги опции RPL Target.

Номер бита	Описание	Документ
0	Advertiser address in Full (F)	RFC 9010
1	Proxy EDAR Requested (X)	RFC 9010

12.5. Субреестр значений RPL Non-Rejection Status

Агентство IANA создало в реестре Routing Protocol for Low Power and Lossy Networks (RPL) новый субреестр значений RPL Non-Rejection Status для использования в сообщениях RPL DAO-ACK, DCO и DCO-ACK со сброшенным флагом A и установленным флагом U.

Положительные значения являются 6-битовыми целыми числами без знака (0..63).
Регистрация выполняется по процедуре IETF Review [RFC8126].
Начальное значение указано в таблице 4.

Таблица 4. Значения восприятия для RPL Status.

Значение	Описание	Документ
0	Успех, безусловное восприятие	RFC 6550 и RFC 9010
1 – 63	Не выделены

12.6. Субреестр значений RPL Rejection Status

Агентство IANA создало в реестре Routing Protocol for Low Power and Lossy Networks (RPL) новый субреестр значений RPL Rejection Status для использования в сообщениях RPL DAO-ACK, DCO и DCO-ACK со сброшенным флагом A и установленным флагом U.

Положительные значения являются 6-битовыми целыми числами без знака (0..63).
Регистрация выполняется по процедуре IETF Review [RFC8126].
Начальные значения указаны в таблице 5.

Таблица 5. Значения отказов для RPL Status.

Значение	Описание	Документ
0	Безусловный отказ	RFC 9010
1	Нет маршрутной записи	RFC 9009
2 – 63	Не выделены

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

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

[RFC3810] Vida, R., Ed. and L. Costa, Ed., “Multicast Listener Discovery Version 2 (MLDv2) for IPv6”, RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6)”, RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.

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

[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, “Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)”, RFC 6775, DOI 10.17487/RFC6775, November 2012, <https://www.rfc-editor.org/info/rfc6775>.

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

[RFC7400] Bormann, C., “6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)”, RFC 7400, DOI 10.17487/RFC7400, November 2014, <https://www.rfc-editor.org/info/rfc7400>.

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

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

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

[RFC8504] Chown, T., Loughney, J., and T. Winters, “IPv6 Node Requirements”, BCP 220, RFC 8504, DOI 10.17487/RFC8504, January 2019, <https://www.rfc-editor.org/info/rfc8504>.

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

[RFC8928] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, “Address-Protected Neighbor Discovery for Low-Power and Lossy Networks”, RFC 8928, DOI 10.17487/RFC8928, November 2020, <https://www.rfc-editor.org/info/rfc8928>.

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

[RFC9009] Jadhav, R.A., Ed., Thubert, P., Sahoo, R.N., and Z. Cao, “Efficient Route Invalidation”, RFC 9009, DOI 10.17487/RFC9009, April 2021, <https://www.rfc-editor.org/info/rfc9009>.

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

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration”, RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.

[RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, “IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals”, RFC 4919, DOI 10.17487/RFC4919, August 2007, <https://www.rfc-editor.org/info/rfc4919>.

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

[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, “An IPv6 Routing Header for Source Routes with the Routing Protocol for Low-Power and Lossy Networks (RPL)”, RFC 6554, DOI 10.17487/RFC6554, March 2012, <https://www.rfc-editor.org/info/rfc6554>.

[RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, “Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing”, RFC 6606, DOI 10.17487/RFC6606, May 2012, <https://www.rfc-editor.org/info/rfc6606>.

[RFC6687] Tripathi, J., Ed., de Oliveira, J., Ed., and JP. Vasseur, Ed., “Performance Evaluation of the Routing Protocol for Low-Power and Lossy Networks (RPL)”, RFC 6687, DOI 10.17487/RFC6687, October 2012, <https://www.rfc-editor.org/info/rfc6687>.

[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., “Source Address Validation Improvement (SAVI) Framework”, RFC 7039, DOI 10.17487/RFC7039, October 2013, <https://www.rfc-editor.org/info/rfc7039>.

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

[RFC8025] Thubert, P., Ed. and R. Cragie, “IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Paging Dispatch”, RFC 8025, DOI 10.17487/RFC8025, November 2016, <https://www.rfc-editor.org/info/rfc8025>.

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

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

[RFC8929] Thubert, P., Ed., Perkins, C.E., and E. Levy-Abegnoli, “IPv6 Backbone Router”, RFC 8929, DOI 10.17487/RFC8929, November 2020, <https://www.rfc-editor.org/info/rfc8929>.

Приложение A. Пример сжатия

На рисунке 13 показан режим Storing для случая приема пакета из Internet, его инкапсуляции корнем для внедрения в RPI и доставки маршрутизатору 6LR, являющемуся родителем конечного получателя, для которого неизвестно о поддержке [RFC8138].

+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
|11110001|SRH-6LoRH| RPI-  |IP-in-IP| NH=1      |11110CPP| UDP | UDP
|Page 1  |Type1 S=0| 6LoRH | 6LoRH  |LOWPAN_IPHC| UDP    | hdr |Payld
+-+ ... -+-+ ... +-+- ... -+-+ ... -+-+-+ ... +-+-+ ... -+ ... +-...
         <-4 байта->                <-        RFC 6282        ->
                                    <-     Нет артефактов RPL ...

Рисунок 13. Инкапсуляция для родительского 6LR в режиме Storing.

Отличие от примера на рисунке 19 в [RFC8138] состоит в добавлении SRH-6LoRH перед RPI-6LoRH для транспортировки сжатого адреса 6LR в качестве адреса получателя во внешнем заголовке IPv6. На рисунке 19 в [RFC8138] IP-адрес получателя во внешнем заголовке опущен и неявно является адресом получателя из внутреннего заголовка. Тип 1 выбран произвольно, а нулевой размер обозначает единственный адрес в SRH.

На рисунке 13 источником инкапсуляции IPv6-in-IPv6 является корень, поэтому он исключен из IPv6-in-IPv6 6LoRH. Адресатом является родительский маршрутизатор 6LR для получателя инкапсулированного пакета, поэтому игнорировать его нельзя. Если DODAG работает в режиме Storing, это будет единственной записью в SRH-6LoRH, а поле SRH-6LoRH Size содержит 0. SRH-6LoRH является первым 6LoRH в цепочке. В этом примере адрес 6LR можно сжать до 2 байтов, поэтому применяется тип 1. В результате общий размер SRH-6LoRH составляет 4 байта.

В режиме In Non-Storing инкапсуляция из корня будет аналогична представленной на рисунке 13 возможно с большим числом интервалов пересылки в SRH-6LoRH множеством SRH-6LoRH, если для разных адресов в заголовке маршрутизации применяются разные форматы сжатия. Отметим, что на последнем этапе пересылки к родительскому 6LR заголовок RH3 потребляется и удаляется из сжатой формы, поэтому форматы пакетов в режимах Non-Storing и Storing не различаются.

За SRH-6LoRH следует RPI-6LoRH, затем IPv6-in-IPv6 6LoRH. При удалении IPv6-in-IPv6 6LoRH удаляются также все предшествующие заголовки 6LoRH. Paging Dispatch [RFC8025] также может удаляться, сли предыдущая страница Page не сменилась на страницу, отличную от 0 и 1, поскольку LOWPAN_IPHC кодируется одинаково на принятой по умолчанию Page 0 и Page 1. Результирующий пакет для адресата является инкапсулированным с компрессией [RFC6282].

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

Авторы благодарны Ines Robles, Georgios Papadopoulos и особенно Rahul Jadhav и Alvaro Retana за их рецензии и вклад в документ. Большое спасибо также Éric Vyncke, Erik Kline, Murray Kucherawy, Peter van der Stok, Carl Wallace, Barry Leiba, Julien Meuric и особенно Benjamin Kaduk и Elwyn Davies за их рецензии и полезные комментации на сессиях IETF Last Call и IESG review.

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

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

Michael C. Richardson

Sandelman Software Works

Email: mcr+ietf@sandelman.ca

URI: https://www.sandelman.ca/

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

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

nmalykh@protokols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3Neighbor Solicitation – запрос соседства.

4Neighbor Advertisement – анонсирование соседа.

5Address-Protected Neighbor Discovery – обнаружение соседей с защитой адреса.