Internet Engineering Task Force (IETF)                  R.A. Jadhav, Ed.
Request for Comments: 9009                                        Huawei
Category: Standards Track                                     P. Thubert
ISSN: 2070-1721                                                    Cisco
                                                              R.N. Sahoo
                                                                  Z. Cao
                                                                  Huawei
                                                              April 2021

Efficient Route Invalidation

Эффективное аннулирование маршрутов

PDF

Аннотация

В документе рассматриваются проблемы, связанные с использованием сообщений NPDAO¹ в RFC 6550, а также требования к оптимизированной схеме обмена сообщениями об аннулировании маршрутов. Кроме того, здесь описано новое сообщение для проактивного аннулирования маршрутов, названное DCO², которое соответствует требованиям к оптимизированному обмену сообщениями об аннулировании маршрутов.

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

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

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

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

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

Авторские права (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], задаёт проактивную схему маршрутизации на основе вектора удалённости. RPL включает необязательные сообщения в форме DAO⁶, которые могут применять маршрутизаторы 6LBR⁷ и 6LR⁸ для изучения маршрутов к нисходящим узлам. 6LoWPAN является сокращением для IPv6 через беспроводные персональные сети с недостаточным электропитанием. В режиме сохранения (Storing) сообщения DAO приводят к созданию маршрутных записей на всех промежуточных 6LR от родительского узла ко всем 6LBR.

RPL позволяет использовать сообщения NPDAO для аннулирования пути, соответствующего данному адресату, с освобождением используемых для этого пути ресурсов. NPDAO является сообщением DAO с нулевым сроком действия маршрута, которое исходит от целевого узла и перемещается в восходящем направлении к 6LBR. В этом документе разъясняются проблемы, связанные с использованием сообщения NPDAO в [RFC6550], а также требования по оптимизации схемы сообщений об аннулировании маршрутов. Кроме того, документ определяет новое сообщение о проактивном аннулировании маршрутов DCO, соответствующее требованиям к оптимизированной схеме сообщений.

Этот документ относится лишь к режиму хранения RPL (Storing MOP⁹). Режим Non-Storing MOP не требует использования NPDAO для аннулирования маршрутов, поскольку маршрутные записи не поддерживаются в 6LR.

1.1. Уровни требований и термины

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

От читателей этой спецификации требуется знакомство с терминами и концепциями документа «RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks» [RFC6550].

Low-Power and Lossy Network (LLN) — сеть с недостаточным электропитанием и большими потерями

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

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

Промежуточный маршрутизатор, способный передавать и принимать сообщения RA (Router Advertisement) и RS (Router Solicitation), а также пересылать и маршрутизировать пакеты IPv6.

Directed Acyclic Graph (DAG) — направленный ациклический граф

Направленный граф, в котором все ребра ориентированы так, что не возникает петель.

Destination-Oriented DAG (DODAG) — ориентированный на получателя граф DAG

DAG, маршрутизируемый у одного получателя, т. е. корень DAG без исходящих рёбер.

6LoWPAN Border Router (6LBR) — маршрутизатор 6LoWPAN

Граничный маршрутизатор, служащий корнем DODAG и граничным узлом для трафика 6LoWPAN.

Destination Advertisement Object (DAO) — объект анонсирования получателя

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

DODAG Information Object (DIO) — объект с информацией DODAG

Сообщения DIO позволяют организовать восходящие маршруты к 6LBR. DIO инициируются в корне DAO.

Common ancestor node — узел общего предка

Первый общий узел 6LR или 6LBR для двух путей к целевому узлу.

No-Path DAO (NPDAO) – сообщение DAO об отсутствии пути

Сообщение DAO с нулевым сроком действия, служащее для аннулирования маршрутов.

Destination Cleanup Object (DCO) — объект “очистки” адресата

Новый код управляющего сообщения RPL для проактивного аннулирования маршрутов в RPL.

Regular DAO — обычное сообщение DAO

Сообщение DAO с ненулевым сроком действия, служащее для создания или обновления отношений смежности.

Target node — целевой узел

Узел, меняющий родителя, для которого обновляется (создание или удаление) маршрутная смежность.

1.2. Сообщения RPL NPDAO

RPL использует сообщения NPDAO в режиме Storing так, что узел, меняющий свою маршрутную смежность может аннулировать прежний маршрут. Это нужно для того, чтобы можно было освободить ресурсы прежнего пути (такие, как маршрутные записи), которые поддерживались от имени целевого узла. В этом документе рассматривается топология, показанная на рисунке 1.

   (6LBR)
     |
     |
     |
    (A)
    / \
   /   \
  /     \
(G)     (H)
 |       |
 |       |
 |       |
(B)     (C)
  \      ;
   \    ;
    \  ;
     (D)
     / \
    /   \
   /     \
 (E)     (F)

Рисунок 1. Простая топология.

Узел D подключён через предпочитаемого родителя B и имеет дополнительный путь к 6LBR через C. Узел A является общим предком D для путей через B-G и C-H. При переключении D с узла B на узел C протокол RPL позволяет передать сообщение NPDAO узлу B и обычное сообщение DAO узлу C.

1.3. Важность сообщений NPDAO

Ресурсы узлов LLN обычно ограничены. Узел имеет ограниченную память, а маршрутные записи является основным содержимым динамической памяти узлов. Аннулирование маршрутов помогает узлам 6LR принимать решение об удалении маршрутных записей для более эффективного использования ограниченных ресурсов. Поэтому требуется механизм эффективного аннулирования маршрутов. Отметим, что одна смена родителя может приводить к смене предка для субдерева. Таким образом, аннулирование маршрутов должно происходить от имени субдерева, а не только от имени меняющего родителя узла. В приведённом выше примере, где узел D меняет своего родителя, требуется обновить маршрутные записи узлов C, H, A, G и B, где адресатами являются D, E, F. Без эффективного аннулирования маршрутов 6LR может сохранять ненужные маршрутные записи.

2. Проблемы, связанные с RPL NPDAO

2.1. Потеря NPDAO в результате обрыва канала к прежнему родителю

При смене узлом родителя передаётся сообщение NPDAO прежнему родителю и обычное сообщение DAO — новому родителю. При смене родителя в результате отказа узла или канала, сообщение NPDAO может не отправляться.

2.2. Аннулирование маршрутов зависимых узлов

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

В приведённом примере при смене родителя узлом D этот узел создаёт сообщение NPDAO от своего имени. Зависимые узлы E и F не создают сообщений NPDAO для своих прежних путей через D к узлам B и G, в результате чего на узлах B и G сохраняются устаревшие записи для E и F.

2.3. Возможность простоя маршрута из-за асинхронности NPDAO и DAO

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

В приведённом примере узел D меняет родителя B на C и сообщение NPDAO, переданное по прежнему пути, может аннулировать предыдущий маршрут и невозможно определить обновление записей на новом пути сообщением DAO.

3. Требования к оптимизации NPDAO

3.1. Требование 1 — независимость от канала к прежнему родителю

Когда меняющий родителя узел передаёт NPDAO прежнему родителю, обычным делом будет отказ на канале к этому родителю (причина смены). Поэтому нужно обеспечить независимость аннулирования маршрута от канала к прежнему родителю с возникшими отказами.

3.2. Требование 2 — аннулирование маршрута для зависимых узлов

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

3.3. Требование 3 — независимость трафика данных от аннулирования пути

При передаче сообщений NPDAO и DAO возможны ситуации, когда NPDAO аннулирует прежний путь, а сообщение DAO будет потеряно и новый путь не будет создан. Это приведёт к недоступности нисходящего пути к сменившему родителя узлу, поэтому желательно синхронизировать аннулирование маршрута с DAO.

4. Изменение сигнализации RPL

4.1. Смена семантики аннулирования маршрутов в RPL

Как указано в параграфе 1.2, сообщения NPDAO исходят от меняющего родителя узла и передаются в восходящем к корню направлении. Для решения проблемы, отмеченной в разделе 2, этот документ определяет новое сообщение DCO, анонсирующее удаление маршрута, которой исходит от общего узла-предка и передаётся по прежнему пути в нисходящем направлении. Общий предок создаёт сообщение DCO при удалении следующего интервала на пути к цели. Например, в качестве отложенного отклика на получение обычного DAO от другого дочернего узла с той же или более новым Path Sequence для цели, передача DCO отменяется.

Маршрутизаторы 6LR в пути DCO аннулируют маршрут на основе данных DCO, а затем передают другое сообщение DCO с теми же сведениями следующему маршрутизатору или маршрутизаторам в нисходящем направлении. Эта операция похожа на обработку DAO промежуточными 6LR в режиме Storing MOP [RFC6550]. Подобно DAO в Storing MOP, сообщение DCO передаётся с использованием локального для канала индивидуального адреса IPv6 link-local для отправителя и получателя, но в отличие от DAO, передаваемых в восходящем направлении, сообщения DCO передаются в нисходящем направлении.

В приведённом на рисунке 1 примере дочерний узел D при смене родителя B на C передаёт обычное сообщение DAO узлу C с информацией о доступности, включающей адрес D как цель и инкрементированное значение Path Sequence. Узел C обновляет таблицу маршрутизации на основе сведений о доступности из DAO, затем создаёт новое сообщение DAO с теми же данными о доступности, пересылаемое узлу H. На узле H выполняется такая же процедура, как на узле C и передаётся сообщение узлу A. Когда A получает обычное сообщение DAO, он видит, что в таблице маршрутизации уже имеется целевой адрес (Target Address) узла D. Однако он будет видеть, что информация о следующем интервале на пути к узлу D изменилась, что говорит о смене пути узлом D. В этом случае узел A, который является общим предком для двух путей к D (прежний и новый), может создать сообщение DCO, передаваемое в нисходящем направлении по старому пути к цели. Узел A выполняет обычную пересылку DAO маршрутизатору 6LBR, как требует [RFC6550].

4.2. Изменение опции Transit Information

Каждое сообщение RPL делится на базовые поля и опции, как описано в разделе 6 [RFC6550]. Базовые поля относятся к сообщению в целом, а опции добавляют зависимые от сообщения и варианта использования атрибуты. Например, сообщение DAO может включать одну или несколько опций RPL Target, которые указывают к каким целям относятся сведения о доступности. С набором опций RPL Target может быть связана опция Transit Information.

Этот документ меняет спецификацию опции Transit Information путём включения флага аннулирования прежнего маршрута I¹⁰, который информирует общего предка о необходимости создать сообщение DCO от имени целевого узла с полем RPL Status 195, указывающим перемещение адреса. Флаг I передаётся в опции Transit Information, которая дополняет сведения о доступности для данного набора RPL Target. Опцию Transit Information с флагом I следует передавать в сообщении DAO при аннулировании маршрута к соответствующим целям.

Значение 195 представляет установленные биты U и A в поле RPL Status (см. рисунок 6 в [RFC9010]), где 6 младших битов содержат значение 6LoWPAN Neighbor Discovery (ND) EARO¹¹ Status 3, указывающее состояние Moved в соответствии с таблицей 1 в [RFC8505].

 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 = 0x06 | Option Length |E|I|  Flags    | Path Control  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Обновлённая опция Transit Information (новый флаг I).

I (Invalidate previous route)

Флаг I устанавливается целевым узлом для указания общему предку своего желания аннулировать все прежние маршруты.

[RFC6550] позволяет передавать адрес родителя в опции Transit Information в зависимости от MOP. В случае Storing MOP это поле обычно не требуется, а для DCO включение поля Parent Address недопустимо.

При получении сообщения DAO с опцией Transit Information, имеющей флаг I, в качестве отложенного отклика, удаляющего маршрутную смежность с указанной в опции Transit Information цели, узлу общего предка следует генерировать сообщения DCO для следующего интервала, связанного с этой смежностью. Флаг I предоставляет целевому узлу контроль над аннулированием его маршрутов, служа сигналом для генерации сообщения DCO.

4.3. Объект «очистки» адресата (DCO)

Определён новый код управляющего сообщения ICMPv6 RPL, названного DCO, которое служит для проактивной очистки состояния и маршрутных данных, сохраняемые в 6LR от имени целевого узла. Сообщения DCO передаются в нисходящем направлении и сбрасывают маршрутные данные и другие сведения о состоянии, связанные с данной целью. Формат сообщения DCO показан на рисунке 3.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D|   Flags   |   RPL Status  | DCOSequence   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                    DODAGID (необязательно)                    +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Опции...
+-+-+-+-+-+-+-+-+

Рисунок 3. Базовый объект DCO.

RPLInstanceID

8-битовое поле, указывающее связанный с DODAG экземпляр топологии, определённый из DIO.

K

Флаг K указывает, что от получателя сообщения DCO ожидается отправка подтверждения DCO-ACK. Если сообщение DCO-ACK не даже при установке флага K, реализация может позднее повторить DCO. Число повторов зависит от реализации и предполагается значение, близкое к числу повторов DAO [RFC6550]. Вопрос числа попыток DCO рассматривается в параграфе 4.6.3. Узел, получивший сообщение DCO без флага K, может отвечать сообщением DCO-ACK, особенно для информирования об ошибках. Примером такой ошибки может служить ситуация, когда передающий DCO-ACK узел не нашёл маршрутной записи для указанной цели. Отказ отправителя от установки флага K говорит о том, что отправитель не ждёт ответа и ему не следует повторять DCO.

D

Флаг наличия поля DODAGID, который должен устанавливаться при использовании локального RPLInstanceID.

Flags

Оставшиеся 6 битов поля Flags зарезервированы на будущее. Отправитель должен устанавливать в них 0, а получатель должен игнорировать.

RPL Status

Статус, определённый в [RFC6550] и обновленный в [RFC9010]. Корневой узел или общий предок, генерирующий DCO, полномочен устанавливать сведения о статусе, которые не меняются при нисходящем распространении DODAG. Этот документ не задаёт дифференциации действий в зависимости от RPL Status.

DCOSequence

8-битовое поле, инкрементируемое для каждого уникального сообщения DCO от узла, которое включается в сообщение DCO-ACK. Начальное значение DCOSequence узел может выбирать произвольно. Обработка DCOSequence описана в параграфе 4.4.

DODAGID

128-битовое целое число без знака, устанавливаемое корнем DODAG для однозначной идентификации DODAG. Поле должно присутствовать при установке флага D и недопустимо при сброшенном флаге D. Значение DODAGID применяется при использовании локального RPLInstanceID для указания DODAGID, связанного с RPLInstanceID.

4.3.1. Secure DCO

Сообщение Secure DCO следует формату, заданному на рисунке 7 в [RFC6550]. Базовый формат сообщения DCO показан на рисунке 3.

4.3.2. Опции DCO

Сообщение DCO должно включать по меньшей мере одну опцию RPL Target и Transit Information, а также может включать иные опции. Данная спецификация позволяет включать в DCO опции:

• 0x00 Pad1;

• 0x01 PadN;

• 0x05 RPL Target;

• 0x06 Transit Information;

• 0x09 RPL Target Descriptor.

Указанные опции определены в параграфе 6.7 [RFC6550]. Сообщение DCO содержит опцию RPL Target и связанную с ней опцию Transit Information со сроком действия 0x00000000 для индикации потери связности с указанной целью.

4.3.3. Последовательность путей в DCO

Сообщение DCO содержит опцию Transit Information для каждого аннулируемого пути. Значение счётчика Path Sequence в опции Transit Information позволяет определить свежесть сообщения DCO по сравнению с самым новым, известным маршрутизаторам 6LR на удаляемом пути. Если сообщение DCO создано общим предком в ответ на сообщение DAO, опция Transit Information в DCO должна использовать значение Path Sequence из новейшей опции Transit Information, которая была получена для цели общим предком. Если 6LR на нисходящем пути получает DCO с Path Sequence не новее Path Sequence из опции Transit Information в сообщении DAO, маршрутизатору 6LR недопустимо удалять своё текущее состояние маршрутизации и недопустимо пересылать DCO вниз по пути, где сообщение не является более свежим. Если DCO новее, маршрутизатор 6LR может сохранить временное состояние, чтобы обеспечить игнорирование DAO, полученного позднее с опцией Transit Information, содержащей более старый порядковый номер. Опция Transit Information в сообщении DAO, которая соответствует или новее, чем чем в DCO, означает, что указанный в DAO установлен и сообщение DAO распространено. При распространении DCO в результате приёма DCO от восходящего родителя, значение Path Sequence должно копироваться из полученного DCO.

4.3.4. Подтверждение DCO-ACK

Сообщение DCO-ACK получателю DCO следует передавать в индивидуальном пакете в ответ на индивидуальное сообщение DCO с флагом K. Если флаг K не установлен, получатель сообщения DCO может передать DCO-ACK, особенно при возникновении ошибки. Формат сообщения DCO-ACK показан на рисунке 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |D|   Flags     |  DCOSequence  | DCO-ACK Status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                    DODAGID (необязательно)                    +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Базовый объект DCO-ACK.

RPLInstanceID

8-битовое поле, указывающее связанный с DODAG экземпляр топологии, определённый из DIO.

D

Флаг наличия поля DODAGID, который должен устанавливаться при использовании локального RPLInstanceID.

Flags

7 резервных битов поля Flags. Отправитель должен устанавливать в них 0, а получатель должен игнорировать.

DCOSequence

8-битовое поле. Значение DCOSequence в DCO-ACK копируется из DCOSequence в принятом сообщении DCO.

DCO-ACK Status

Указывает статус завершения. Поле DCO-ACK Status определено на основе рисунка 6 в [RFC9010], указывающего формат RPL Status. StatusValue = 0 при сброшенном (0) флаге U указывает безусловное восприятие. StatusValue = 1 с установленным (1) флагом U говорит об отсутствии маршрутной записи, как указано в параграфе 5.3.

DODAGID

128-битовое целое число без знака, устанавливаемое корнем DODAG для однозначного указания DODAG. Поле должно присутствовать при установленном флаге D и недопустимо при сброшенном флаге D. Поле DODAGID применяется при использовании локального RPLInstanceID для указания DODAGID, связанного с RPLInstanceID.

4.3.5. Secure DCO-ACK

Формат сообщения Secure DCO-ACK следует приведённому на рисунке 7 в [RFC6550], а базовый формат сообщения DCO-ACK показан на рисунке 4.

4.4. Базовые правила DCO

1. Если узел передаёт сообщение DCO с более новой или просто отличающейся от переданной в предыдущем DCO информацией, он должен инкрементировать поле DCOSequence. При передаче сообщения DCO, идентичного переданному ранее, узел может инкрементировать DCOSequence. Счётчик DCOSequence работает в соответствии с правилами параграфа 7.2 в [RFC6550].

2. Поля RPLInstanceID и DODAGID в сообщении DCO должны содержать значения соответствующих полей сообщения DAO, в ответ на которое узел общего предка создаёт сообщение DCO.

3. Узел может установить флаг K в индивидуальном сообщении DCO для запроса индивидуального DCO-ACK с целью подтверждения попытки.

4. Узлу, получившему индивидуальное сообщение DCO с флагом K, следует отвечать сообщением DCO-ACK. При сброшенном флага K в полученном сообщении DCO узел может передать DCO-ACK, особенно при наличии ошибки.

5. Узел, получивший индивидуальное сообщение DCO, должен проверить сохранённое значение Path Sequence в контексте данной цели. Если сохранённое значение Path Sequence не старее полученного в DCO, сообщение DCO должно отбрасываться.

6. Узел, установивший флаг K в индивидуальном сообщении DCO, но не получивший в ответ DCO-ACK, может запланировать повтор сообщения DCO вплоть до заданного реализацией числа попыток.

7. Узел, получивший индивидуальное сообщение DCO со своим адресом в опции RPL Target, должен вырезать опцию Target. Если эта опция Target является единственной в сообщении DCO, сообщение DCO должно отбрасываться.

Диапазон значения DCOSequence уникален для узла, генерирующего сообщения.

4.5. Незапрошенные DCO

Маршрутизатор 6LR может создавать сообщения DCO без запроса для односторонней очистки пути от имени целевой записи. 6LR имеет все сведения о состоянии, а именно Target Address и Path Sequence, требуемые для генерации DCO по его таблице маршрутизации. Условия, при которых 6LR может генерировать DCO без запроса, выходят за рамки этой спецификации, но могут включать перечисленные ниже.

1. По завершении срока действия записи 6LR может аккуратно очистить её, инициируя сообщение DCO.

2. 6LR должен поддерживать записи с более высоким приоритетом и заполнение таблицы требует удаления имеющихся записей. Это удаление может быть выполнено путём создания DCO.

Сообщение DCO, созданное независимо от DAO (асинхронно) и предназначено для сброса всех состояний на пути независимо от Path Sequence, должно использовать в Path Sequence значение 240 (см. параграф 7.2 в [RFC6550]). Это значение позволяет DCO «выиграть» у любого установленного пути DAO, но проигрывает устанавливаемому пути DAO. Если предок инициирует одностороннюю очистку на созданном пути с использованием DCO м Path Sequence 240, сообщение DCO в конечном итоге достигнет целевого узла, который в результате узнает об аннулировании пути.

4.6. Другие вопросы

4.6.1. Аннулирование зависимых узлов

Спецификация RPL [RFC6550] не включает механизма аннулирования маршрутов для зависимых узлов. Этот документ позволяет зависимым узлам аннулировать маршруты. Зависимые узлы генерируют соответствующие сообщения DAO для обновления путей и предыдущее аннулирование маршрутов для этих узлов должно работать подобно описанному выше для узла, меняющего родителя. Зависимый узел может установить флаг I в опции Transit Information как часть обычного DAO для запроса аннулирования прежнего маршрута от общего предка.

Зависимые узлы не имеют указаний по части возможной смены их родителями своих родителей. Таким образом, для аннулирования маршрута зависимый узел может устанавливать флаг I во всех опциях Transit Information своих сообщений DAO. Установка флага I не препятствует работе, даже при отсутствии аннулирования прежнего маршрута.

4.6.2. NPDAO и DCO в одной сети

Механизм NPDAO, предусмотренный в [RFC6550], по-прежнему можно использовать в одной сети с DCO. Сообщения NPDAO могут применяться, например, по истечении срока действия маршрута целевого объекта или при решении узла корректно завершить сессию RPL при отключении узла (shutdown). Кроме того, в сети может использоваться сочетание узлов, поддерживающих DCO и имеющийся механизм NPDAO. Возможно также использование одним узлом сигнализации NPDAO и DCO для аннулирования маршрутов.

В параграфе 9.8 [RFC6550] сказано: «При удалении узлом другого узла из числа родителей DAO ему следует передать сообщение No-Path DAO (параграф 6.4.3) этому удаляемому родителю DAO для аннулирования имеющегося маршрута.» Этот документ добавляет более оптимальный способ аннулирования маршрута, сохраняя возможность использования сообщений NPDAO. В результате реализация имеет 2 варианта аннулирования маршрута.

1. Использование NPDAO для аннулирования прежнего маршрута и отправка обычного DAO по новому пути.

2. Передача по новому пути обычного DAO с флагом I в опции Transit Information, чтобы общий предок инициировал нисходящее сообщение DCO для аннулирования прежнего маршрута.

Этот документ рекомендует использовать вариант 2 по причинам, указанным в разделе 3.

В этом документе предполагается поддержка данной спецификации всеми маршрутизаторами 6LR в сети. При наличии узлов 6LR, не поддерживающих спецификацию, которые расположены на пути передачи DCO, аннулирование маршрутов для соответствующих целей (из сообщения DCO) может не сработать или сработать частично. Узел может создать сообщение NPDAO, не получив DCO с указанием себя как цели в течение заданного интервала времени, зависящего от реализации, максимальной глубины сети и средней задержки на интервал пересылки. Отметим, что отправка NPDAO и DCO для одной операции не будет приводить к нежелательным побочным эффектам, поскольку восприятие NPDAO или DCO зависит от свежести Path Sequence.

4.6.3. Повторы DCO

Отправитель сообщения DCO может повторит его, если был установлен флаг K, а ответного DCO-ACK не получено. Время повтора DCO может зависеть от глубины сети и средней задержки на этапе пересылки (hop) и составляет 2 — 120 секунд в зависимости от сети. Если пределы задержки не известны, реализации недопустимо повторять передачу чаще 1 раза за 3 секунды и недопустимо использовать более трёх повторов.

Число повторов может также зависеть от критичности аннулирования маршрутов для сети и настройки повторов на канальном уровне. Для сетей, поддерживающих лишь потоки MP2P¹² и P2MP¹³, таких как AMI¹⁴ и телеметрия, маршрутизаторы 6LR могут не очень стремиться аннулировать маршруты, если у них нет сильных ограничений на память. Для сетей автоматизации зданий и жилых помещений, где может присутствовать значительная доля трафика P2P, маршрутизаторы 6LR могут быть заинтересованы в быстром аннулировании маршрутов, поскольку это может влиять на эффективность пересылки.

4.6.4. DCO с множеством предпочтительных родителей

[RFC6550] позволяет узлу выбрать множество предпочтительных родителей для организации маршрутов. В параграфе 9.2.1 [RFC6550] сказано: «Все DAO, созданные одновременно для одной цели Target, должны передаваться с одним значением Path Sequence в опции Transit Information». Впоследствии, при необходимости инициировать аннулирование маршрута можно использовать сообщение NPDAO, которое может быть инициировано обновлением Path Sequence для всех родительских узлов, через которые проходит аннулируемый маршрут (см. [RFC6550]).

В случае DCO сам целевой узел не инициирует аннулирование маршрута, оставляя это узлу общего предка. При обнаружении узлом общего предка DAO с новым следующим интервалом он инициирует DCO. Реализациям рекомендуется инициировать DCO с некоторой задержкой (DelayDCO), чтобы узел общего предка мог получить обновлённые DAO от всех возможных next-hop. Это поможет снизить связанные с DCO издержки, т. е. общий предок может дождаться обновлённых DAO со всех возможных направления перед инициированием DCO для аннулирования маршрута. После ожидания требуется создать DCO для всех next-hop, где нужно аннулировать маршруты.

Этот документ рекомендует использовать для таймера DelayDCO значение в 1 секунду, основанное на принятом по умолчанию таком же значении для таймера DelayDAO в [RFC6550]. Это основано на предположении, что DAO от всех возможных наборов родителей будут получены общим предком в этом интервале времени.

Возможность генерации DCO до получения обновлённых DAO от всех путей сохраняется. В этом случае узел-предок начнёт процедуру аннулирования для путей, от которых получены обновлённые DAO. Создаваемое при этом сообщение DCO будет запускать аннулирования сегментов, на путях, где обновлённые DAO не приняты. Но при достижении сообщениями DAO этих сегментов состояние маршрутизации для них будет обновляться и несогласованности состояний маршрутизации не возникает.

Отметим, что синхронизация DCO и DAO не требуется и таймер DelayDCO просто снижает издержки на управление DCO и требуется лишь в сетях с узлами, имеющими множество предпочтительных родителей.

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

Агентство IANA выделило коды для сообщений DCO и DCO-ACK в реестре RPL Control Codes (таблица 1).

Таблица 1. Новые коды для сообщений DCO и DCO-ACK.

Выделен также бит 1 из реестра Transit Information Option Flags для флага I (4.2. Изменение опции Transit Information).

5.1. Новый реестр для флагов DCO

Агентство IANA создало реестр для 8-битового поля флагов DCO, названный Destination Cleanup Object (DCO) Flags и размещённый в реестре Routing Protocol for Low Power and Lossy Networks (RPL). Новые флаги в этом реестре могут выделяться лишь по процедуре IETF Review [RFC8126]. Для каждого бита отслеживаются 3 параметра:

• номер (отсчёт с 0 для старшего бита);

• описание возможности;

• определяющий флаг документ RFC.

Выделенные к настоящему времени биты указаны в таблице 2.

Таблица 2. Базовые флаги DCO.

5.2. Новый реестр для флагов подтверждения DCO

Агентство IANA создало реестр для 8-битового поля флагов DCO-ACK, названный Destination Cleanup Object (DCO) Acknowledgment Flags и размещённый в реестре Routing Protocol for Low Power and Lossy Networks (RPL).Новые флаги в этом реестре могут выделяться лишь по процедуре IETF Review [RFC8126]. Для каждого бита отслеживаются 3 параметра:

• номер (отсчёт с 0 для старшего бита);

• описание возможности;

• определяющий флаг документ RFC.

Выделенный к настоящему времени флаг указан в таблице 3.

Таблица 3. Базовый флаг DCO-ACK.

5.3. Значения RPL Rejection Status

Этот документ добавляет значение в реестр RPL Rejection Status, созданный в [RFC9010] (параграф 12.6).

Таблица 4. Базовый флаг DCO-ACK.

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

Этот документ предоставляет узлу общего предка возможность аннулировать маршрут от имени целевого узла. Общий предок может делать это по наличию флага I в опции Transit Information сообщения DCO от целевого узла. Однако общий предок может аннулировать маршрут и по своей инициативе, поскольку он обладает всеми нужными сведениями, а именно Target Address и соответствующее значение Path Sequence. Это позволяет мошенническому узлу общего предка аннулировать маршруты и влиять на трафик к целевому узлу.

DCO передаёт значение RPL Status, являющееся информативным. С течение времени могут выделяться новые значения статуса и узел будет игнорировать неизвестные значения. Это позволяет использовать поле RPL Status для создания скрытого канала. Но канал работает лишь 1 раз, поскольку сообщение уничтожает свою среду (маршрут).

В этом документе определён флаг I, устанавливаемый целевым узлом и применяемый узлом-предком для инициирования сообщения DCO, если предок видит обновление смежности в маршрутизации. Однако флаг может быть подделан вредоносным маршрутизатором 6LR на пути и вызвать аннулирование имеющегося активного маршрута. Аннулирование будет срабатывать лишь при выполнении условия Path Sequence для цели, к которой предпринимается попытка аннулировать маршрут. При этом злонамеренный 6LR может подделать сообщение DAO от имени потомка, установив в нем флаг I для аннулирования маршрута от имени этого потомка. Следует отметить, что при использовании механизмов, предложенных в [RFC6550], вредоносный маршрутизатор 6LR может также создать поддельное сообщение DAO с нулевым сроком действия или вызвать отказ в обслуживании путём полного отбрасывания трафика, поэтому предложенный в данном документе механизм не ведёт к существенному росту рисков.

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

Для всех сообщений RPL имеются защищённые варианты, обеспечивающие контроль целостности с использованием кодов MAC¹⁵ или подписей. Кроме того, для защищённых сообщений RPL доступно шифрование.

Этот документ добавляет сообщения DCO и DCO-ACK, синтаксически похожие на имеющиеся сообщения RPL, такие как DAO и DAO-ACK. Защищённые версии DCO и DCO-ACK используют методы, похожие на методы защиты других сообщений RPL (таких как DAO и DAO-ACK).

RPL поддерживает 3 режима защиты, описанных в параграфе 10.1 [RFC6550].

Unsecured — без защиты

В этом режиме RPL использует базовые сообщения DIS, DIO, DAO, DAO-ACK без разделов Security. Поскольку в сети могут применяться иные методы защиты (например, защита на канальном уровне), использование этого режима не означает полного отсутствия защиты сообщений.

Preinstalled — с предустановленным ключом

В этом режиме RPL применяет защищённые сообщения, поэтому должны использоваться защищённые варианты DCO и DCO-ACK.

Authenticated — с проверкой подлинности

В этом режиме RPL применяет защищённые сообщения, поэтому должны использоваться защищённые варианты DCO и DCO-ACK.

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

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

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

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

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

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

Приложение A. Примеры сообщений

A.1. Пример сообщений DCO

В этом примере узел D (рисунок 1) меняет родителя B на C. В примере предполагается наличие у узла D своего маршрута через B-G-A-6LBR, использующего pathseq=x. В примере используются соглашения о сообщениях DAO и DCO и указаны лишь требуемые для разъяснения примера параметры, а именно, tgt (опция Target), значение которого задаёт адрес целевого узла, pathseq (Path Sequence) в опции Transit Information и I_flag (флаг I) в той же опции. Последовательность действий приведена ниже.

1. Узел D меняет родителя B на C.

2. D передаёт обычное сообщение DAO(tgt=D,pathseq=x+1,I_flag=1) в обновленный путь к C.

3. C проверяет наличие маршрутной записи от D (которой нет), создаёт новую запись и пересылает сведения о доступности целевого узла D узлу H в сообщении DAO(tgt=D,pathseq=x+1,I_flag=1).

4. Подобно C, узел H проверяет наличие маршрутной записи от D (её нет), создаёт запись и пересылает информацию о доступности цели D узлу A в сообщении DAO(tgt=D,pathseq=x+1,I_flag=1).

5. Узел A получает DAO(tgt=D,pathseq=x+1,I_flag=1) и проверяет наличие записи от узла D. Эта запись имеется и A проверяет в ней следующий интервал пересылки (next-hop) для D, который является другим (узел G). Затем A проверяет I_flag и создаёт сообщение DCO(tgt=D,pathseq=x+1) на прежний next-hop для цели D (узел G). Далее узел A обновляет маршрутную запись и пересылает сведения о доступности цели D в восходящем направлении, используя DAO(tgt=D,pathseq=x+1,I_flag=1).

6. Узел G получает DCO(tgt=D,pathseq=x+1) и сравнивает Path Sequence с сохраненным значением. Если новое значение свежее, G аннулирует маршрутную запись для цели D и пересылает сведения о (не)доступности в нисходящем направлении узлу B в сообщении DCO(tgt=D,pathseq=x+1).

7. Узел B аналогичным способом обрабатывает DCO(tgt=D,pathseq=x+1), аннулируя маршрутную запись для цели D и пересылает сведения о (не)доступности вниз узлу D.

8. Узел D игнорирует сообщение DCO(tgt=D,pathseq=x+1), поскольку сам является целью.

9. Распространение DCO будет останавливаться на любом узле, у которого нет маршрутной информации для цели. Если применяется кэширование маршрутных данных и кэшированное значение Path Sequence больше значения в DCO, сообщение DCO отбрасывается.

A.2. Пример сообщений DCO с несколькими предпочтительными родителями

На рисунке 5 показан выбор узлом (N41) нескольких предпочтительных родителей (N32) и (N33).

1.        (6LBR)
            |
            |
            |
          (N11)
           / \
          /   \
         /     \
      (N21)   (N22)
        /      / \
       /      /   \
      /      /     \
   (N31)  (N32)  (N33)
       :    |    /
        :   |   /
         :  |  /
          (N41)

   Рисунок 5. Пример топологии 2.

   
   (N41) передаёт сообщение DAO(tgt=N41,PS=x,I_flag=1) узлам (N32) и (N33). Значение I_flag указывает флаг аннулирования (Invalidation), а PS — Path Sequence в опции Transit Information.

2. (N32) передаёт DAO(tgt=N41,PS=x,I_flag=1) узлу (N22), а (N33) передаёт этому же узлу сообщение DAO(tgt=N41,PS=x,I_flag=1). (N22) узнает несколько маршрутов к одному получателю (N41) через разные next-hop. Узел (N22) может получить сообщения DAO от (N32) и (N33) с флагом I_flag в любом порядке. Реализации следует использовать таймер DelayDCO перед инициированием DCO. Если (N22) получает обновлённое сообщение DAO от всех путей, инициировать DCO не нужно. Таким образом, таблица маршрутизации N22 должна содержать (Dst,NextHop,PS): { (N41,N32,x), (N41,N33,x) }.

3. (N22) передаёт DAO(tgt=N41,PS=x,I_flag=1) узлу (N11).

4. (N11) передаёт DAO(tgt=N41,PS=x,I_flag=1) граничному маршрутизатору (6LBR). Это создаёт полный путь.

5. (N41) принимает решение о смене набора предпочтительных родителей { N32, N33 } на { N31, N32 }.

6. (N41) передаёт DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N32) и DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N31).

7. (N32) передаёт DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N22). Узел (N22) имеет несколько маршрутов к адресату (N41). Он видит новое значение Path Sequence для Target=N41 и ждёт в течение заданного интервала (DelayDCO) перед аннулированием другого маршрута { (N41),(N33),x }. По истечении срока ожидания (N22) передаёт DCO(tgt=N41,PS=x+1) узлу (N33) и обычное сообщение DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N11).

8. (N33) принимает DCO(tgt=N41,PS=x+1). Полученное значение Path Sequence является более поздним и аннулирует запись, связанную с целью (N41). Затем (N33) передаёт DCO(tgt=N41,PS=x+1) узлу (N41). Узел (N41) видит себя в качестве цели и отбрасывает DCO.

9. После п. 6 узел (N31) получает DAO(tgt=N41,PS=x+1,I_flag=1), в результате чего создаёт маршрутную запись и передаёт DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N21), который получает DAO и в результате передаёт DAO(tgt=N41,PS=x+1,I_flag=1) узлу (N11).

10. (N11) получает DAO(tgt=N41,PS=x+1,I_flag=1) от (N21) и ждёт в течение DelayDCO, поскольку у него имеется несколько маршрутов к (N41). Узел (N41) получит DAO(tgt=N41,PS=x+1,I_flag=1) от (N22) (п. 7). Таким образом, (N11) получит обычные сообщения DAO(tgt=N41,PS=x+1,I_flag=1) от всех путей и не будет инициировать DCO.

11. (N11) пересылает DAO(tgt=N41,PS=x+1,I_flag=1) маршрутизатору (6LBR) и это создаёт полный путь.

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

Большое спасибо Alvaro Retana, Cenk Gundogan, Simon Duquennoy, Georgios Papadopoulos и Peter van der Stok за их рецензии и комментарии. Alvaro Retana помог создать окончательный вариант документа, внеся важные замечания.

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

Rahul Arvind Jadhav (editor)

Huawei

Whitefield

Kundalahalli Village

Bangalore 560037

Karnataka

India

Phone: +91-080-49160700

Email: rahul.ietf@gmail.com

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

Rabi Narayan Sahoo

Huawei

Whitefield

Kundalahalli Village

Bangalore 560037

Karnataka

India

Phone: +91-080-49160700

Email: rabinarayans0828@gmail.com

Zhen Cao

Huawei

W Chang’an Ave

Beijing

China

Email: zhencao.ietf@gmail.com

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

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

nmalykh@protokols.ru

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

Аннотация

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

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

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

Документ является результатом работы IETF⁵ и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG⁶. Дополнительную информацию о стандартах 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 обычно называют RPI⁷, хотя RPI — это информация, определённая в [RFC6550] и передаваемая в RPL Option. В RFC 6554 [RFC6554] определён заголовок RH3⁸, являющийся заголовком расширения IPv6 для доставки дейтаграмм в домене маршрутизации RPL, в частности для режима Non-Storing (без сохранения).

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

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

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

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

Routing Header Dispatch для 6LoWPAN¹⁰ (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 DODAG¹¹. Предполагается, что лист 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.

При перезагрузке узел (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.

В этом документе показано, что источник не всегда может быть уверен в прохождении пакета лишь через домен 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.

Без описанной ниже сигнализации это изменение будет препятствовать взаимодействию (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.

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.

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.

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.

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

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

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.

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 без инкапсуляции.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

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, содержащем уникальной значение счётчика DTSN¹³. Лист отвечает на это сообщение сообщением 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

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

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

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 между новым подключением (узлом) и JRC¹⁴ при использовании [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. Хотя ESP¹⁵ предотвратит подмену адресов отправителей, при использовании [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, её можно ослабить с помощью механизма SAVI¹⁶, используя [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

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

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

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

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

PDF

Аннотация

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

2.2. Глоссарий

6LoRH

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

6LoWPAN

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

DIO

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

DODAG

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

LLN

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

MOP

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

RAL

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

RAN

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

RPI

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

RPL

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

RUL

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

SRH

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

Sub-DODAG

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

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

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

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

Опция DODAG Configuration определена в параграфе 6.7.6 [RFC6550]. Назначение опции расширено для распространения конфигурационных данных, влияющих на создание и поддержку DODAG, а также распространение рабочих параметров RPL через DODAG. Исходная опция DODAG Configuration включала 4 резервных бита для будущих флагов.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 0x04 |Opt Length = 14| | |T| |A|       ...           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
                                <- flags ->

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3. Возврат

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cisco Systems, Inc.

Building D

45 Allee des Ormes — BP1200

06254 MOUGINS — Sophia Antipolis

France

Phone: +33 497 23 26 34

Email: pthubert@cisco.com

Li Zhao

Cisco Systems, Inc.

Xinsi Building

No. 926 Yi Shan Rd

Shanghai

200233

China

Email: liz3@cisco.com

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

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

nmalykh@protokols.ru