RFC 9008 Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane

Опубликовано 13.04.2021 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                       M.I. Robles
Request for Comments: 9008                                 UTN-FRM/Aalto
Updates: 6550, 6553, 8138                                  M. Richardson
Category: Standards Track                                            SSW
ISSN: 2070-1721                                               P. Thubert
                                                                   Cisco
                                                              April 2021

Using RPI Option Type, Routing Header for Source Routes, and IPv6-in-IPv6 Encapsulation in the RPL Data Plane

Применение типа опции RPI, Routing Header для Source Route и инкапсуляции IPv6-in-IPv6 в плоскости данных RPL

PDF

Аннотация

В этом документе рассматриваются различные потоки данных через сети LLN1, использующие протокол RPL2 для организации маршрутов. Рассматриваются варианты, где в плоскости данных требуются тип опций RPI3 (RFC 6553), заголовки RPL Source Route (RFC 6554), и инкапсуляция IPv6-in-IPv6. Анализ обеспечивает базу для разработки эффективной компрессии этих заголовков. Документ обновляет RFC 6553 путем добавления RPI Option Type, RFC 6550 путем определения флага в опцию конфигурации DIO4 для указания внесённого изменения и RFC 8138 путем добавления типа опции при декомпрессии RPL Option.

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

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

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

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

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

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

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

1. Введение

Протокол RPL [RFC6550] используется для маршрутизации в сетях с ограниченными возможностями. В [RFC6553] определена опция RPL, передаваемая в заголовке IPv6 Hop-by-Hop Options для переноса RPLInstanceID и быстрого обнаружения несогласованности (петли) сетевой топологии. Опцию RPL обычно называют RPI7, хотя RPI – это информация, определённая в [RFC6550] и передаваемая в RPL Option. В RFC 6554 [RFC6554] определён заголовок RH38, являющийся заголовком расширения IPv6 для доставки дейтаграмм в домене маршрутизации RPL, в частности для режима Non-Storing (без сохранения).

Эти элементы называют артефактами RPL (artifact) и они наблюдаются во всем трафике плоскости данных сетей с маршрутизацией RPL. Как правило артефакты не возникают в плоскости управления RPL, где обычно передаётся пошаговый (hop-by-hop) трафик (единственным исключением служат сообщения DAO в режиме Non-Storing).

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

Рабочая группа ROLL9 проанализировала применение правил IPv6 [RFC2460] к режимам Storing и Non-Storing протокола RPL. В результате было выделено 24 варианта использования плоскости данных, полностью рассмотренных здесь во избежание неоднозначностей. Во время подготовки этого документа в [RFC8200] были опубликованы новые правила и документ был обновлён с учётом нормативных изменений.

Документ обновляет [RFC6553], меняя Option Type для RPL Option, чтобы маршрутизаторы, совместимые с [RFC8200], игнорировали эту опцию, если она им не понятна.

Routing Header Dispatch для 6LoWPAN10 (6LoRH) [RFC8138] определяет механизм сжатия данных RPL Option и Routing Header типа 3 (RH3) [RFC6554], а также эффективную инкапсуляцию IPv6-in-IPv6.

Большинство из описанных здесь вариантов применения используют инкапсуляцию пакетов IPv6-in-IPv6. При инкапсуляции и декапсуляции пакетов должны применяться правила [RFC6040] для сопоставления поля явной индикации перегрузки (explicit congestion notification или ECN) во внутреннем и внешнем заголовке. Рекомендуется изучить документ [TUNNELS], разъясняющий связь между туннелями IP и существующими уровнями протоколов, а также проблемы, связанные с туннелированием IP.

Неограниченное применение RPL выходит за рамки этого документа, а заявления о применимости для таких приложений могут содержать различные рекомендации, например [ACP].

1.1. Обзор

Раздел 2 посвящён используемой в документе терминологии, раздел 3 содержит обзор RPL, раздел 4 описывает обновления RFC 6553, RFC 6550, RFC 8138. В разделе 5 рассмотрена топология, используемая в примерах применения, раздел 6 перечисляет рассмотренные варианты применения, раздел 7 посвящён вариантам режима Storing, раздел 8 – вариантам режима Non-Storing. В разделе 9 рассматриваются операционные вопросы поддержки не осведомленных о RPL листьев, в разделе 10 – операционные вопросы, связанные с изменением RPI Option Type. Раздел 11 посвящён реестрам IANA, а раздел 12 – вопросам безопасности.

2. Терминология и уровни требований

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

В [RFC7102] определены используемые в этом документе термины LLN, RPL, RPL domain, ROLL.

Consumed

Routing Header «потребляется» при нулевом значении поля Segments Left, означающем, что получатель в заголовке IPv6 является конечным адресатом пакета и все интервалы пересылки из Routing Header пройдены.

RPL Leaf – лист RPL

Хост IPv6, подключенный к маршрутизатору RPL и получающий связность через RPL DODAG11. Предполагается, что лист RPL будет игнорировать поглощённый Routing Header как узел IPv6 и заголовок Hop-by-Hop Options – как хост IPv6. В результате лист RPL может корректно получать пакеты с артефактами RPL, при этом не предполагается, что он не будет создавать артефакты RPL или поддерживать инкапсуляцию IP-in-IP. Далее в документе для сокращения используется термин «лист» вместо «лист RPL».

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

Информация, абстрактно определённая в [RFC6550], для размещения в пакетах IP. Этот термин обычно служит (в том числе здесь) для обозначения RPL Option [RFC6553] с этой абстрактной информацией в заголовке IPv6 Hop-by-Hop Options. В [RFC8138] представлено более сжатое форматирования той же абстрактной информации.

RPL-Aware Node (RAN) – понимающий RPL узел

Устройство, реализующее протокол RPL. Такие устройства могут находиться как в сетях LLN, так и вне их.

RPL-Aware Leaf (RAL) – понимающий RPL лист

Не знающий о RPL узел, который является также листом RPL.

RPL-Unaware Node – не понимающий RPL узел

Устройство, не реализующее RPL. Отметим, что такие устройства могут быть в составе LLN.

RPL-Unaware Leaf (RUL) – не понимающий RPL лист

Знающий о RPL узел, который является также листом RPL.

6LoWPAN Node (6LN) – узел 6LoWPAN

Определение из [RFC6775]: «Узлом 6LoWPAN является любой хост или маршрутизатор, участвующий в LoWPAN. Термин применяется, когда хост или маршрутизатор может играть описанную роль». В этом документе 6LN является листом.

6LoWPAN Router (6LR) – маршрутизатор 6LoWPAN

Определение из [RFC6775]: «Промежуточный маршрутизатор в LoWPAN, способный передавать и принимать Router Advertisement (RA) и Router Solicitation (RS), а также пересылать и маршрутизировать пакеты IPv6. Маршрутизаторы 6LoWPAN присутствуют лишь в топологиях route-over».

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

Определение из [RFC6775]: «Граничный маршрутизатор, расположенный на стыке сетей 6LoWPAN или между сетью 6LoWPAN и другой сетью IP. На границе сети 6LoWPAN может быть один или несколько маршрутизаторов 6LBR. Они отвечают за распространение префиксов IPv6 для обслуживаемых сетей 6LoWPAN. Изолированная сеть LoWPAN также включает маршрутизатор 6LBR, предоставляющий префиксы для неё».

Flag Day – “день флага”

Время, когда конфигурация сети меняется так, что узлы со старой конфигурацией не могут взаимодействовать с обновлёнными узлами. Примером может служить переход ARPANET от IP версии 3 к IP версии 4 1 января 1983 г. [RFC0801]. В контексте этого документа – переход от RPI Option Type (0x63) к Option Type (0x23), представляющий собой серьёзную замену. Для снижения времени на такой переход в параграфе 4.1.3 представлен механизм, позволяющий обновлять узлы постепенно.

Non-Storing Mode (Non-SM) – режим без хранения

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

Storing Mode (SM) – режим с хранением

Режим работы RPL, при котором понимающие RPL узлы (6LR) поддерживают состояние маршрутизации (от потомков) и источнику не требуется задавать маршрут.

3. Обзор RPL

RPL определяет управляющее сообщение (плоскость управления), которое является сообщением ICMPv6 [RFC4443] типа 155. Сообщения DIS (DODAG Information Solicitation), DIO (DODAG Information Object), DAO (Destination Advertisement Object) являются управляющими сообщениями RPL и имеют свои коды. Стек RPL показан на рисунке 1.

+--------------+
| Вышележащие  |
|   уровни     |
+--------------+
|   RPL        |
+--------------+
|   ICMPv6     |
+--------------+
|   IPv6       |
+--------------+
|   6LoWPAN    |
+--------------+
|   PHY-MAC    |
+--------------+

Рисунок 1. Стек RPL.


RPL поддерживает два режима внутреннего нисходящего (Downward) трафика. Режим Storing (SM) полностью поддерживает состояние, в Non-Storing (non-SM) маршрутизацию задаёт источник. Экземпляр RPL работает в режиме Storing или Non-Storing, а RPL Instance с комбинацией узлов Storing и Non-Storing не поддерживается текущей спецификацией. Внешние маршруты анонсируются сообщениями non-SM даже в сети SM (4.1.1. Анонсирование внешних маршрутов с сигнализацией режима Non-Storing).

4. Обновления RFC 6550, RFC 6553, RFC 8138

4.1. Обновления RFC 6550

4.1.1. Анонсирование внешних маршрутов с сигнализацией режима Non-Storing

В параграфе 6.7.8 [RFC6550] определён флаг E для указания того, что маршрутизатор 6LR, создающий DAO распространяет внешние маршруты (цели) в сеть RPL. Внешней считается цель, полученная от другого протокола (например, префикс вне домена RPL), но доступная через 6LR. Находясь за пределами домена RPL, доступный через внешнюю цель узел не может гарантировать игнорирование артефактов RPL. От такого узла также не ожидается корректная обработка сжатия, заданного в [RFC8138]. Это означает, что артефакты RPL следует помещать в инкапсуляцию IP-in-IP, которая удаляется маршрутизатором 6LR, а сжатие следует обрабатывать на 6LR до пересылки пакета за пределы домена RPL.

Эта спецификация обновляет [RFC6550], указывая, что рекомендуется анонсировать внешние цели с использованием сообщений DAO режима Non-Storing даже при работе сети в режиме Storing. Таким образом, внешние маршруты не анонсируются внутри DODAG и все пакеты для внешней цели достигают корня как обычный трафик в режиме Non-Storing. Сообщения DAO режима Non-Storing сообщают корню адрес маршрутизатора 6LR, добавившего внешний маршрут, и корень использует инкапсуляцию IP-in-IP для 6LR, который завершает туннель IP-in-IP и пересылает исходный пакет за пределы домена RPL без артефактов RPL.

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

Лист RUL является особым случаем внешней цели, которая в действительности является хостом и заведомо поддерживает потребляемый заголовок Routing, а также игнорирует заголовок Hop-by-Hop Options, как предписано [RFC8200]. Узнать о цели можно от внешнего протокола маршрутизации или путем её регистрации на 6LR с использованием [RFC8505].

Для включения IP-in-IP на всем пути к 6LN полезна поддержка декапсуляции IP-in-IP в 6LN, но [RFC8504] не предполагает этого. Если 6LN является RUL, инкапсулирующему пакеты корню следует завершать туннель в родительском 6LR. Корень может инкапсулировать пакеты для всего пути к RUL, если он знает, что RUL поддерживает инкапсуляцию IP-in-IP и артефакты в цепочке внешних заголовков.

От доступного по внешнему маршруту узла не ожидается поддержка [RFC8138]. Независимо от выполнения декапсуляции и доставки маршрутизатором 6LR пакетов листу RUL, вносящий внешний маршрут 6LR должен выполнить декомпрессию пакета, сжатого в соответствии с [RFC8138], перед его пересылкой по внешнему маршруту.

4.1.2. Опции конфигурации и режим работы

В параграфе 6.7.6 [RFC6550] описана опция DODAG Configuration, содержащая набор флагов в первом октете. В преддверии будущих работ по пересмотру RPL в части настройки конфигурации LLN и DODAG этот документ меняет название субреестра IANA DODAG Configuration Option Flags так, чтобы он применялся лишь к режимам работы (Mode of Operation или MOP) от 0 до 6, оставляя невыделенными флаги для режима MOP = 7. Режимы MOP описаны в параграфе 6.3.1 [RFC6550]. Кроме того, этот документ резервирует значение MOP = 7 для будущих расширений (см. параграфы 11.2 и 11.3).

4.1.3. Индикация нового RPI во флаге опции DODAG Configuration

Для предотвращения проблем, связанных с отсутствием взаимодействия между узлами (flag day) с новым RPI Option Type (0x23) и старым RPI Option Type (0x63) в этом параграфе определён флаг опции DODAG Configuration, указывающий возможность безопасного применения нового типа RPI Option. Флаг указывает значение Option Type, которое сеть будет использовать для RPL Option. Таким образом, при вхождении узла в сеть он будет получать используемое значение. Благодаря этому узлы с поддержкой RPL узнают, можно ли применять тип 0x23 при создании новой опции RPL. Пересылающему пакет с RPI узлу недопустимо менять Option Type в RPL Option.

Это делается с помощью флага опции DODAG Configuration, указывающего «включение RPI 0x23» и распространяемого по сети. В параграфе 6.3.1 [RFC6550] определено 3-битовое поле режима работы (MOP) в базовом объекте DIO. Флаг определён лишь для значений MOP от 0 до 6. Для MOP = 7 узел должен применять RPI 0x23.

Как указано в [RFC6550], опция DODAG Configuration передаётся в сообщениях DIO и содержит данные конфигурации. Опция обычно статична и не меняется внутри графа DODAG. Конфигурацию задаёт корень DODAG и она распространяется по DODAG в опциях DODAG Configuration. Узлы, не являющиеся корнем DODAG, не меняют содержимого опции DODAG Configuration.

В настоящее время для неиспользуемых битов опции DODAG Configuration в [RFC6550] сказано: «Отправитель должен устанавливать 0, а получатель должен игнорировать поле». При получении сообщения с нулевым полем флагов (принято по умолчанию) новые узлы будут сохранять совместимость с RFC 6553 – исходящий трафик имеет старое значение RPI Option Type (0x63). Если получен флаг со значением 1, должно устанавливаться RPL Option 0x23.

Бит 3 в поле Flags опции DODAG Configuration должен использоваться в соответствии с таблицей 1 (совпадает с таблицей 36 и приведена здесь для удобства).

Таблица 1. Флаг опции DODAG Configuration для индикации RPI Flag Day.

Номер бита

Описание

Документ

3

Тип RPI 0x23 разрешён

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

При перезагрузке узел (6LN или 6LR) не запоминает тип RPI Option (т. е. состояние флага), поэтому он не будет вызывать сообщений DIO до получения DIO, указывающего используемое значение RPI. Узел будет применять значение 0x23, если сеть поддерживает это.

4.2. Обновление RFC 6553 – индикация нового типа RPI Option

Это изменение требуется для обеспечения возможности передачи, например, пакетов IPv6 из понимающего RPL листа узлу, не поддерживающему RPL, через сеть Internet (7.2.1. Поток от RAL в Internet) без инкапсуляции IPv6-in-IPv6.

В разделе 6 [RFC6553] сказано (см. таблицу 2), что в поле Option Type опции RPL два старших бита должны иметь значение 01, а третий бит – 1. Первые два бита указывают, что узел IPv6 должен отбрасывать пакеты с неизвестным Option Type, а третий указывает возможность смены Option Data на маршруте. Остальные биты задают Option Type.

Таблица 2. Option Type в опции RPL.

Шестнадцатеричное значение

Двоичное значение

Описание

Документ

act

chg

rest

0x63

01

1

00011

RPL Option

[RFC6553]

В этом документе показано, что источник не всегда может быть уверен в прохождении пакета лишь через домен RPL. В момент публикации [RFC6553] перетекание заголовка Hop-by-Hop Options во внешнюю цепочку заголовков IPv6 могла влиять на маршрутизаторы ядра в Internet. По этой причине было принято решение инкапсулировать все пакеты с RPL Option в формат IPv6-in-IPv6 во всех случаях, когда не было ясно, останется ли пакет в домене RPL. В исключительных случаях, когда пакеты будут уходить, Option Type гарантирует, что первый маршрутизатор Internet, не распознавший её, отбросит пакет и защитит остальную сеть.

Даже со сжатием заголовка IPv6-in-IPv6 [RFC8138] это ведёт к добавлению байтов в пакет, связанному с потреблением дополнительной энергии и пропускной способности, росту потерь и возможности фрагментации на уровне 6LoWPAN. Это влияет на повседневную работу устройств с ограничениями в случаях, которые обычно достаточно редки и не оказывает существенного влияния на ядро в целом.

Хотя намерение заключается в том, чтобы заголовок Hop-by-Hop Options с RPL Option не выходил за пределы домена RPL, данная спецификация меняет поведение с целью снижения зависимости от инкапсуляции IPv6-in-IPv6 и защиты устройств с ограничениями. В разделе 4 [RFC8200] разъяснено поведение маршрутизаторов в Internet следующим образом: «сейчас предполагается, что промежуточные узлы будут проверять и обрабатывать Hop-by-Hop Options только в тех случаях, когда это явно задано в их конфигурации.»

Когда перемещение пакета непонятно, отправителю предпочтительно не инкапсулировать его, принимая во внимание возможность выхода пакета из сети RPL на пути к адресату. В этом случае пакет должен прийти к получателю, а не быть Если узле Internet настроен на обработку заголовка Hop-by-Hop Options и встречает Option Type с двумя первыми битами 01, он отбросит пакет в соответствии с [RFC8200]. Хостам следует делать это независимо от конфигурации.

Поэтому данный документ обновляет Option Type в RPL Option [RFC6553], называемый для простоты RPI Option Type (таблица 3). Два старших бита должны иметь значение 00, а третий – 1. Первые два бита указывают, что узел IPv6 должен пропустить эту опцию и продолжить обработку заголовка ([RFC8200], параграф 4.2), если он не понимает Option Type, а третий бит устанавливается для индикации возможности смены Option Data на пути. Значения 5 битов справа не меняется – 0x3 (00011). Это гарантирует, что пакет, покинувший домен RPL в сети LLN (или саму сеть LLN), не будет отброшен в результате наличия опции RPL.

С новым Option Type при получении (промежуточным) узлом IPv6 (не знающим RPL) пакета с RPL Option ему следует игнорировать Hop-by-Hop RPL Option (пропустить опцию и продолжить обработку заголовка). Это актуально в случаях наличия потока от RAL в Internet (7.2.1. Поток от RAL в Internet). Это существенно меняет [RFC6553].

Таблица 3. Пересмотр Option Type в опции RPL.

Шестнадцатеричное значение

Двоичное значение

Описание

Документ

act

chg

rest

0x23

00

1

00011

RPL Option

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

Без описанной ниже сигнализации это изменение будет препятствовать взаимодействию (flag day) в имеющихся сетях, использующих 0x63 в качестве значения RPI Option Type. Переход к значению 0x23 не будет понятен в этих сетях. Реализациям RPL предлагается при обработке заголовка воспринимать оба значения 0x63 и 0x23.

При пересылке пакетов реализациям следует использовать значение RPI Type, которое было получено. Это требование обусловлено тем, что RPI Option Type не меняется на пути ([RFC8200], параграф 4.2). Это позволяет постепенно обновлять сеть, а корень DODAG будет знать, какие части сети были обновлены.

При создании новых пакетов реализации следует иметь возможность определить значение для включения в пакет. Это контролируется опцией DODAG Configuration (4.1.3. Индикация нового RPI во флаге опции DODAG Configuration).

Смена RPI Option Type 0x63 на 0x23 делает все узлы, соответствующие параграфу 4.2 [RFC8200], устойчивыми к артефактам RPL и больше не требуется удалять артефакты при передаче трафика в Internet. Это изменение проясняет, когда использовать заголовки IPv6-in-IPv6 и как адресовать их – заголовок Hop-by-Hop Options с RPI должен добавляться, когда 6LR порождает пакеты (без заголовков IPv6-in-IPv6), а заголовки IPv6-in-IPv6 должны добавляться, когда 6LR определяет, что нужно вставить заголовок Hop-by-Hop Options с RPL Option. Заголовок IPv6-in-IPv6 адресуется корню RPL для восходящего направления и хосту для нисходящего.

В режиме Non-Storing работа с не понимающими RPL узлами-листьями много проще, поскольку 6LBR (корень DODAG) имеет полные сведения о соединениях всех узлов DODAG и весь трафик идёт через корневой узел. 6LBR может распознавать не понимающие RPL узлы-листья, поскольку он будет получать сообщения DAO и них от 6LR, расположенного непосредственно над узлом, не понимающим RPL.

Режим Non-Storing не требует смены типа 0x63 на 0x23, поскольку корень всегда может создать правильный пакет. Смена Type не оказывает негативного влияния в режиме Non-Storing (см. параграф 4.1.3).

4.3. Обновление RFC 8138 – индикация способа декомпрессии

Это обновление требуется для обеспечения возможности декомпрессии RPL Option с новым Option Type 0x23.

Заголовок RPI-6LoRH содержит сжатую форму RPL RPI (см. раздел 6 в [RFC8138]). Узел, выполняющий декомпрессию, должен делать это используя активное значение RPI Option Type, т. е. выбрать 0x23 (новое) или 0x63 (старое). Узел выбирает значение на основе флага в опции DODAG Configuration, определённого в параграфе 4.1.3. Например, если сеть использует 0x23 (в опции DIO), при декомпрессии следует задавать 0x23. Сжатие заголовка IPv6-in-IPv6 описано в разделе 7 [RFC8138].

Использование единого кода при обработке заголовков IPv6-in-IPv6 может обеспечивать существенные преимущества.

В режиме Storing при переходе потока от RAL к RUL и от RUL к RUL применяется сжатие заголовков IPv6-in-IPv6 и RPI. В таких случаях должен применяться заголовок IPv6-in-IPv6, который следует сжимать в соответствии с разделом 7 [RFC8138]. На рисунке 2 показан пример для режима Storing, где пакет принимается из Internet, затем корневой узел инкапсулирует пакет для передачи в RPI. В этом примере для листа неизвестно о поддержке RFC 8138 и пакет инкапсулируется для маршрутизатора 6LR, который является родителем и последним интервалом пересылки.

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

Рисунок 2. Опция RPI, вставленная корнем в режиме Storing.


На рисунке 2 инкапсуляция IPv6-in-IPv6 выполняется корнем, поэтому он не включён в IP-in-IP 6LoRH. Получателем является родительский 6LR адресата во внутреннем пакете, поэтому его нельзя исключить. Он указывается отдельной записью в заголовке Source Route 6LoRH (SRH-6LoRH) как первый 6LoRH. Запись одна, поэтому SRH-6LoRH Size имеет значение 0. В этом примере Type = 1, поэтому адрес 6LR сжимается до двух байтов, а общий размер SRH-6LoRH составляет 4 байта. Далее следует заголовок RPI-6LoRH, затем IP-in-IP 6LoRH. При удалении IP-in-IP 6LoRH удаляются также все предшествующие ему заголовки маршрутизатора Может удаляться и Paging Dispatch [RFC8025], если предыдущая страница не была заменена страницей, отличной от 0 или 1, поскольку LOWPAN_IPHC кодируется одинаково на принятой по умолчанию странице 0 и Page 1. Результирующим пакетом для адресата является внутренний пакет, сжатый в соответствии с [RFC6282].

5. Эталонная топология

             +------------+
             |  INTERNET  ----------+
             +------------+         |
                                  A |
                              +-------+
                              |6LBR   |
                  +-----------|(root) |-------+
                  |           +-------+       |
                  |                           |
                  | B                         |C
              +---|---+                   +---|---+
              |  6LR  |                   |  6LR  |
    +---------|       |--+             +---       ---+
    |         +-------+  |             |  +-------+  |
    |                    |             |             |
    | D                  |  E          |             |
  +-|-----+          +---|---+         |             |
  |  6LR  |          |  6LR  |         |             |
  |       |    +------       |         |             |
  +---|---+    |     +---|---+         |             |
      |        |         |             |             |
      |        |         +--+          |             |
      |        |            |        I |          J  |
   F  |        | G          | H        |             |
+-----+-+    +-|-----+  +---|--+   +---|---+     +---|---+
|  RAL  |    | RUL   |  | RAL  |   |  RAL  |     | RUL   |
|  6LN  |    |  6LN  |  | 6LN  |   |  6LN  |     |  6LN  |
+-------+    +-------+  +------+   +-------+     +-------+

Рисунок 3. Эталонная топология RPL.


В общем случае сеть RPL включает 6LBR, магистральные маршрутизаторы (Backbone Router или 6BBR), 6LR, а также 6LN в качестве листьев, логически организованных в граф DODAG.

На рисунке 3 показана эталонная топология RPL, используемая в этом документе. Для узлов применяются символьные метки, которые позволяют в дальнейшем ссылаться на них. 6LR представляет полный маршрутизатор, 6LN – понимающий RPL маршрутизатор или хост (лист). Для упрощения предполагается, что 6LBR имеет прямой доступ в Internet и служит корнем DODAG, поэтому 6BBR на рисунке не показаны. Листья 6LN, помеченные как RAL (F, H, I), являются узлами RPL без дочерних хостов. Листья, помеченные как RUL (G и J), являются устройствами, не поддерживающими RPL, но использующими анонсы RA (Router Advertisement), запросы дубликатов адресов 6LoWPAN (Duplicate Address Request), подтверждения дубликатов (Duplicate Address Confirmation или DAR/DAC) и обнаружение соседей 6LoWPAN лишь для участия в работе сети [RFC8505]. 6LBR (A) на рисунке является корнем Global DODAG.

6. Варианты применения

Далее анализируются комбинации RFC 6553, RFC 6554 и инкапсуляции IPv6-in-IPv6 для репрезентативных потоков трафика. Варианты включают потоки:

  • между понимающими RPL узлами и корнем (6LBR);

  • между понимающими RPL узлами и Internet;

  • между узлами RUL внутри LLN (см. например, 7.1.4. Пример потока от RUL к корню);

  • внутри LLN когда адрес конечного получателя находится вне LLN (см. например, 7.2.3. Поток от RUL в Internet).

Рассматриваемые варианты приведены ниже.

Взаимодействие между листом и корнем:

RAL -> root

root -> RAL

RUL -> root

root -> RUL

Взаимодействие между листом и Internet:

RAL -> Internet

Internet -> RAL

RUL -> Internet

Internet -> RUL

Взаимодействие между листьями:

RAL -> RAL

RAL -> RUL

RUL -> RAL

RUL -> RUL

Этот документ следует правилу, в соответствии с которым заголовок не может быть удалён или вставлен «на лету» внутри маршрутизируемого пакета IPv6. Это фундаментальное правило архитектуры IPv6 задано в [RFC8200].

Поскольку значение Rank в артефактах RPI меняется при каждой пересылке, оно обычно достигает 0 по прибытии в корень DODAG. При передаче пакетов в Internet корень DODAG должен обнулять это поле, поэтому в Internet значение SenderRank недоступно.

Несмотря на возможность сохранения артефактов RPI, промежуточный маршрутизатор, которому нужно добавлять заголовок расширения (например, RH3 или RPL Option), должен все равно инкапсулировать пакет в (дополнительный) внешний заголовок IP. Следствием этого является то, что промежуточный маршрутизатор может удалить RH3 или RPL Option лишь при его размещении в инкапсулирующем заголовке IPv6, который адресован данному промежуточному маршрутизатору. Для выполнения этого нужно удалить весь заголовок инкапсуляции (может быть добавлена замена).

RPL Option и RH3 могут быть изменены маршрутизаторами на пути пакетов очень специфическими способами без добавления и удаления заголовков инкапсуляции. Оба заголовка разработаны с учётом такого изменения и помечены как изменяемые, но восстанавливаемые. Поэтому IPsec AH (Authentication Header) можно применять к этим заголовкам, но это не будет защищать от изменения.

Опция RPI должна присутствовать в каждом отдельном пакете данных RPL. До выхода [RFC8138] существовал значительный интерес к заданию исключений из этого правила, и удаления RPI для потоков Downward в режиме Non-Storing. Это исключение охватывало очень небольшое число случаев и вызвало существенные проблемы взаимодействия, добавив интереса к коду и тестам. Возможность сжать RPI до 3 байтов или меньше в значительной мере устранила потребность в исключении опции. В последующих параграфах рассматриваются примеры, подобранные на основе указанных ниже требований IPv6 и RPL.

Опция RPI должна быть в каждом пакете, проходящем через LLN.

  • Приведённое выше требование заставляет инкапсулировать все пакеты, приходящие из Internet.

  • Заголовок нельзя вставить или удалить «на лету» для маршрутизируемого пакета IPv6.

  • Заголовки расширения может добавлять и удалять лишь отправитель или получатель.

  • Заголовки RPI и RH3 маршрутизаторы на пути пакета могут изменять без необходимости добавления и удаления инкапсулирующего заголовка.

  • RH3 или RPL Option может удаляться промежуточным маршрутизатором лишь из инкапсулирующего заголовка IPv6, адресованного этому маршрутизатору.

  • Режим Non-Storing в нисходящем направлении требует для RH3 инкапсуляции корнем.

Варианты применения определены на основе приведённых ниже допущений для случая использования в LLN неотбрасываемого типа RPI Option Type (0x23).

  • Каждый узел IPv6 (включая маршрутизаторы Internet) следует [RFC8200], что позволяет безопасно вставлять RPI Option Type 0x23 .

  • Все маршрутизаторы 6LR соответствуют [RFC8200].

  • RPI игнорируются получателями IPv6 (RUL dst).

  • В некоторых случаях предполагается, что RAL поддерживает инкапсуляцию IP-in-IP.

  • Поддержка узлами RUL инкапсуляции IP-in-IP не предполагается.

  • Для исходящего из RUL трафика при добавлении неанализируемого RPI узлу 6LR, служащему граничным маршрутизатором RPL, следует переписывать RPI, указывая выбранный экземпляр и задавая флаги.

  • Описания RAL применяются к RAN в целом.

  • Неограниченное использование RPL выходит за рамки этого документа.

  • Сжатие основано на [RFC8138].

  • Метки потока [RFC6437] не требуются в RPL.

7. Режим Storing

В режиме Storing (SM) с полным учётом состояния отправитель может определить, находится ли адресат в LLN, сравнивая адрес получателя с опцией PIO в сообщении DIO. В таблице 4 показаны заголовки, требуемые в разных случаях и указано, требуется ли добавлять заголовок IPv6-in-IPv6 и кому он должен быть адресован:

  1. конечный получатель (целевой узел RAL (tgt));

  2. «корень»;

  3. родитель 6LR для RUL.

Для случаев, где заголовок IPv6-in-IPv6 не требуется, указано «Нет», а для адресата – «-» (неприменимо). Во всех случаях требуется опция RPI, поскольку она показывает несогласованность маршрутной топологии (петли). В общем случае заголовок RH3 не требуется, поскольку он не применяется в режиме Storing, однако при передаче от корня к RUL в режиме SM, где RH3 может использоваться, этот заголовок указывает RUL (таблица 8).

Лист может быть маршрутизатором 6LR или хостом и оба обозначаются как 6LN. Корень указывает 6LBR (рисунок 3).

Таблица 4. Инкапсуляция IPv6-in-IPv6 в режиме Storing.

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

Направление

IPv6-in-IPv6

Адресат IPv6-in-IPv6

Leaf – Root

RAL -> корень

Нет

–

корень -> RAL

Нет

–

корень -> RUL

Требуется

6LR

RUL -> корень

Требуется

корень

Leaf – Internet

RAL -> Internet

Требуется

корень

Internet -> RAL

Требуется

RAL (tgt)

RUL -> Internet

Требуется

корень

Internet -> RUL

Требуется

6LR

Leaf – Leaf

RAL -> RAL

Нет

–

RAL -> RUL

Нет (вверх)

–

Требуется (вниз)

6LR

RUL -> RAL

Требуется (вверх)

корень

Требуется (вниз)

RAL

RUL -> RUL

Требуется (вверх)

корень

Требуется (вниз)

6LR

7.1. Взаимодействие между листом и корнем

В этом параграфе рассматриваются потоки в режиме Storing (SM):

RAL -> корень

корень -> RAL

RUL -> корень

корень -> RUL

7.1.1. Пример потока от RAL к корню

В режиме Storing опция RPI [RFC6553] применяется для передачи RPLInstanceID и Rank. Поток имеет вид RAL (6LN) -> 6LR_i -> корень (6LBR), например, Узел F (6LN) -> Узел D (6LR_i) -> Узел B (6LR_i) -> Узел A (корень 6LBR).

RAL (узел F) вставляет RPI и передаёт пакет 6LR (узел D), который уменьшает Rank в RPI и передаёт пакет вверх. При поступлении пакета в 6LBR (узел A) опция RPI восстанавливается и пакет обрабатывается. Заголовок IPv6-in-IPv6 не требуется. 6LBR может удалить RPI, поскольку пакет адресован ему. Для использования этого варианта узел RAL должен знать, что он взаимодействует 6LBR. RAL может знать адрес 6LBR поскольку ему известен корень из DODAGID в сообщениях DIO. В таблице 5 показаны заголовки, которые требуется использовать.

Таблица 5. Использование заголовков при передаче от RAL к корню в режиме SM.

Заголовок

RAL src

6LR_i

6LBR dst

Добавленные заголовки

RPI

–

–

Изменённые заголовки

–

RPI

–

Удалённые заголовки

–

–

RPI

Неизменные заголовки

–

–

–

7.1.2. Пример потока от корня к RAL

В этом случае поток имеет вид: корень (6LBR) -> 6LR_i -> RAL (6LN), например, Узел A (корень, 6LBR) -> Узел B (6LR_i) -> Узел D (6LR_i) -> Узел F (6LN). Маршрутизатор 6LBR вставляет RPI и передаёт пакет вниз. 6LR увеличивает Rank в RPI (проверяется RPLInstanceID для выбора таблицы пересылки). Пакет обрабатывается в RAL и RPI удаляется. Заголовок IPv6-in-IPv6 не требуется. В таблице 6 показаны заголовки, которые требуется использовать.

Таблица 6. Использование заголовков при передаче от корня к RAL в режиме SM.

Заголовок

6LBR src

6LR_i

RAL dst

Добавленные заголовки

RPI

–

–

Изменённые заголовки

–

RPI

–

Удалённые заголовки

–

–

RPI

Неизменные заголовки

–

–

–

7.1.3. Пример потока от корня к RUL

Поток имеет вид: корень (6LBR) -> 6LR_i -> RUL (получатель IPv6), например, Узел A (6LBR) -> Узел B (6LR_i) -> Узел E (6LR_n) -> Узел G (RUL). 6LR_i (узел B) представляет промежуточные маршрутизаторы от источника (6LBR) к получателю (RUL), а 1 <= i <= n, где n – число маршрутизаторов (6LR), через которые пакет проходит от 6LBR (узел A) к RUL (узел G). 6LBR инкапсулирует пакет в заголовок IPv6-in-IPv6 и помещает в начало (prepend) RPI. Заголовок IPv6-in-IPv6 содержит адрес родителя 6LR для RUL (6LR_n). Родитель 6LR узла RUL удаляет заголовок и передаёт пакет RUL. В таблице 7 показаны заголовки, которые требуется использовать.

Таблица 7. Использование заголовков при передаче от корня к RUL в режиме SM.

Заголовок

6LBR src

6LR_i

6LR_n

RUL dst

Добавленные заголовки

IP6-IP612 (RPI)

–

–

–

Изменённые заголовки

–

RPI

–

–

Удалённые заголовки

–

–

IP6-IP6 (RPI)

–

Неизменные заголовки

–

IP6-IP6

–

–

Инкапсуляции IP-in-IP при взаимодействии корня с RUL можно избежать. В режиме SM её можно заменить заголовком RH3, указывающим RUL и в этом случае пакет направляется маршрутизатору 6LR как в обычной операции SM, затем 6LR пересылает его RUL на основе заголовка RH3, а RUL игнорирует потреблённые RH3 и RPI как в режиме Non-Storing. В таблице 8 показаны заголовки, которые требуется использовать.

Таблица 8. Использование заголовков при передаче от корня к RUL в режиме SM без инкапсуляции.

Заголовок

6LBR src

6LR_i i=(1,..,n-1)

6LR_n

RUL dst

Добавленные заголовки

RPI, RH3

–

–

–

Изменённые заголовки

–

RPI

RPI, RH3 (потребляется)

–

Удалённые заголовки

–

–

–

–

Неизменные заголовки

–

RH3

–

RPI, RH3 (оба игнорируются)

7.1.4. Пример потока от RUL к корню

Поток имеет вид RUL (узел IPv6 src) -> 6LR_1 -> 6LR_i -> корень (6LBR). Например, Узел G (RUL) -> Узел E (6LR_1) -> Узел B (6LR_i) -> Узел A (корень, 6LBR). 6LR_i представляет промежуточные маршрутизаторы на пути от источника (RUL) к адресату (6LBR), а 1 <= i <= n, где n – число маршрутизаторов (6LR) через которые пакет проходит от RUL к 6LBR.

Когда пакет приходит от RUL (узел G) в 6LR_1 (узел E), маршрутизатор 6LR_1 инкапсулирует его в заголовок IPv6-in-IPv6 с RPI, адресованный корню (узел A). Корень удаляет заголовок и обрабатывает пакет. В таблице 9 показаны заголовки, которые нужны в случае, когда заголовок IPv6-in-IPv6 адресован корню (узел A).

Таблица 9. Использование заголовков при передаче от RUL к корню в режиме SM.

Заголовок

RUL src

6LR_1

6LR_i

6LBR dst

Добавленные заголовки

–

IP6-IP6 (RPI)

–

–

Изменённые заголовки

–

–

RPI

–

Удалённые заголовки

–

–

–

IP6-IP6 (RPI)

Неизменные заголовки

–

–

IP6-IP6

–

7.2. Взаимодействие между листом и Internet

В этом параграфе описано взаимодействие в режиме Storing (SM) для случаев:

RAL -> Internet

Internet -> RAL

RUL -> Internet

Internet -> RUL

7.2.1. Поток от RAL в Internet

В этом случае поток имеет вид RAL (6LN) -> 6LR_i -> корень (6LBR) -> Internet, например, Узел F (RAL) -> Узел D (6LR_i) -> Узел B (6LR_i) -> Узел A (корень, 6LBR) -> Internet. 6LR_i представляет промежуточные маршрутизаторы на пути от источника (RAL) к корню (6LBR), , а 1 <= i <= n, где n – число маршрутизаторов (6LR) через которые пакет проходит от RAL к 6LBR.

Информация RPL из RFC 6553 может уходить в Internet, поскольку узлы, не настроенные на поддержку RPL, будут игнорировать её. Заголовок IPv6-in-IPv6 не требуется. С другой стороны, RAL может вставлять RPI с инкапсуляцией в заголовок IPv6-in-IPv6 для корня, который будет удалять RPI и передавать пакет в Internet. В этом случае используется узел-лист, но этот вариант применим также к любому типу узлов, понимающих RPL (например, 6LR).

В таблице 10 показаны заголовки, которые нужно использовать при отсутствии инкапсуляции. Отметим, что 6LBR изменяет RPI, устанавливая SenderRank = 0, если поле имеет иное значение. В таблице 11 показаны заголовки, которые требуется использовать при наличии инкапсуляции.

Таблица 10. Использование заголовков при передаче от RAL в Internet в режиме SM без инкапсуляции.

Заголовок

RAL src

6LR_i

6LBR

Internet dst

Добавленные заголовки

RPI

–

–

–

Изменённые заголовки

–

RPI

RPI

–

Удалённые заголовки

–

–

–

–

Неизменные заголовки

–

–

–

RPI (игнорируется)

Таблица 11. Использование заголовков при передаче от RAL в Internet в режиме SM с инкапсуляцией в корень (6LBR).

Заголовок

RAL src

6LR_i

6LBR

Internet dst

Добавленные заголовки

IP6-IP6 (RPI)

–

–

–

Изменённые заголовки

–

RPI

–

–

Удалённые заголовки

–

–

IP6-IP6 (RPI)

–

Неизменные заголовки

–

IP6-IP6

–

–

7.2.2. Поток из Internet к RAL

Поток имеет вид Internet -> корень (6LBR) -> 6LR_i -> RAL (6LN), например, Internet -> Узел A (корень, 6LBR) -> Узел B (6LR_1) -> Узел D (6LR_n) -> Узел F (RAL). При поступлении пакета из Internet в 6LBR опция RPI добавляется во внешний заголовок IPv6-in-IPv6 (с адресом получателя RAL) и пакет передаётся 6LR, где меняется Rank в RPI. При поступлении пакета в RAL он декапсулируется и RPI удаляется до обработки пакета. В таблице 12 показаны заголовки, которые требуется использовать.

Таблица 12. Использование заголовков при передаче из Internet в RAL в режиме SM.

Заголовок

Internet src

6LBR

6LR_i

RAL dst

Добавленные заголовки

–

IP6-IP6 (RPI)

–

–

Изменённые заголовки

–

–

RPI

–

Удалённые заголовки

–

–

–

IP6-IP6 (RPI)

Неизменные заголовки

–

–

–

–

7.2.3. Поток от RUL в Internet

Поток имеет вид RUL (узел IPv6 src) -> 6LR_1 -> 6LR_i -> корень (6LBR) -> Internet, например, Узел G (RUL) -> Узел E (6LR_1) -> Узел B (6lR_i) -> Узел A (корень, 6LBR) -> Internet. Узел 6LR_1 (i=1) добавляет заголовок IPv6-in-IPv6 (RPI), адресованный корню, который может удалить RPI до передачи наверх. На промежуточных 6LR изменяется значение Rank в RPI.

В идеале исходный узел оставит нулевую метку потока IPv6 для лучшего сжатия пакета в LLN. 6LBR установит ненулевую метку потока при отправке пакета в Internet (см. [RFC6437]). В таблице 13 показаны заголовки, которые требуется использовать.

Таблица 13. Использование заголовков при передаче от RUL в Internet в режиме SM.

Заголовок

IPv6 src (RUL)

6LR_1

6LR_i i=(2,..,n)

6LBR

Internet dst

Добавленные заголовки

–

IP6-IP6 (RPI)

–

–

–

Изменённые заголовки

–

–

RPI

–

–

Удалённые заголовки

–

–

–

IP6-IP6 (RPI)

–

Неизменные заголовки

–

–

–

–

–

7.2.4. Поток из Internet к RUL

Поток имеет вид Internet -> корень (6LBR) -> 6LR_i -> RUL (узел IPv6 dst), например, Internet -> Узел A (корень, 6LBR) -> Узел B (6LR_i) -> Узел E (6LR_n) -> Узел G (RUL). 6LBR добавляет RPI в заголовок IPv6-in-IPv6. Заголовок инкапсуляции IPv6-in-IPv6 адресован родителю 6LR узла RUL. Подробности этого варианта рассмотрены в [RFC9010], где описана маршрутизация RPL на 6LN, выступающем в качестве хоста и не понимающем RPL. 6LBR может устанавливать нулевую метку потока во внутреннем заголовке IPv6-in-IPv6 в целях сжатия [RFC8138] [RFC6437]. В таблице 14 показаны заголовки, которые требуется использовать.

Таблица 14. Использование заголовков при передаче из Internet в RUL в режиме SM.

Заголовок

Internet src

6LBR

6LR_i i=(1,..,n-1)

6LR_n

RUL dst

Добавленные заголовки

–

IP6-IP6 (RPI)

–

–

–

Изменённые заголовки

–

–

RPI

–

–

Удалённые заголовки

–

–

–

IP6-IP6 (RPI)

–

Неизменные заголовки

–

–

–

–

–

7.3. Взаимодействие между листьями

В этом параграфе рассматривается режим Storing (SM) для потоков:

RAL -> RAL

RAL -> RUL

RUL -> RAL

RUL -> RUL

7.3.1. Поток от RAL к RAL

Протокол RPL [RFC6550] разрешает простую оптимизацию одной пересылки (one-hop) для сетей Storing и Non-Storing. Узел может передать пакет соседу one-hop напрямую (см. раздел 9 в [RFC6550]).

Когда узлы не соединены непосредственно, поток в режиме Storing имеет вид RAL src (6LN) -> 6LR_ia -> общий родитель (6LR_x) -> 6LR_id -> RAL dst (6LN), например, Узел F (RAL src) -> Узел D (6LR_ia) -> Узел B (6LR_x) -> Узел E (6LR_id) -> Узел H (RAL dst). 6LR_ia (узел D) представляет промежуточные маршрутизаторы на пути от источника к общему родителю 6LR_x (узел B), 1 <= ia <= n, где n – число маршрутизаторов (6LR) на пути от RAL (узел F) к общему родителю 6LR_x (узел B). 6LR_id (узел E) представляет промежуточные маршрутизаторы на пути от общего родителя 6LR_x (узел B) к адресату RAL (узел H), 1 <= id <= m, где m – число маршрутизаторов (6LR) между общим родителем (6LR_x) и адресатом RAL (узел H).

Предполагается, что два узла расположены в одном домене RPL (общий корень DODAG). На узле общего корня (узел B) флаг направление (O) в RPI меняется (снижение ранга заменяется его ростом). Хотя узлы 6LR обновляют RPI, им не требуется добавлять или удалять RPI, поэтому заголовки IPv6-in-IPv6 не нужны. В таблице 15 показаны заголовки, которые требуется использовать.

Таблица 15. Использование заголовков при передаче между RAL в режиме SM.

Заголовок

RAL src

6LR_ia

6LR_x (общий родитель)

6LR_id

RAL dst

Добавленные заголовки

RPI

–

–

–

–

Изменённые заголовки

–

RPI

RPI

RPI

–

Удалённые заголовки

–

–

–

–

RPI

Неизменные заголовки

–

–

–

–

–

7.3.2. Поток от RAL к RUL

В этом случае поток имеет вид RAL src (6LN) -> 6LR_ia -> общий предок (6LBR, корень) -> 6LR_id -> RUL (узел IPv6 dst), например, Узел F (RAL) -> Узел D -> Узел B -> Узел A -> Узел B -> Узел E -> Узел G (RUL). 6LR_ia представляет промежуточные маршрутизаторы на пути от источника (RAL) к общему родителю (корень), 1 <= ia <= n, где n – число маршрутизаторов (6LR) на пути от RAL к корню. 6LR_id (узел E) представляет промежуточные маршрутизаторы на пути от корня (узел B) к адресату RUL (узел G). Здесь 1 <= id <= m и m задаёт число маршрутизаторов (6LR) на пути от корня к адресату RUL.

Пакет от RAL приходит в 6LBR, поскольку маршрут к RUL не вводится в RPL SM и RAL вставляет опцию RPI (RPI1), адресованную корню (6LBR). Корень не удаляет RPI1 (это невозможно при отсутствии инкапсуляции) и инкапсулирует пакет в IPv6-in-IPv6 с RPI2, а затем передаёт его родителю 6LR для RUL, который удаляет инкапсуляцию и RPI2 до передачи пакета RUL. В таблице 16 показаны заголовки, которые требуется использовать.

Таблица 16. Использование заголовков при передаче от RAL к RUL в режиме SM.

Заголовок

RAL src

6LR_ia

6LBR

6LR_id

6LR_m

RUL dst

Добавленные заголовки

RPI1

–

IP6-IP6 (RPI2)

–

–

–

Изменённые заголовки

–

RPI1

–

RPI2

–

–

Удалённые заголовки

–

–

–

–

IP6-IP6 (RPI2)

–

Неизменные заголовки

–

–

RPI1

RPI1

RPI1

RPI1 (игнорируется)

7.3.3. Поток от RUL к RAL

Поток имеет вид RUL (узел IPv6 src) -> 6LR_ia -> 6LBR -> 6LR_id -> RAL dst (6LN), например, Узел G (RUL) -> Узел E -> Узел B -> Узел A -> Узел B -> Узел D -> Node F (RAL). 6LR_ia (узел E) представляет промежуточные маршрутизаторы на пути от источника RUL (узел G) к корню(узел A). 1 <= ia <= n, где n – число маршрутизаторов (6LR) на пути от источника к корню. 6LR_id представляет промежуточные маршрутизаторы на пути от корня (узел A) к адресату RAL (узел F). Здесь 1 <= id <= m, а m – число маршрутизаторов (6LR) на пути от корня к получателю RAL.

6LR_1 (узел E) получает пакет от RUL (узел G) и вставляет в него RPI (RPI1) с инкапсуляцией в заголовок IPv6-in-IPv6 для корня. Корень удаляет внешний заголовок с RPI (RPI1) и вставляет RPI (RPI2) для адресата RAL (узел F). В таблице 17 показаны заголовки, которые требуется использовать.

Таблица 17. Использование заголовков при передаче от RUL к RAL в режиме SM.

Заголовок

RUL src

6LR_1

6LR_ia

6LBR

6LR_id

RAL dst

Добавленные заголовки

–

IP6-IP6 (RPI1)

–

IP6-IP6 (RPI2)

–

–

Изменённые заголовки

–

–

RPI1

–

RPI2

–

Удалённые заголовки

–

–

–

IP6-IP6 (RPI1)

–

IP6-IP6 (RPI2)

Неизменные заголовки

–

–

–

–

–

–

7.3.4. Поток от RUL к RUL

Поток имеет вид RUL (узел IPv6 src) -> 6LR_1 -> 6LR_ia -> 6LBR -> 6LR_id -> RUL (узел IPv6 dst), например, Узел G (RUL src) -> Узел E -> Узел B -> Узел A (корень) -> Узел C -> Узел J (RUL dst). Внутренний узел 6LR_ia (например, E или B) – это промежуточный маршрутизатор на пути от источника RUL (узел G) к корню (6LBR) (узел A), 1 <= ia <= n, где n – число маршрутизаторов (6LR) между RUL и корнем. 6LR_1 соответствует ia=1. 6LR_id (узел C) представляет промежуточные маршрутизаторы от корня (узел A) до получателя RUL (узел J), 1 <= id <= m, где m – число маршрутизаторов (6LR) на пути от корня до адресата RUL.

6LR_1 (узел E) получает пакет от RUL (узел G) и добавляет RPI (RPI1) в инкапсуляцию IPv6-in-IPv6 для корня, который удаляет внешний заголовок с RPI (RPI1) и помещает RPI (RPI2) в новый заголовок, адресованный родителю 6LR получателя RUL. В таблице 18 показаны заголовки, которые требуется использовать.

Таблица 18. Использование заголовков при передаче между RUL в режиме SM.

Заголовок

RUL src

6LR_1

6LR_ia

6LBR

6LR_id

6LR_n

RUL dst

Добавленные заголовки

–

IP6-IP6 (RPI1)

–

IP6-IP6 (RPI1)

–

–

–

Изменённые заголовки

–

–

RPI1

–

RPI2

–

–

Удалённые заголовки

–

–

–

IP6-IP6 (RPI1)

–

IP6-IP6 (RPI2)

–

Неизменные заголовки

–

–

–

–

–

–

–

8. Режим Non-Storing

В режиме Non-Storing (Non-SM) с полным заданием маршрута источником маршрутизатор 6LBR (корень DODAG) имеет полные сведения о связности всех узлов DODAG и всех потоках трафика через корневой узел. Поэтому остальным узлам не нужно знать о наличии узлов, не понимающих RPL, поскольку соответствующие действия выполняет 6LBR.

В таблице 19 указаны заголовки, требуемые в разных вариантах применения, и показано, когда вставляются заголовки RPI, RH3, IPv6-in-IPv6. В последнем столбце указан целевой адресат в заголовка IPv6-in-IPv6: 6LN (RAL), 6LR (родитель RUL) или корень. Если заголовок IPv6-in-IPv6 не нужен, в соответствующей ячейке указано «Нет». В RPL не предполагается возможность пропуска RPI, поскольку эти данные нужны для маршрутизации, качества обслуживания и сжатия. Эта спецификация предполагает, что RPI присутствует всегда. Термин «возможно(вверх)» указывает, что заголовок IPv6-in-IPv6 может потребоваться для направления Upward, «требуется(вверх)» говорит, что заголовок IPv6-in-IPv6 требуется для направления Upward, а «требуется(вниз)» – для Downward.

Лист может быть маршрутизатором 6LR или хостом и указан как 6LN (рисунок 3). В таблице 19 (1) указывает случай 6TiSCH [RFC8180], где RPI все ещё может требоваться для того, чтобы идентификатор RPLInstanceID был доступен при выборе канала или приоритета на каждом узле пересылки.

Таблица 19. Заголовки, требуемые в режиме Non-Storing: RPI, RH3, инкапсуляция IPv6-in-IPv6.

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

Направление

RPI

RH3

IPv6-in-IPv6

IPv6-in-IPv6 dst

Leaf – Root

RAL -> корень

Да

Нет

Нет

Нет

корень -> RAL

Да

Да

Нет

Нет

корень -> RUL

Да (1)

Да

Нет

6LR

RUL -> корень

Да

Нет

Требуется

корень

Leaf – Internet

RAL -> Internet

Да

Да

Возможно (вверх)

корень

Internet -> RAL

Да

Да

Требуется

RAL

RUL -> Internet

Да

Нет

Требуется

корень

Internet -> RUL

Да

Да

Требуется

6LR

Leaf – Leaf

RAL -> RAL

Да

Да

Возможно (вверх)

корень

Требуется (вниз)

RAL

RAL -> RUL

Да

Да

Возможно (вверх)

корень

Требуется (вниз)

6LR

RUL -> RAL

Да

Да

Требуется (вверх)

корень

Требуется (вниз)

RAL

RUL -> RUL

Да

Да

Требуется (вверх)

корень

Требуется (вниз)

6LR

8.1. Взаимодействие между листом и корнем

В этом параграфе описан режим Non-Storing (Non-SM) для потоков:

RAL -> root

root -> RAL

RUL -> root

root -> RUL

8.1.1. Пример потока от RAL в корень

В режиме Non-Storing узел-лист использует принятую по умолчанию маршрутизацию для передачи трафика в корень. Опция RPI должна включаться, поскольку она содержит значение Rank, используемое для обнаружения и предотвращения петель. Поток имеет вид RAL (6LN) -> 6LR_i -> корень (6LBR), например, Узел F -> Узел D -> Узел B -> Узел A (корень). 6LR_i представляет промежуточные маршрутизаторы между отправителем и получателем, 1 <= i <= n, где n – число маршрутизаторов (6LR) на пути от источника (RAL) к получателю (6LBR). Ситуация не отличается от режима Storing. В таблице 20 показаны заголовки, которые требуется использовать.

Таблица 20. Использование заголовков при передаче от RAL к корню в режиме Non-SM.

Заголовок

RAL src

6LR_i

6LBR dst

Добавленные заголовки

RPI

–

–

Изменённые заголовки

–

RPI

–

Удалённые заголовки

–

–

RPI

Неизменные заголовки

–

–

–

8.1.2. Пример потока от корня к RAL

Поток имеет вид: корень (6LBR) -> 6LR_i -> RAL (6LN), например, Узел A (корень) -> Узел B -> Узел D -> Узел F. 6LR_i представляет промежуточные маршрутизаторы между отправителем и получателем, 1 <= i <= n, где n – число маршрутизаторов (6LR) на пути от источника (6LBR) к адресату (RAL). 6LBR вставляет RH3 и RPI, инкапсуляция IPv6-in-IPv6 не нужна, поскольку трафик исходит от понимающего RPL узла 6LBR. Получатель заведомо понимает RPL, поскольку корень знает всю топологию в режиме Non-Storing. В таблице 21 показаны заголовки, которые требуется использовать.

Таблица 21. Использование заголовков при передаче от корня к RAL в режиме Non-SM.

Заголовок

6LBR src

6LR_i

RAL dst

Добавленные заголовки

RPI, RH3

–

–

Изменённые заголовки

–

RPI, RH3

–

Удалённые заголовки

–

–

RPI, RH3

Неизменные заголовки

–

–

–

8.1.3. Пример потока от корня к RUL

Поток имеет вид: корень (6LBR) -> 6LR_i -> RUL (узел IPv6 dst), например, Узел A (корень) -> Узел B -> Узел E -> Узел G (RUL). 6LR_i представляет промежуточные маршрутизаторы между отправителем и получателем, 1 <= i <= n, где n – число маршрутизаторов (6LR) на пути от источника (6LBR) к адресату (RUL).

6LBR добавляет заголовок RH3, который меняется на каждом промежуточном 6LR (6LR_1 и т. д.) и полностью воспринимается последним 6LR (6LR_n), но остаётся на месте. При добавлении RPI узел RUL, не понимающий RPI, будет игнорировать его (в соответствии с [RFC8200]), поэтому инкапсуляция не нужна. В таблице 22 показаны заголовки, которые требуется использовать.

Таблица 22. Использование заголовков при передаче от корня к RUL в режиме Non-SM.

Заголовок

6LBR src

6LR_i i=(1,..,n-1)

6LR_n

RUL dst

Добавленные заголовки

RPI, RH3

–

–

–

Изменённые заголовки

–

RPI, RH3

RPI, RH3 (потребляется)

–

Удалённые заголовки

–

–

–

–

Неизменные заголовки

–

–

RPI, RH3 (оба игнорируются)

8.1.4. Пример потока от RUL к корню

Поток имеет вид RUL (узел IPv6 src) -> 6LR_1 -> 6LR_i -> корень (6LBR), например, Узел G -> Узел E -> Узел B -> Узел A (корень). 6LR_i представляет промежуточные маршрутизаторы между источником и получателем, 1 <= i <= n, где n – число маршрутизаторов (6LR) на пути пакета от источника (RUL) к адресату. Например, 6LR_1 (i=1) – маршрутизатор, получающий пакеты от RUL. В этом случае RPI добавляет первый маршрутизатор 6LR (6LR_1, узел E), инкапсулируя в заголовок IPv6-in-IPv6, а следующие 6LR на пути меняют RPI. Корень воспринимает RPI и пакет в целом. В таблице 23 показаны заголовки, которые требуется использовать.

Таблица 23. Использование заголовков при передаче от RUL в корень в режиме Non-SM.

Заголовок

RUL src

6LR_1

6LR_i

6LBR dst

Добавленные заголовки

–

IPv6-in-IPv6 (RPI)

–

–

Изменённые заголовки

–

–

RPI

–

Удалённые заголовки

–

–

–

IPv6-in-IPv6 (RPI)

Неизменные заголовки

–

–

–

8.2. Режим Non-Storing – взаимодействие между листом и Internet

В этом параграфе рассматриваются потоки в режиме Non-Storing (Non-SM) для случаев:

RAL -> Internet

Internet -> RAL

RUL -> Internet

Internet -> RUL

8.2.1. Пример потока от RAL в Internet

Поток имеет вид RAL (6LN) src -> 6LR_i -> корень (6LBR) -> Internet dst, например, Узел F (RAL) -> Узел D -> Узел B -> Узел A -> Internet. Имея сведения RAL о домене RPL, пакет можно инкапсулировать в корень, если адресат находится вне домена RPL узла RAL.

6LR_i представляет промежуточные маршрутизаторы между отправителем и получателем. 1 <= i <= n, где n – число маршрутизаторов (6LR) между источником (RAL) и 6LBR. В этом случае инкапсуляция от RAL к корню не обязательна. Простейшим случаем является выход RPI в Internet (таблица 24), с учётом игнорирования в Internet этой информации. Для метки потока IPv6 следует установить 0 с целью более эффективного сжатия [RFC8138], а 6LBR будет устанавливать отличное от 0 значение при передаче в направлении Internet [RFC6437]. В таблице 24 показаны заголовки, которые требуется использовать без инкапсуляции, в таблице 25 – с инкапсуляцией для корневого узла.

Таблица 24. Использование заголовков при передаче от RAL в Internet без инкапсуляции в режиме Non-SM.

Заголовок

RAL src

6LR_i

6LBR

Internet dst

Добавленные заголовки

RPI

–

–

–

Изменённые заголовки

–

RPI

RPI

–

Удалённые заголовки

–

–

–

–

Неизменные заголовки

–

–

–

RPI (игнорируется)

Таблица 25. Использование заголовков при передаче от RAL в Internet с инкапсуляцией в корень в режиме Non-SM.

Заголовок

RAL src

6LR_i

6LBR

Internet dst

Добавленные заголовки

IP6v6-in-IPv6 (RPI)

–

–

–

Изменённые заголовки

–

RPI

–

–

Удалённые заголовки

–

–

IP6v6-in-IPv6 (RPI)

–

Неизменные заголовки

–

–

–

–

8.2.2. Пример потока из Internet к RAL

Поток имеет вид Internet -> корень (6LBR) -> 6LR_i -> RAL dst (6LN), например, Internet -> Узел A (корень) -> Узел B -> Узел D -> Узел F (RAL). 6LR_i представляет промежуточные маршрутизаторы между отправителем и получателем, 1 <= i <= n, где n и число маршрутизаторов (6LR) на пути от 6LBR к адресату (RAL). Маршрутизатор 6LBR должен добавлять заголовок RH3. Поскольку 6LBR знает путь к целевому узлу и его адрес, он может указать этот адрес в заголовке IPv6-in-IPv6. 6LBR будет указывать метку потока 0 для более эффективного сжатия [RFC8138]. В таблице 26 показаны заголовки, которые требуется использовать.

Таблица 26. Использование заголовков при передаче из Internet в RAL в режиме Non-SM.

Заголовок

Internet src

6LBR

6LR_i

RAL dst

Добавленные заголовки

–

IP6v6-in-IPv6 (RH3, RPI)

–

–

Изменённые заголовки

–

–

IP6v6-in-IPv6 (RH3, RPI)

–

Удалённые заголовки

–

–

–

IP6v6-in-IPv6 (RH3, RPI)

Неизменные заголовки

–

–

–

–

8.2.3. Пример потока от RUL в Internet

Поток имеет вид RUL (узел IPv6 src) -> 6LR_1 -> 6LR_i -> корень (6LBR) -> Internet dst, например, Узел G -> Узел E -> Узел B -> Узел A -> Internet. 6LR_i представляет промежуточные маршрутизаторы между отправителем и получателем, 1 <= i <= n, где n – число маршрутизаторов (6LR) на пути от источника (RUL) к 6LBR, например, 6LR_1 (i=1). Рекомендуется устанавливать в RUL метку потока 0. Поскольку родитель RUL добавляет заголовки RPL в пакет RUL, первый 6LR (6LR_1) будет добавлять RPI в новый заголовок IPv6-in-IPv6, адресуемый корню. Это идентично работе в режиме Storing (параграф 7.2.3). В таблице 27 показаны заголовки, которые требуется использовать.

Таблица 27. Использование заголовков при передаче от RUL в Internet в режиме Non-SM.

Заголовок

RUL src

6LR_i

6LR_i i=(2,..,n)

6LBR

Internet dst

Добавленные заголовки

–

IP6-IP6

–

–

–

Изменённые заголовки

–

–

RPI

–

–

Удалённые заголовки

–

–

–

IP6-IP6 (RPI)

–

Неизменные заголовки

–

–

–

–

–

8.2.4. Пример потока из Internet к RUL

Поток имеет вид Internet src -> корень (6LBR) -> 6LR_i -> RUL (узел IPv6 dst), например, Internet -> Узел A (корень) -> Узел B -> Узел E -> Узел G. 6LR_i представляет промежуточные маршрутизаторы между отправителем и получателем, 1 <= i <= n, где n – число маршрутизаторов (6LR) на пути пакета от 6LBR к RUL.

Маршрутизатор 6LBR должен добавлять заголовок RH3 в заголовок инкапсуляции IPv6-in-IPv6. 6LBR будет знать путь и понимать, что конечный узел не понимает RPL, поскольку он получит информацию DAO от ближайшего 6LR. Поэтому 6LBR может указать в заголовке IPv6-in-IPv6 получателем последний маршрутизатор 6LR. 6LBR будет помещать метку потока 0 для более эффективного сжатия [RFC8138]. В таблице 28 показаны заголовки, которые требуется использовать.

Таблица 28. Использование заголовков при передаче из Internet к RUL в режиме Non-SM.

Заголовок

Internet src

6LBR

6LR_i

6LR_n

RUL dst

Добавленные заголовки

–

IP6-IP6 (RH3, RPI)

–

–

–

Изменённые заголовки

–

–

IP6-IP6 (RH3, RPI)

–

–

Удалённые заголовки

–

–

–

IP6-IP6 (RH3, RPI)

–

Неизменные заголовки

–

–

–

–

–

8.3. Взаимодействие между листьями

В этом параграфе рассматриваются потоки в режиме Non-Storing (Non-SM) для случаев:

RAL -> RAL

RAL -> RUL

RUL -> RAL

RUL -> RUL

8.3.1. Пример потока от RAL к RAL

Поток имеет вид RAL src -> 6LR_ia -> корень (6LBR) -> 6LR_id -> RAL dst, например, Узел F (RAL src) -> Узел D -> Узел B -> Узел A (корень) -> Узел B -> Узел E -> Узел H (RAL dst). 6LR_ia представляет промежуточные маршрутизаторы между источником и корнем, 1 <= ia <= n, где n – число маршрутизаторов (6LR) на пути от RAL к корню. 6LR_id представляет маршрутизаторы между корнем и адресатом, 1 <= id <= m, где m – число промежуточных маршрутизаторов (6LR).

Здесь участвуют лишь узлы одного домена RPL. Узел-источник добавляет RPI в исходный пакет и передаёт пакет в восходящем направлении. Источник может поместить RPI (RPI1) в заголовок IPv6-in-IPv6, адресованный корню, чтобы 6LBR мог удалить этот заголовок. Если маршрутизатор этого не делает, RPI1 пересылается в нисходящем направлении во внутреннем заголовке (не имеет смысла). Маршрутизатор 6LBR должен вставить RH3 в заголовок инкапсуляции IPv6-in-IPv6. Он удаляет RPI (RPI1), поскольку опция содержится в полученном заголовке IPv6-in-IPv6. В иных случаях опция RPI может быть скрыта во внутреннем заголовке IP и её следует игнорировать. Корень вставляет RPI (RPI2) вместе с RH3.

Сети, использующие расширение RPL point-to-point [RFC6997], по сути являются Non-Storing DODAG и относятся к этому варианту или варианту параграфа 8.1.2 с узлом-источником, действующим как 6LBR.

В таблице 29 показаны заголовки, которые требуется использовать при инкапсуляции для корня, а в таблице 30 – для случая без инкапсуляции. Отметим, что в строке «Изменённые заголовки» по мере прохождения вверх каждый 6LR_ia меняет лишь RPI1. При движении вниз на каждом 6LR_id заголовок IPv6 меняется на RH3, поэтому изменяются оба вместе с RPI2.

Таблица 29. Использование заголовков при передаче между RAL с инкапсуляцией для корня в режиме Non-SM.

Заголовок

RAL src

6LR_ia

6LBR

6LR_id

RAL dst

Добавленные заголовки

IP6-IP6 (RPI1)

–

IP6-IP6 (RH3 -> RAL, RPI2)

–

–

Изменённые заголовки

–

RPI1

–

–

–

Удалённые заголовки

–

–

IP6-IP6 (RPI1)

–

IP6-IP6 (RH3, RPI2)

Неизменные заголовки

–

–

–

–

–

Таблица 30. Использование заголовков при передаче между RAL без инкапсуляции для корня в режиме Non-SM.

Заголовок

RAL src

6LR_ia

6LBR

6LR_id

RAL dst

Добавленные заголовки

RPI1

–

IP6-IP6 (RH3, RPI2)

–

–

Изменённые заголовки

–

RPI1

–

IP6-IP6 (RH3, RPI2)

–

Удалённые заголовки

–

–

–

–

IP6-IP6 (RH3, RPI2)

Неизменные заголовки

–

–

RPI1

RPI1

RPI1 (игнорируется)

8.3.2. Пример потока от RAL к RUL

Поток имеет вид RAL -> 6LR_ia -> корень (6LBR) -> 6LR_id -> RUL (узел IPv6 dst), например, Узел F (RAL) -> Узел D -> Узел B -> Узел A (root) -> Узел B -> Узел E -> Узел G (RUL). 6LR_ia представляет промежуточные маршрутизаторы между источником и корнем, 1 <= ia <= n, где n – число маршрутизаторов (6LR). 6LR_id представляет промежуточные маршрутизаторы между корнем и адресатом, 1 <= id <= m, где m – число маршрутизатором (6LR).

Как и в предыдущем случае, RAL (6LN) может вставлять RPI (RPI1) в заголовок IPv6-in-IPv6, адресованный корню, чтобы 6LBR мог удалить RPI. Затем 6LBR вставляет RH3 в новый заголовок IPv6-in-IPv6, адресованный последнему 6LR_id (6LR_id = m), вместе с RPI2.

Если узел-источник не помещает RPI (RPI1) в заголовок IPv6-in-IPv6 для корня, RPI1 пересылается вниз из корня во внутреннем заголовке (не имеет смысла).

В таблице 31 показаны заголовки, которые требуется использовать при инкапсуляции для корня, а в таблице 32 – для случая без инкапсуляции.

Таблица 31. Использование заголовков при передаче от RAL к RUL с инкапсуляцией для корня в режиме Non-SM.

Заголовок

RAL src

6LR_ia

6LBR

6LR_id

6LR_m

RUL dst

Добавленные заголовки

IP6-IP6 (RPI1)

–

IP6-IP6 (RH3, RPI2)

–

–

–

Изменённые заголовки

–

RPI1

–

IP6-IP6 (RH3, RPI2)

–

–

Удалённые заголовки

–

–

IP6-IP6 (RPI1)

–

IP6-IP6 (RH3, RPI2)

–

Неизменные заголовки

–

–

RPI1

RPI1

–

–

Таблица 32. Использование заголовков при передаче от RAL к RUL без инкапсуляции для корня в режиме Non-SM.









Заголовок




RAL src




6LR_ia




6LBR




6LR_id




6LR_m




RUL dst








Добавленные заголовки




RPI1




–




IP6-IP6 (RH3, RPI2)




–




–




–








Изменённые заголовки




–




RPI1




–




IP6-IP6 (RH3, RPI2)




–




–








Удалённые заголовки




–




–




–




–




IP6-IP6 (RH3, RPI2)




–








Неизменные заголовки




–




–




RPI1




RPI1




RPI1




RPI1 (игнорируется)








8.3.3. Пример потока от RUL к RAL


Поток имеет вид RUL (узел IPv6 src) -> 6LR_1 -> 6LR_ia -> корень (6LBR) -> 6LR_id -> RAL dst (6LN), например, Узел G (RUL) -> Узел E -> Узел B -> Узел A (корень) -> Узел B -> Узел E -> Узел H (RAL). 6LR_ia представляет промежуточные маршрутизаторы между источником и корнем, 1 <= ia <= n, где n – число маршрутизаторов (6LR). 6LR_id представляет промежуточные маршрутизаторы между корнем и получателем, 1 <= id <= m, где m – число маршрутизаторов (6LR).


RPI (RPI1) добавляется первым 6LR (6LR_1) в заголовок IPv6-in-IPv6, адресованный корню. 6LBR удаляет RPI и добавляет свой заголовок IPv6-in-IPv6 с RH3 и RPI (RPI2). В таблице 33 показаны заголовки, которые требуется использовать.


Таблица 33. Использование заголовков при передаче от RUL к RAL в режиме Non-SM.








Заголовок




RUL src




6LR_1




6LR_ia




6LBR




6LR_id




RAL dst








Добавленные заголовки




RPI1




IP6-IP6 (RPI1)




–




IP6-IP6 (RH3, RPI2)




–




–








Изменённые заголовки




–




–




RPI1




–




IP6-IP6 (RH3, RPI2)




–








Удалённые заголовки




–




–




–




IP6-IP6 (RPI1)




–




–








Неизменные заголовки




–




–




–




–




–




–








8.3.4. Пример потока от RUL к RUL


Поток имеет вид RUL (узел IPv6 src) -> 6LR_1 -> 6LR_ia -> корень (6LBR) -> 6LR_id -> RUL (узел IPv6 dst), например, Узел G -> Узел E -> Узел B -> Узел A (корень) -> Узел C -> Узел J. 6LR_ia представляет промежуточные маршрутизаторы между источником и корнем, 1 <= ia <= n, где n – число маршрутизаторов (6LR). 6LR_id представляет промежуточные маршрутизаторы между корнем и получателем, 1 <= id <= m, где m – число маршрутизаторов (6LR).


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


Таблица 34. Использование заголовков при передаче между RUL в режиме Non-SM.








Заголовок




RUL src




6LR_1




6LR_ia




6LBR




6LR_id




6LR_m




RUL dst








Добавленные заголовки




–




IP6-IP6 (RPI1)




–




IP6-IP6 (RH3, RPI2)




–




–




–








Изменённые заголовки




–




–




RPI1




–




IP6-IP6 (RH3, RPI2)




–




–








Удалённые заголовки




–




–




–




IP6-IP6 (RPI1)




–




IP6-IP6 (RH3, RPI2)




–








Неизменные заголовки




–




–




–




–




–




–




–








9. Операционные вопросы поддержки RUL


Примерно половина описанных в документе вариантов связана с листьями (хостами), не «говорящими» на RPL. Эти узлы делятся на 2 категории – одни отбрасывают пакеты с заголовками RPI или RH3, другие продолжают обработку пакетов с такими заголовками.


В [RFC8200] указаны новые правила, предполагающие, что узлам, не настроенным (явно) на проверку заголовков Hop-by-Hop Options, следует игнорировать эти заголовки и продолжать обработку пакета. Несмотря на это и на переход от типа 0x63 к 0x23, в сети могут быть узлы, ещё не соответствующие RFC 8200, которые будут отбрасывать пакеты. В которых сохраняются артефакты RPL. В общем случае поддержка таких узлов в RPL LLN является непростой задачей.


В некоторых конкретных случаях можно удалить артефакты RPL до пересылки пакеты хосту-листу. Важно, чтобы артефакты были вставлены корнем RPL в заголовок IPv6-in-IPv6 и этот заголовок был адресован маршрутизатору 6LR, расположенному непосредственно перед листом. В этом случае маршрутизатор удаляет заголовок IPv6-in-IPv6 вместе с артефактами RPL.


Описанный выше случай возникает всякий раз, когда приходит трафик извне LLN (Internet в приведённых выше вариантах) в режиме Non-Storing. В этом режиме корень RPL знает точную топологию (поскольку он должен создавать заголовок RH3) и, следовательно, знает, как маршрутизатор 6LR расположен перед листом. Например, на рисунке 3 узел E является 6LR перед листом G, а узел C – 6LR перед листом J.


Трафик от корня RPL (например, при совмещении системы сбора данных с корнем RPL) не требует заголовка IPv6-in-IPv6 (в режиме Storing или Non-Storing), поскольку пакеты исходят из корня, а тот может вставлять заголовки RPI и RH3 напрямую в создаваемый пакет. Такие пакеты немного меньше, но могут передаваться лишь узлам (независимо от поддержки ими RPL), воспринимающим артефакты RPL.


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


Поскольку в режиме Storing полный путь трафика неведом, узлы, не воспринимающие (отбрасывающие) артефакты RPL, не могут поддерживаться.


10. Операционные вопросы использования 0x23


В этом разделе рассматриваются операционные вопросы, связанные с внедрением нового типа RPI Option Type 0x23.


В процессе загрузки узел получает сообщение DIO с информацией о типе RPI Option, указывающее новый тип RPI в опции DODAG Configuration. Корень DODAG отвечает за настройку сети с новым значением с помощью сообщений DIO и определяет, когда на всех узлах установлено новое значение. Для DODAG следует сменить номер версии DODAG. В случае перезагрузки узел не помнит RPI Option Type, поэтому сообщения DIO передаются с флагом, указывающим новый тип RPI Option.


Опция DODAG Configuration передаётся в сообщении RPL DIO, содержащем уникальной значение счётчика DTSN13. Лист отвечает на это сообщение сообщением DAO с тем же значением DTSN. Это обычная часть маршрутизации RPL – в результате чего корень RPL знает, когда обновлённую опцию DODAG Configuration увидят все узлы.


До завершения перехода всем узлам, понимающим RPL, следует поддерживать оба значения. Процедура перехода запускается при передаче DIO с флагом, указывающим новый тип RPI Option. Использование типа 0x63 продолжается до тех пор, пока не будет уверенности в поддержке типа 0x23 во всей сети, после чего происходит одномоментный переход к типу 0x23. Опция RPI типа 0x23 позволяет передавать пакеты узлам без поддержки RPL. Этим узлам следует игнорировать опцию и продолжать обработку пакетов.


Как отмечено выше, указание новой опции RPI флагом в DODAG Configuration обеспечивает возможность избежать резкого перехода (flag day) с нарушением работы сети, использующей тип 0x63 для RPI Option. Реализациям RPL предлагается воспринимать оба типа 0x63 и 0x23 для RPI Option Type при обработке заголовков для поддержки взаимодействия.


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


11.1. Тип RPL Option


Этот документ обновляет регистрацию в субреестре «Destination Options and Hop-by-Hop Options» [RFC6553], как показано в таблице 35.


Таблица 35. Option Type в RPL Option








Шестнадцатеричное значение




Двоичное значение




Описание




Документ








act




chg




rest








0x23




00




1




00011




Тип RPL Option




Этот документ








0x63




01




1




00011




Тип RPL Option (устарел)




[RFC6553], этот документ








Субреестр «DODAG Configuration Option Flags for MOP 0..6» обновлён в соответствии с таблицей 36.


Таблица 36. Флаг опции DODAG Configuration для индикации RPI Flag Day.








Номер бита




Описание




Документ








3




Тип RPI 0x23 разрешён




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








11.2. Изменение реестра DODAG Configuration Option Flags


Агентство IANA переименовало субреестр «DODAG Configuration Option Flags» в «DODAG Configuration Option Flags for MOP 0..6» с указанием ссылки на этот документ.


11.3. Перевод MOP = 7 в статус Reserved


Агентство IANA изменило статус регистрации значения 7 в субреестре «Mode of Operation» с Unassigned на Reserved. Значение зарезервировано на будущее с указанием ссылки в субреестре на данный документ.


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


Вопросы безопасности, рассмотренные в [RFC6553] и [RFC6554], применимы к пакетам, находящимся в домене RPL.


Описанный в этом документе механизм IPv6-in-IPv6 более ограничен, нежели механизм общего назначения из [RFC2473]. Готовность каждого узла LLN декапсулировать пакеты и пересылать их может использоваться узлами для сокрытия источника атаки. Хотя типичная сеть LLN может быть очень слабым источником злонамеренного трафика (эти сети медленны, а узлы часто имеют ограниченные возможности), при достаточном числе узлов сети LLN могут оказывать существенное влияние, особенно при атаках на другие сети LLN. Кроме того, некоторые варианты применения RPL включают скоростные магистрали с оборудованием уровня ISP [ACP], которое может включать множество интерфейсов 100 Гбит/с.


Блокировка или тщательная фильтрация трафика IPv6-in-IPv6 на входе в LLN, как описано выше, гарантирует, что атака может быть организована лишь со взломанного узла внутри сети LLN. Использование входной фильтрации [BCP38] для исходящего трафика в корне RPL позволяет предупреждать оператора о возникновении атаки, а также отбрасывать вредоносный трафик. Поскольку в сети RPL обычно используется один префикс, назначаемый самой сетью RPL, входная фильтрация [BCP38] включает сравнение лишь с одним префиксом е её легко настроить автоматически.


В некоторых вариантах применения следует пропускать трафик IPv6-in-IPv6 через корень RPL, например, для обмена IPv6-in-IPv6 между новым подключением (узлом) и JRC14 при использовании [BRSKI] и [ZEROTOUCH-JOIN]. В этом случае корню RPL следует тщательно выполнять фильтрацию – координатор присоединения отделен от корня RPL.


При соблюдении указанных предосторожностей атаки с использованием туннелей IPv6-in-IPv6 становятся возможными лишь с узлов LLN по отношению к другим узлам LLN. Такие атаки можно организовать напрямую и они имеют смысл лишь при использовании фиктивных адресов источников или для усиления обратного трафика. Эти атаки возможны и без туннелей IPv6-in-IPv6 путём простой подмены адресов отправителей. Если для атаки нужна двухсторонняя связь, инкапсуляция IPv6-in-IPv6 не даёт преимуществ.


При каждом предложении использовать заголовки IPv6-in-IPv6 возникают вопросы, связанные с безопасностью. В разделе «Вопросы безопасности» [RFC2473] (раздел 9) было предложено обеспечивать безопасность конечных точек туннеля путём защиты пути IPv6 между ними. Эти рекомендации не подходят для сетей RPL. В [RFC5406] приведены дополнительные рекомендации по использованию IPsec. Хотя ESP15 предотвратит подмену адресов отправителей, при использовании [RFC8138] сжатие выполняется до шифрования, поскольку оно связано с потерей данных. После шифрования избыточности, которую можно устранить сжатием, уже не будет. Это небольшие проблемы. Основным вопросом является организация доверенных отношений для использования протокола обмена ключами (Internet Key Exchange Protocol Version 2) IKEv2. Это требует присутствия системы сертификатов на каждом узле, включая все узлы Internet, которым может потребоваться связь с LLN. В результате для использования IPsec в общем случае нужна глобальная инфраструктура PKI.


Ещё важнее то, что использование туннелей IPsec для защиты заголовков IPv6-in-IPv6 в общем случае будет расти в квадратичной зависимости от числа узлов. Это потребует значительных ресурсов узлов с ограничениями в сети с ограниченными ресурсами. А в результате туннели IPsec обеспечат лишь аутентификацию источников, подобную BCP38! Таким образом, IPsec обеспечит для точек выхода переходные гарантии того, что точка входа выполняет входную фильтрацию [BCP38] для приходящего трафика. Простая фильтрация BCP 38 на входе и выходе LLN обеспечивает близкий уровень защиты без проблем расширяемости и доверия, связанных с туннелями IPv6, как описано в [RFC2473]. Применение IPsec не рекомендуется.


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


Описанное здесь использование заголовков RH3 также допускает злоупотребления. Внешний злоумышленник может создать пакет с заголовком RH3, используемым не полностью, и инкапсулировать его для сокрытия RH3 от промежуточных узлов для маскировки источника трафика. В результате заголовок RH3 от атакующего будет скрыт от сети, пока пакет не придёт к адресату, где будет декапсулирован. Как указано в параграфе 4.2 [RFC6554], маршрутизаторы RPL отвечают за гарантию применения SRH лишь между собой. Поэтому при наличии не полностью использованного заголовка RH3 в инкапсулированном пакете декапсулирующий узел должен убедиться, что внешний пакет исходит из домена RPL, отбрасывая несоответствующие пакеты.


Как указано в разделе 2 [RFC6554], граничные маршрутизаторы RPL «не пропускают дейтаграммы с заголовком SRH через границу домена маршрутизации RPL.» Это утверждение должно трактоваться как относящееся к «не полностью использованным» заголовкам. Потреблённый (инертный) заголовок RH3 может присутствовать в пакете, вышедшем из одной сети LLN, прошедшем через Internet и входящем в другую LLN. В соответствии с этим документом такие заголовки не требуется удалять. Здесь не описан случай, когда RH3 вставляется в сети Non-Storing для трафика, покидающего LLN, однако этот документ не препятствую внедрение этого в будущем. Короче говоря, пакет, проходящий через границу домена RPL, может включать заголовок RH3, но этот заголовок должен быть использован полностью.


Если опцию RPI разрешено передавать в LLN через границу, злоумышленник может использовать её для изменения приоритета в пакете, выбирая другое значение RPLInstanceID, например, с более дорогой энергией. Возможны также случаи, когда не все узлы LLN будут доступны с использованием принятого по умолчанию RPLInstanceID, а смена RPLInstanceID позволит атакующему обойти такие фильтры. Подобно RH3, корень RPL вставляет опции RPI для входящего в LLN трафика путём добавления сначала заголовка IPv6-in-IPv6, поэтому RPI от злоумышленника сеть не увидит. У адресата наличие наличие второй опции RPI уже не имеет значения и она просто будет пропущена, поскольку пакет уже идентифицирован, как доставленный конечному получателю.


Для исходящего от RUL трафика при добавлении RUL неинициализированной опции RPI (например, со значением 0), 6LR, служащему граничным маршрутизатором RPL, следует переписать RPI для указания выбранного экземпляра и установки флагов. Это делается для предотвращения 1) передачи листом, который является внешним маршрутизатором, чужого пакета с не имеющей отношения к делу опцией RPI и 2) передачи от листа атакующего некорректной конфигурации и внедрения трафика в защищённый экземпляр. Это применимо также в случае, когда лист, знающий RPL Instance, пытается исправить RPI – маршрутизатору 6LR нужна конфигурация, разрешающая такому узлу выполнять вставку для этого экземпляра.


RH3 и RPI злоумышленник может использовать внутри сети для маршрутизации пакетов необычными путями, возможно для их сокрытия. Такое поведение похоже на обычную работу [RFC6997] и ограничить его нельзя. Это свойство системы, а не ошибка.


В [RFC7416] рассмотрено множество угроз для LLN, не связанных напрямую с заголовками IPv6-in-IPv6, и этот документ не влияет на приведённый там анализ.


Узлы LLN могут использовать механизм IPv6-in-IPv6 для организации атаки на другую часть LLN, скрывая себя как источник атаки. Механизм даже позволяет создать иллюзию атаки извне LLN и при отсутствии противодействия это можно применить для атаки DDOS на узлы Internet. В работе [DDOS-KREBS] приведены примеры уже известных атак этого типа.


Если атака идёт из LLN, её можно ослабить с помощью механизма SAVI16, используя [RFC8505] с [RFC8928]. Атакующий не сможет отправить трафик с незарегистрированного адреса, а процесс регистрации проверяет корректность топологии. Отметим, что в большинстве случаев подлинность проверяется на уровне L2. Если атака происходит извне LLN, инкапсуляцию IPv6-in-IPv6 можно использовать для сокрытия внутренних заголовков маршрутизации, но RH3 обычно использует лишь внутренние адреса LLN. Поэтому RH3 с CmprI < 8 следует считать частью атаки (см. раздел 3 в [RFC6554]).


Узлы за пределами LLN для организации таких атак должны передавать трафик IPv6-in-IPv6 через корень RPL. Для противодействия этому корню RPL следует ограничивать входящие пакеты IPv6-in-IPv6 (простейшее решение) или следует проходить по цепочке заголовков расширения IP для проверки данных верхнего уровня, как описано в [RFC7045]. В частности, корню RPL следует выполнять входную фильтрацию [BCP38] по адресам отправителей для всех заголовков IP, проверяемых в обоих направлениях.


Примечание. В некоторых случаях префикс может применяться в нескольких сетях LLN с использованием механизмов, подобных описанным в [RFC8929]. В таких случаях входная фильтрация [BCP38] должна учитывать это обстоятельство, должен происходить обмен информация между всеми LLN или входные фильтры [BCP38] должны быть перемещены в направлении Internet, чтобы наличие нескольких LLN не имело значения.


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


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


[BCP38] Ferguson, P. and D. Senie, “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing”, BCP 38, RFC 2827, May 2000. <https://rfc-editor.org/info/bcp38>


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


[RFC6040] Briscoe, B., “Tunnelling of Explicit Congestion Notification”, RFC 6040, DOI 10.17487/RFC6040, November 2010, <https://www.rfc-editor.org/info/rfc6040>.


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


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


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


[RFC7045] Carpenter, B. and S. Jiang, “Transmission and Processing of IPv6 Extension Headers”, RFC 7045, DOI 10.17487/RFC7045, December 2013, <https://www.rfc-editor.org/info/rfc7045>.


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


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


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


[ACP] Eckert, T., Behringer, M. H., and S. Bjarnason, “An Autonomic Control Plane (ACP)”, Work in Progress, Internet-Draft, draft-ietf-anima-autonomic-control-plane-30, 30 October 2020, <https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-30>.


[BRSKI] Pritikin, M., Richardson, M. C., Eckert, T., Behringer, M. H., and K. Watsen, “Bootstrapping Remote Secure Key Infrastructures (BRSKI)”, Work in Progress, Internet-Draft, draft-ietf-anima-bootstrapping-keyinfra-45, 11 November 2020, <https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-45>.


[DDOS-KREBS] Goodin, D., “Record-breaking DDoS reportedly delivered by >145k hacked cameras”, September 2016, <https://arstechnica.com/information-technology/2016/09/botnet-of-145k-cameras-reportedly-deliver-internets-biggest-ddos-ever/>.


[RFC0801] Postel, J., “NCP/TCP transition plan”, RFC 801, DOI 10.17487/RFC0801, November 1981, <https://www.rfc-editor.org/info/rfc801>.


[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 2460, DOI 10.17487/RFC2460, December 1998, <https://www.rfc-editor.org/info/rfc2460>.


[RFC2473] Conta, A. and S. Deering, “Generic Packet Tunneling in IPv6 Specification”, RFC 2473, DOI 10.17487/RFC2473, December 1998, <https://www.rfc-editor.org/info/rfc2473>.


[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.


[RFC5406] Bellovin, S., “Guidelines for Specifying the Use of IPsec Version 2”, BCP 146, RFC 5406, DOI 10.17487/RFC5406, February 2009, <https://www.rfc-editor.org/info/rfc5406>.


[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, “IPv6 Flow Label Specification”, RFC 6437, DOI 10.17487/RFC6437, November 2011, <https://www.rfc-editor.org/info/rfc6437>.


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


[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and J. Martocci, “Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy Networks”, RFC 6997, DOI 10.17487/RFC6997, August 2013, <https://www.rfc-editor.org/info/rfc6997>.


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


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


[RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, “Minimal IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) Configuration”, BCP 210, RFC 8180, DOI 10.17487/RFC8180, May 2017, <https://www.rfc-editor.org/info/rfc8180>.


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


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


[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/rfc/rfc9010>.


[TUNNELS] Touch, J. and M. Townsley, “IP Tunnels in the Internet Architecture”, Work in Progress, Internet-Draft, draft-ietf-intarea-tunnels-10, 12 September 2019, <https://tools.ietf.org/html/draft-ietf-intarea-tunnels-10>.


[ZEROTOUCH-JOIN] Richardson, M., “6tisch Zero-Touch Secure Join protocol”, Work in Progress, Internet-Draft, draft-ietf-6tisch-dtsecurity-zerotouch-join-04, 8 July 2019, <https://tools.ietf.org/html/draft-ietf-6tisch-dtsecurity-zerotouch-join-04>.


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


Эта работа была выполнена, благодаря гранту проекта StandICT.eu.


Большое спасибо C. M. Heard за помощь при написании раздела 4, где учтено множество его комментариев.


Авторы благодарны за рецензирование, отзывы и комментарии Dominique Barthel, Robert Cragie, Ralph Droms, Simon Duquennoy, Cenk Guendogan, Rahul Jadhav, Benjamin Kaduk, Matthias Kovatsch, Gustavo Mercado, Subramanian Moonesamy, Marcela Orbiscay, Cristian Perez, Charlie Perkins, Alvaro Retana, Peter van der Stok, Xavier Vilajosana, Éric Vyncke, Thomas Watteyne (в алфавитном порядке).


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


Maria Ines Robles


Universidad Tecno. Nac.(UTN)-FRM, Argentina /Aalto University Finland


Coronel Rodríguez 273


M5500 Mendoza


Provincia de Mendoza


Argentina


Email: mariainesrobles@gmail.com


Michael C. Richardson


Sandelman Software Works


470 Dawson Avenue


Ottawa ON K1Z 5V7


Canada


Email: mcr+ietf@sandelman.ca


URI: http://www.sandelman.ca/mcr/


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




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


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


nmalykh@protokols.ru






1Low-Power and Lossy Network – сеть с ограниченным электропитанием и потерями.






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






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






4DODAG Information Object – информационный объект DODAG.






5Internet Engineering Task Force.






6Internet Engineering Steering Group.






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






8RPL Source Route Header.






9Routing Over Low power and Lossy networks – маршрутизация в сетях LLN.






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






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






12Здесь и далее это обозначение служит сокращением для IPv6-in-IPv6.






13Destination Advertisement Trigger Sequence Number – порядковый номер триггера анонсирования адресатов.






14Join Registrar/Coordinator – координатор/регистратор присоединения.






15Encapsulating Security Payload – инкапсуляция данных защиты.






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



 											


		
						

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

					


					

					
			




	

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