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

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

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

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

PDF

Аннотация

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

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

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

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

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

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

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

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

Оглавление

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

1. Введение

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

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

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

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

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

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

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

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


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

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

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

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

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

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

  • В разделах 3 и 4 приведено ненормативное описание основных аспектов RPL и 6LoWPAN ND, используемых в спецификации для подключения 6LN, являющихся RUL, через сеть RPL.

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

  • В разделе 6 представлены изменения по отношению к [RFC6550] – новое поведение, когда 6LR анонсирует адреса 6LN в сообщении RPL DAO на основе регистрации ND узлом 6LN, а корень RPL DODAG выполняет обмен EDAR/EDAC с граничным маршрутизатором 6LoWPAN (6LBR) от имени 6LR и изменения некоторых опций RPL и RPL Status для облегчения интеграции протоколов.

  • В разделе 7 представлены изменения по отношению к [RFC9009] – использование сообщения DCO расширено на режим работы Non-Storing для передачи сведений об асинхронных передачах из корня в 6LR.

  • В разделе 8 представлены изменения по отношению к [RFC6775] и [RFC8505] – диапазон значений статуса ARO/EARO сужен до 64, а оставшиеся биты переведены в резервные.

  • В разделах 9 и 10 представлена работа этой спецификации для индивидуальных и групповых потоков, а раздел 11 посвящён вопросам безопасности.

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

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

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

2.2. Глоссарий

6BBR

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

6CIO

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

6LBR

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

6LN

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

6LoRH

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

6LoWPAN

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

6LR

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

AP-ND

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

ARO

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

DAC

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

DAD

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

DAO

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

DAR

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

DCO

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

DIO

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

DODAG

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

EARO

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

EDAC

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

EDAR

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

EUI

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

LLN

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

MLD

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

MOP

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

NA

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

NBMA

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

NCE

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

ND

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

NS

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

PIO

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

RA

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

RAL

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

RAN

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

RH3

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

ROVR

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

RPI

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

RPL

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

RUL

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

SAVI

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

SLAAC

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

SRH

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

TID

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

TIO

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

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

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

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

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

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

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

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

6LoWPAN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |    Status     |    Opaque     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Rsvd | I |R|T|     TID       |     Registration Lifetime     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~          Registration Ownership Verifier (ROVR)               ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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


4.2.1. Флаг R

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

L

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

E

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

P

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |   Length = 1  |     Reserved      |D|L|B|P|E|G|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Reserved                            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 0x05 | Option Length |F|X|Flg|ROVRsz | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                Target Prefix (Variable Length)                |
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
...            Registration Ownership Verifier (ROVR)         ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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


F

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

X

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

Flg (Flags)

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

ROVRsz (ROVR Size)

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

Registration Ownership Verifier (ROVR)

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

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

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

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 0x04 |Opt Length = 14| |P| | |A|       ...           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     +
                                  |4 бита |

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


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

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

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

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

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

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

Диапазон

Назначение

0

Безусловное восприятие

1-127

Непрямой отказ

128-255

Отказ

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

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

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

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


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

U

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

A

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

Status Value

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

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

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

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

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

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

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

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

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

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

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

  • Применение флага R расширяется на сообщения NA(EARO) для подтверждения установки маршрута.

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

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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

  2. 6LN получает глобальный адрес IPv6 через (1) автоматическую настройку без учёта состояния (SLAAC) [RFC4862] из опции PIO [RFC4861] в сообщении RA или (2) другим путём, например DHCPv6 [RFC8415].

  3. После получения адреса 6LN регистрирует его и периодически обновляет регистрацию заранее в течение срока действия предыдущей регистрации, как предписано [RFC6775], для обновления NCE до завершения срока действия, указанного в EARO. 6LN устанавливает (1) флаг T, как предписано в [RFC8505]. TID увеличивается каждый раз в соответствии с параграфом 5.2.1 в [RFC8505], что полностью совместимо с параграфом 7.2 в [RFC6550]).

  4. Как указано в параграфе 5.2 [RFC8505], 6LN может одновременно регистрировать несколько 6LR. В этом случае для всех полей в EARO устанавливаются одни значения для каждой параллельной регистрации адреса, за исключением поля Registration Lifetime и флага R, которые могут различаться. 6LN может отменить часть регистраций или перенести регистрацию с одних 6LR на другие. Для этого 6LN передаёт серию сообщений NS(EARO) с одинаковым TID, устанавливая Registration Lifetime = 0 для прежних 6LR и ненулевое значение для новых 6LR. В этом процессе узлу 6LN следует передавать NS(EARO) с ненулевым Registration Lifetime и убедиться, что хотя бы один раз был достигнут успех, прежде чем передавать NS(EARO) для прерывания другой регистрации. Это позволяет избежать оттока, связанного с временным аннулированием маршрута в сети RPL над общим родителем вовлечённых 6LR.

  5. В соответствии с параграфом 5.1 в [RFC8505] узел 6LN, действующий как RUL, устанавливает флаг R в EARO своих регистрация, для которых нужны услуги маршрутизации. Если флаг R не возвращается в NA, лист RUL должен считать, что организация маршрутов через данный 6LR привела к отказу и следует попытаться использовать другой 6LR. Листу RUL следует обеспечить успешное завершение регистрации до сброса флага R. В случае конфликта с предшествующим правилом по сроку действия, правило для срока имеет приоритет.

  6. 6LN может использовать любой из маршрутизаторов 6LR, где он зарегистрирован, в качестве принятого по умолчанию шлюза. Использование 6LR, на котором 6LN не зарегистрирован, может приводить к отбрасыванию пакетов в 6LR функцией проверки отправителя SAVI [RFC7039], поэтому не рекомендуется.

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

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

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

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

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

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

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

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

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

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

  1. Registered Address указывается как Target Prefix в обновлённой опции Target сообщения DAO с установкой Prefix Length = 128 и сбросом флага F, поскольку анонсирующий узел не является RUL. Поле ROVR копируется из EARO (6.1. Обновлённая опция RPL Target).

  2. 6LR указывает один из глобальных или локальной уникальных unicast-адресов IPv6 как Parent Address в опции TIO, связанной с опцией Target.

  3. 6LR устанавливает флаг E в TIO для индикации распространения внешнего маршрута в сеть RPL.

  4. Path Lifetime в TIO рассчитывается по Registration Lifetime в EARO с преобразованием секунд в единицы Lifetime Unit сети RPL. Это задаёт ограничение для развёртывания требованием совместимости Lifetime Unit с выражением Registration Lifetime, например, Lifetime Unit = 0x4000 отображает старший бит Registration Lifetime на Path Lifetime. Значение Path Lifetime должно обеспечить срок действия пути, не превышающий регистрацию и охватывающий время кругового обхода на пути к корню.

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

  5. В Path Sequence опции TIO устанавливается значение TID из EARO.

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

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

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

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

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

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

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

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

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


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

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

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

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

9.2.3. Корень RPL DODAG

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

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

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

  1. Целевой адрес IPv6 из опции RPL Target помещается в поле Registered Address сообщения EDAR.

  2. Значение Registration Lifetime преобразуется из Path Lifetime версии TIO в соответствии с Lifetime Unit в сети RPL и единицей 60 секунд а сообщениях 6LoWPAN ND.

  3. В поле TID устанавливается значение Path Sequence из TIO и указывается код ICMP 1 в сообщении EDAR.

  4. ROVR из опции RPL Target копируется в EDAR, а для ICMP Code Suffix устанавливается подходящее значение в соответствии с таблицей 4 в [RFC8505], в зависимости от размера поля ROVR.

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

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

9.2.4. 6LBR

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Номер бита

Описание

Документ

1

Root Proxies EDAR/EDAC (P)

RFC 9010

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

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

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

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

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

Номер бита

Описание

Документ

0

Advertiser address in Full (F)

RFC 9010

1

Proxy EDAR Requested (X)

RFC 9010

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

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

  • Положительные значения являются 6-битовыми целыми числами без знака (0..63).

  • Регистрация выполняется по процедуре IETF Review [RFC8126].

  • Начальное значение указано в таблице 4.

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

Значение

Описание

Документ

0

Успех, безусловное восприятие

RFC 6550 и RFC 9010

1 – 63

Не выделены

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

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

  • Положительные значения являются 6-битовыми целыми числами без знака (0..63).

  • Регистрация выполняется по процедуре IETF Review [RFC8126].

  • Начальные значения указаны в таблице 5.

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

Значение

Описание

Документ

0

Безусловный отказ

RFC 9010

1

Нет маршрутной записи

RFC 9009

2 – 63

Не выделены

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.

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

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

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

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

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


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

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

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

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

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

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

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

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

Cisco Systems, Inc.

Building D

45 Allee des Ormes – BP1200

06254 MOUGINS – Sophia Antipolis

France

Phone: +33 497 23 26 34

Email: pthubert@cisco.com

Michael C. Richardson

Sandelman Software Works

Email: mcr+ietf@sandelman.ca

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


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

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

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

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

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

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

Рубрика: RFC | Оставить комментарий

RFC 9009 Efficient Route Invalidation

image_print
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

Аннотация

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

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

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

Документ является результатом работы IETF3 и представляет согласованный взгляд сообщества IETF. Документ прошёл открытое обсуждение и был одобрен для публикации IESG4. Дополнительную информацию о стандартах 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 документа Trust Legal Provisions, без каких-либо гарантий (как указано в Simplified BSD License).

Оглавление

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

1. Введение

Протокол RPL5, определённый в [RFC6550], задаёт проактивную схему маршрутизации на основе вектора удалённости. RPL включает необязательные сообщения в форме DAO6, которые могут применять маршрутизаторы 6LBR7 и 6LR8 для изучения маршрутов к нисходящим узлам. 6LoWPAN является сокращением для IPv6 через беспроводные персональные сети с недостаточным электропитанием. В режиме сохранения (Storing) сообщения DAO приводят к созданию маршрутных записей на всех промежуточных 6LR от родительского узла ко всем 6LBR.

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

Этот документ относится лишь к режиму хранения RPL (Storing MOP9). Режим 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 путём включения флага аннулирования прежнего маршрута I10, который информирует общего предка о необходимости создать сообщение 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) EARO11 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 секунды и недопустимо использовать более трёх повторов.

Число повторов может также зависеть от критичности аннулирования маршрутов для сети и настройки повторов на канальном уровне. Для сетей, поддерживающих лишь потоки MP2P12 и P2MP13, таких как AMI14 и телеметрия, маршрутизаторы 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.

 

Код

Описание

Документ

0x07

Destination Cleanup Object

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

0x08

Destination Cleanup Object Acknowledgment

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

0x87

Secure Destination Cleanup Object

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

0x88

Secure Destination Cleanup Object Acknowledgment

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

 

Выделен также бит 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.

 

Номер бита

Описание

Документ

0

Запрос DCO-ACK (K)

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

1

Поле DODAGID присутствует (D)

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

 

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.

 

Номер бита

Описание

Документ

0

Поле DODAGID присутствует (D)

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

 

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

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

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

 

Значение

Смысл

Документ

1

Нет маршрутной записи

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

 

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 имеются защищённые варианты, обеспечивающие контроль целостности с использованием кодов MAC15 или подписей. Кроме того, для защищённых сообщений 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@protocols.ru

1No-Path Destination Advertisement Object – анонс отсутствия пути к адресату.

2Destination Cleanup Object – объект «очистки» адресата.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

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

6Destination Advertisement Object – объект анонсирования адресата.

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

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

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

10Invalidate previous route.

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

12Multi-Point to Point – множество с одним.

13Point-to-Multipoint – один со многими.

14Advanced Metering Infrastructure – расширенная инфраструктура измерений.

15Message Authentication Code – код проверки подлинности сообщения.

Рубрика: RFC | Оставить комментарий

RFC 8996 Deprecating TLS 1.0 and TLS 1.1

image_print
Internet Engineering Task Force (IETF)                       K. Moriarty
Request for Comments: 8996                                           CIS
BCP: 195                                                      S. Farrell
Obsoletes: 5469, 7507                             Trinity College Dublin
Updates: 3261, 3329, 3436, 3470, 3501, 3552,                  March 2021
         3568, 3656, 3749, 3767, 3856, 3871,                            
         3887, 3903, 3943, 3983, 4097, 4111,                            
         4162, 4168, 4217, 4235, 4261, 4279,                            
         4497, 4513, 4531, 4540, 4582, 4616,                            
         4642, 4680, 4681, 4712, 4732, 4743,                            
         4744, 4785, 4791, 4823, 4851, 4964,                            
         4975, 4976, 4992, 5018, 5019, 5023,                            
         5024, 5049, 5054, 5091, 5158, 5216,                            
         5238, 5263, 5281, 5364, 5415, 5422,                            
         5456, 5734, 5878, 5953, 6012, 6042,                            
         6083, 6084, 6176, 6347, 6353, 6367,                            
         6460, 6614, 6739, 6749, 6750, 7030,                            
         7465, 7525, 7562, 7568, 8261, 8422                             
Category: Best Current Practice                                         
ISSN: 2070-1721

Deprecating TLS 1.0 and TLS 1.1

Прекращение поддержки TLS 1.0 и TLS 1.1

PDF

Аннотация

Этот документ формально отменяет протокол TLS1 версии 1.0 (RFC 2246) и 1.1 (RFC 4346) с переводом упомянутых документов в статус Historic. В этих версиях отсутствует поддержка современных и рекомендуемых криптографических алгоритмов и механизмов, а различные правительственные и отраслевые профили приложений, использующих TLS, рекомендуют отказ от этих устаревших версий TLS. TLS версии 1.2 рекомендован для протоколов IETF с 2008 г., а в 2018 г. заменён TLS версии 1.3, что обеспечило достаточное для перехода к новым версиям время. Прекращение поддержки старых версий сокращает фронт атак, снижает вероятность неверной настройки и упрощает поддержку программ и библиотек.

Этот документ также отменяет DTLS2 версии 1.0 (RFC 4347), не отменяя DTLS версии 1.2 (DTLS версии 1.1 не существует).

Документ обновляет многие RFC, которые нормативно задавали применение TLS версии 1.0 или TLS версии 1.1, а также рекомендации по использованию TLS в RFC 7525 (следовательно, является частью BCP 195).

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

Документ относится к категории Internet Best Current Practice.

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

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

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

Авторские права (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).

Оглавление

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

1. Введение

Протоколы TLS версии 1.0 [RFC2246] и 1.1 [RFC4346] переопределены TLS 1.2 [RFC5246] в 2008 г., а этот протокол был переопределен TLS 1.3 [RFC8446]. Протокол DTLS версии 1.0 [RFC4347] переопределен DTLS 1.2 [RFC6347] в 2012 г. Пришло время отказаться от TLS 1.0, TLS 1.1 и DTLS 1.0 с переводом упомянутых документов в статус Historic.

Технические причины отказа от поддержки старых версий указаны ниже.

  • Протоколы требуют поддержки устаревших протоколов, которая нежелательна с точки зрения криптографии. Например, TLS 1.0 требует реализации TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.

  • Отсутствует поддержка рекомендуемых в настоящее время шифров, особенно аутентифицированного шифрования со связанными данными (AEAD5), которое не поддерживается до TLS 1.2. Отметим, что записи для устаревших шифров сохраняются в реестрах, но многие реестры TLS были обновлены [RFC8447], где указано, что эти записи не рекомендуются IETF.

  • Целостность согласования зависит от хэша SHA-1.

  • Проверка подлинности партнера зависит от подписей SHA-1.

  • Поддержка 4 версий протокола TLS повышает вероятность некорректной настройки.

  • По крайней мере одна из распространённых библиотек планирует отказ от поддержки TLS 1.1 и TLS 1.0 в будущих выпусках, поэтому программам, использующим библиотеки придётся сохранять старую версию для поддержки TLS 1.0 и TLS 1.1, что явно нежелательно.

Прекращение поддержки этих версий предназначено для оказания помощи разработчикам с целью перехода на новые версии (D)TLS, начиная с (D)TLS 1.2. Отмена также позволяет разработчикам прекратить поддержку устаревших версий для сужения фронта атак и объёма поддержки протоколов в своей продукции.

1.1. Обновлённые RFC

Этот документ обновляет перечисленные ниже RFC, в которых содержатся нормативные ссылки на TLS 1.0, TLS 1.1, DTLS 1.0. Обновление предназначено для отмены использования этих устаревших версий. Конкретные ссылки на обязательную для реализации минимальную версию протокола TLS 1.0 или TLS 1.1 заменены ссылками на TLS 1.2, а ссылки на DTLS 1.0 – ссылками на DTLS 1.2. Утверждения вида: «TLS 1.0 является наиболее широко распространённой версией» удалены без замены.

[RFC3261] [RFC3329] [RFC3436] [RFC3470] [RFC3501] [RFC3552] [RFC3568] [RFC3656] [RFC3749] [RFC3767] [RFC3856] [RFC3871] [RFC3887] [RFC3903] [RFC3943] [RFC3983] [RFC4097] [RFC4111] [RFC4162] [RFC4168] [RFC4217] [RFC4235] [RFC4261] [RFC4279] [RFC4497] [RFC4513] [RFC4531] [RFC4540] [RFC4582] [RFC4616] [RFC4642] [RFC4680] [RFC4681] [RFC4712] [RFC4732] [RFC4785] [RFC4791] [RFC4823] [RFC4851] [RFC4964] [RFC4975] [RFC4976] [RFC4992] [RFC5018] [RFC5019] [RFC5023] [RFC5024] [RFC5049] [RFC5054] [RFC5091] [RFC5158] [RFC5216] [RFC5238] [RFC5263] [RFC5281] [RFC5364] [RFC5415] [RFC5422] [RFC5456] [RFC5734] [RFC5878] [RFC6012] [RFC6042] [RFC6083] [RFC6084] [RFC6176] [RFC6353] [RFC6367] [RFC6739] [RFC6749] [RFC6750] [RFC7030] [RFC7465] [RFC7525] [RFC7562] [RFC7568] [RFC8261] [RFC8422]

Статус [RFC7562], [RFC6042], [RFC5456], [RFC5024], [RFC4540], [RFC3656] обновлён с разрешения Independent Submissions Editor.

RFC с нормативными ссылками на TLS 1.0 или TLS 1.1, которые устарели и указаны здесь как обновлённые данным документом, чтобы подчеркнуть, что взамен устаревшего протокола следует использовать современную версию TLS включают [RFC3316], [RFC3489], [RFC3546], [RFC3588], [RFC3734], [RFC3920], [RFC4132], [RFC4244], [RFC4347], [RFC4366], [RFC4492], [RFC4507], [RFC4572], [RFC4582], [RFC4934], [RFC5077], [RFC5081], [RFC5101], [RFC5953].

Документ [RFC4642] уже обновлён [RFC8143], но это обновление не идентично вносимому данным документом.

В [RFC6614] указано требование использовать TLS 1.1 и выше, но содержится лишь информационная ссылка на [RFC4346]. Это требование обновлено указанием TLS 1.2 или последующих версий.

[RFC6460], [RFC4744], [RFC4743] уже имеют статус Historic, но указаны здесь как обновлённые данным документом, чтобы подчеркнуть необходимость замены устаревших протоколов современными версиями TLS.

Этот документ обновляет DTLS [RFC6347], где разрешено согласование использования DTLS 1.0, отменённого здесь.

Шифры DES и IDEA6, заданные в [RFC5469], были удалены из TLS 1.2 документом [RFC5246], поскольку указанные для этих шифров версии TLS, переведены в статус Historic, как и [RFC5469].

Заданное для отката версии шифра Signaling Cipher Suite Value [RFC7507] было определено с целью обнаружения ситуаций, когда клиент и сервер согласуют версию (D)TLS ниже максимальной, поддерживаемой обоими. В TLS 1.3 ([RFC8446]) для этого применяется другой механизм на основе сторожевых значений в поле ServerHello.Random. Версии (D)TLS до 1.2 полностью отменены и единственным вариантом, которым реализации (D)TLS могут согласовать использование версии ниже максимальной для обоих, является согласование (D)TLS 1.2 при поддержке обоими (D)TLS 1.3, а использование (D)TLS 1.3 предполагает поддержку механизма ServerHello.Random. Это переопределяет функциональность [RFC7507] и документ получает статус Obsolete.

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

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

2. Поддержка отмены

Детали атак на TLS 1.0 и TLS 1.1, а также способы их предотвращения рассмотрены в [NIST800-52r2], [RFC7457] и упомянутых там RFC. Несмотря на разработку мер устранения известных уязвимостей, вновь обнаруживаемые проблемы старых версий протоколов не могут быть устранены в старых версиях библиотек, если новые библиотеки не поддерживают эти устаревшие протоколы.

Например, NIST предлагает приведённые ниже рекомендации (раздел 1.1 History of TLS в [NIST800-52r2]).

Протокол TLS 1.1, заданный в RFC 4346 [24], был разработан для устранения слабостей TLS 1.0, прежде всего в части выбора вектора инициализации и обработки ошибок заполнения. Векторы инициализации были сделаны явными для предотвращения определённого класса атак против режима CBC7, используемого TLS. Обработка ошибок заполнения была изменена так, чтобы ошибка считалась неверным кодом аутентификации сообщения, а не отказом при расшифровке. Кроме того, в TLS 1.1 RFC подтверждены атаки на режим CBC, основанные на времени расчёта кода MAC8. В спецификации TLS 1.1 указано, что для защиты от таких атак реализация должна обрабатывать записи независимо от наличия ошибок заполнения. Дополнительные проблемы реализации режимов CBC (не включённые в RFC 4346 [24]), рассмотрены в параграфе 3.3.2.

Протокол TLS 1.2, заданный в RFC 5246 [25], внёс несколько криптографических улучшений, особенно в сфере функций хэширования, с возможностью использовать или задавать семейство алгоритмов SHA-2 для хэширования и расчётов MAC и PRF9. В TLS 1.2 также добавлены шифры AEAD.

Протокол TLS 1.3, заданный в RFC 8446 [57], существенно меняет TLS с целью устранения угроз, обнаруженных в последние годы. Изменения включают новый протокол согласования, новый процесс вывода ключей с использованием функции HKDF10 [37], а также исключение шифров, использующих транспорт ключей RSA или статический обмен DH (Diffie-Hellman), режимов работы CBC и SHA-1. Многие расширения, заданные для TLS 1.2 и предшествующих версий, не могут применяться с TLS 1.3.

3. SHA-1 как проблема TLS 1.0 и TLS 1.1

Целостность TLS 1.0 и TLS 1.1 зависит от хэширования SHA-1 при обмене сообщениями. Это позволяет организовать «атаку с понижением» на процесс согласования злоумышленнику, способному выполнить 277 операций, что гораздо ниже доступных в настоящее время возможностей.

Точно так же аутентификация при согласовании зависит от подписей с использованием хэширования SHA-1 или конкатенации хэш-значений MD5 и SHA-1, которая не намного сильней SHA-1, что позволяет атакующему представиться сервером при успешном взломе слабого хэша SHA-1.

Протоколы TLS 1.0 и TLS 1.1 не позволяют партнёрам выбрать более строгое хэширование подписей в сообщениях ServerKeyExchange и CertificateVerify, доступное лишь при переходе на новые версии протокола.

Дополнительная информация представлена в [Bhargavan2016].

4. Отказ от TLS 1.0

Использование TLS 1.0 недопустимо. Согласование TLS 1.0 из любой версии TLS недопустимо.

Все версии TLS более защищены, нежели TLS 1.0. Хотя в TLS 1.0 можно настроить предотвращение некоторых типов перехвата, предпочтительней использовать старшую из доступных версий.

На практике клиентам недопустимо передавать ClientHello с ClientHello.client_version {03,01}, а серверам недопустимо передавать ServerHello с ServerHello.server_version {03,01}. Любая сторона, получившая сообщение Hello с версией протокола {03,01}, должна ответить сообщением protocol_version и разорвать соединение.

Исторически в спецификациях TLS не было чёткого указания номера версии уровня записи (TLSPlaintext.version) в сообщении ClientHello. Приложение E в [RFC5246] указывает, что TLSPlaintext.version можно выбирать для максимальной совместимости, хотя не было определено «идеального» значения. Эта рекомендация сохраняется, поэтому серверы TLS должны воспринимать любое значение {03,XX} (включая {03,00}) как номер версии для уровня записи в ClientHello, но согласование TLS 1.0 недопустимо.

5. Отказ от TLS 1.1

Использование TLS 1.1 недопустимо. Согласование TLS 1.1 из любой версии TLS недопустимо.

На практике клиентам недопустимо передавать ClientHello с ClientHello.client_version {03,02}, а серверам недопустимо передавать ServerHello с ServerHello.server_version {03,02}. Любая сторона, получившая сообщение Hello с версией протокола {03,02}, должна ответить сообщением protocol_version и разорвать соединение.

Все версии более новые версии TLS более защищены, нежели TLS 1.1. Хотя в TLS 1.1 можно настроить предотвращение некоторых типов перехвата, предпочтительней использовать старшую из доступных версий. Поддержка TLS 1.1 в библиотеках сокращается и это будет влиять на безопасность в будущем, если меры противодействия атакам не будут реализованы в старых библиотеках.

Исторически в спецификациях TLS не было чёткого указания номера версии уровня записи (TLSPlaintext.version) в сообщении ClientHello. Приложение E в [RFC5246] указывает, что TLSPlaintext.version можно выбирать для максимальной совместимости, хотя не было определено «идеального» значения. Эта рекомендация сохраняется, поэтому серверы TLS должны воспринимать любое значение {03,XX} (включая {03,00}) как номер версии для уровня записи в ClientHello, но согласование TLS 1.1 недопустимо.

6. Обновление RFC 7525

Документ Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) [RFC7525] является BCP 195 – самым свежим в категории Best Current Practice для реализации TLS – и основан на TLS 1.2. В момент публикации документа TLS 1.0 и TLS 1.1 ещё не считались устаревшими. Поэтому здесь BCP 195 упоминается специально для обновления текста рекомендациями этого документа по прекращению поддержки.

Этот документ обновляет параграф 3.1.1 [RFC7525] заменой не следует на недопустимо, как указано ниже.

  • Реализациям недопустимо согласовывать TLS версии 1.0 [RFC2246].

    Обоснование. Протокол TLS 1.0 (1999 г.) не поддерживает многие современные строгие шифры. Кроме того, в TLS 1.0 отсутствует вектор инициализации (Initialization Vector или IV) для шифров CBC и не выдаются предупреждения при ошибках заполнения.

  • Реализациям недопустимо согласовывать TLS версии 1.1 [RFC4346].

    Обоснование. Протокол TLS 1.1 (2006 г.) улучшает защиту по сравнению с TLS 1.0, но не поддерживает некоторые современные и более строгие шифры.

Этот документ обновляет параграф 3.1.2 [RFC7525] заменой не следует на недопустимо и добавлением ссылки на RFC 6347, как указано ниже.

  • Реализациям недопустимо согласовывать DTLS версии 1.0 [RFC4347] [RFC6347].

    Версия 1.0 протокола DTLS соответствует версии 1.1 протокола TLS (см. выше).

7. Вопросы эксплуатации

Этот документ является частью BCP 195 и в этом качестве отражает представление IETF (на момент публикации этого документа) в части опыта применения TLS и DTLS.

Хотя протокол TLS 1.1 устарел с момента публикации [RFC5246] в 2008 г., а DTLS 1.0 устарел с момента публикации [RFC6347] в 2012 г., ещё могут оставаться системы, не поддерживающие (D)TLS 1.2 и выше. Принятие рекомендаций этого документа для всех систем, которым нужно взаимодействовать с вышеупомянутыми системами, будет приводить к отказам. Однако игнорирование рекомендаций для сохранения взаимодействия сопряжено с риском. Характер возникающих рисков рассмотрен в разделах 2 и 3, а сведения о рисках следует учитывать вместе с информацией об их смягчении при решении вопроса об обновлении систем в свете рекомендаций этого документа.

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

Этот документ отменяет поддержку двух устаревших версий протокола TLS и одной устаревшей версии DTLS по описанным выще соображениям безопасности. Фронт возможных атак сужается за счет уменьшения числа поддерживаемых протоколов и возможностей отката к старым версиям.

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

Этот документ не требует действий со стороны IANA.

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

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

[RFC2246] Dierks, T. and C. Allen, “The TLS Protocol Version 1.0”, RFC 2246, DOI 10.17487/RFC2246, January 1999, <https://www.rfc-editor.org/info/rfc2246>.

[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, DOI 10.17487/RFC3261, June 2002, <https://www.rfc-editor.org/info/rfc3261>.

[RFC3329] Arkko, J., Torvinen, V., Camarillo, G., Niemi, A., and T. Haukka, “Security Mechanism Agreement for the Session Initiation Protocol (SIP)”, RFC 3329, DOI 10.17487/RFC3329, January 2003, <https://www.rfc-editor.org/info/rfc3329>.

[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, “Transport Layer Security over Stream Control Transmission Protocol”, RFC 3436, DOI 10.17487/RFC3436, December 2002, <https://www.rfc-editor.org/info/rfc3436>.

[RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, “Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols”, BCP 70, RFC 3470, DOI 10.17487/RFC3470, January 2003, <https://www.rfc-editor.org/info/rfc3470>.

[RFC3501] Crispin, M., “INTERNET MESSAGE ACCESS PROTOCOL — VERSION 4rev1”, RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.

[RFC3552] Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations”, BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.

[RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, “Known Content Network (CN) Request-Routing Mechanisms”, RFC 3568, DOI 10.17487/RFC3568, July 2003, <https://www.rfc-editor.org/info/rfc3568>.

[RFC3656] Siemborski, R., “The Mailbox Update (MUPDATE) Distributed Mailbox Database Protocol”, RFC 3656, DOI 10.17487/RFC3656, December 2003, <https://www.rfc-editor.org/info/rfc3656>.

[RFC3749] Hollenbeck, S., “Transport Layer Security Protocol Compression Methods”, RFC 3749, DOI 10.17487/RFC3749, May 2004, <https://www.rfc-editor.org/info/rfc3749>.

[RFC3767] Farrell, S., Ed., “Securely Available Credentials Protocol”, RFC 3767, DOI 10.17487/RFC3767, June 2004, <https://www.rfc-editor.org/info/rfc3767>.

[RFC3856] Rosenberg, J., “A Presence Event Package for the Session Initiation Protocol (SIP)”, RFC 3856, DOI 10.17487/RFC3856, August 2004, <https://www.rfc-editor.org/info/rfc3856>.

[RFC3871] Jones, G., Ed., “Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure”, RFC 3871, DOI 10.17487/RFC3871, September 2004, <https://www.rfc-editor.org/info/rfc3871>.

[RFC3887] Hansen, T., “Message Tracking Query Protocol”, RFC 3887, DOI 10.17487/RFC3887, September 2004, <https://www.rfc-editor.org/info/rfc3887>.

[RFC3903] Niemi, A., Ed., “Session Initiation Protocol (SIP) Extension for Event State Publication”, RFC 3903, DOI 10.17487/RFC3903, October 2004, <https://www.rfc-editor.org/info/rfc3903>.

[RFC3943] Friend, R., “Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)”, RFC 3943, DOI 10.17487/RFC3943, November 2004, <https://www.rfc-editor.org/info/rfc3943>.

[RFC3983] Newton, A. and M. Sanz, “Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)”, RFC 3983, DOI 10.17487/RFC3983, January 2005, <https://www.rfc-editor.org/info/rfc3983>.

[RFC4097] Barnes, M., Ed., “Middlebox Communications (MIDCOM) Protocol Evaluation”, RFC 4097, DOI 10.17487/RFC4097, June 2005, <https://www.rfc-editor.org/info/rfc4097>.

[RFC4111] Fang, L., Ed., “Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)”, RFC 4111, DOI 10.17487/RFC4111, July 2005, <https://www.rfc-editor.org/info/rfc4111>.

[RFC4162] Lee, H.J., Yoon, J.H., and J.I. Lee, “Addition of SEED Cipher Suites to Transport Layer Security (TLS)”, RFC 4162, DOI 10.17487/RFC4162, August 2005, <https://www.rfc-editor.org/info/rfc4162>.

[RFC4168] Rosenberg, J., Schulzrinne, H., and G. Camarillo, “The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)”, RFC 4168, DOI 10.17487/RFC4168, October 2005, <https://www.rfc-editor.org/info/rfc4168>.

[RFC4217] Ford-Hutchinson, P., “Securing FTP with TLS”, RFC 4217, DOI 10.17487/RFC4217, October 2005, <https://www.rfc-editor.org/info/rfc4217>.

[RFC4235] Rosenberg, J., Schulzrinne, H., and R. Mahy, Ed., “An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)”, RFC 4235, DOI 10.17487/RFC4235, November 2005, <https://www.rfc-editor.org/info/rfc4235>.

[RFC4261] Walker, J. and A. Kulkarni, Ed., “Common Open Policy Service (COPS) Over Transport Layer Security (TLS)”, RFC 4261, DOI 10.17487/RFC4261, December 2005, <https://www.rfc-editor.org/info/rfc4261>.

[RFC4279] Eronen, P., Ed. and H. Tschofenig, Ed., “Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)”, RFC 4279, DOI 10.17487/RFC4279, December 2005, <https://www.rfc-editor.org/info/rfc4279>.

[RFC4346] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1”, RFC 4346, DOI 10.17487/RFC4346, April 2006, <https://www.rfc-editor.org/info/rfc4346>.

[RFC4497] Elwell, J., Derks, F., Mourot, P., and O. Rousseau, “Interworking between the Session Initiation Protocol (SIP) and QSIG”, BCP 117, RFC 4497, DOI 10.17487/RFC4497, May 2006, <https://www.rfc-editor.org/info/rfc4497>.

[RFC4513] Harrison, R., Ed., “Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms”, RFC 4513, DOI 10.17487/RFC4513, June 2006, <https://www.rfc-editor.org/info/rfc4513>.

[RFC4531] Zeilenga, K., “Lightweight Directory Access Protocol (LDAP) Turn Operation”, RFC 4531, DOI 10.17487/RFC4531, June 2006, <https://www.rfc-editor.org/info/rfc4531>.

[RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, “NEC’s Simple Middlebox Configuration (SIMCO) Protocol Version 3.0”, RFC 4540, DOI 10.17487/RFC4540, May 2006, <https://www.rfc-editor.org/info/rfc4540>.

[RFC4582] Camarillo, G., Ott, J., and K. Drage, “The Binary Floor Control Protocol (BFCP)”, RFC 4582, DOI 10.17487/RFC4582, November 2006, <https://www.rfc-editor.org/info/rfc4582>.

[RFC4616] Zeilenga, K., Ed., “The PLAIN Simple Authentication and Security Layer (SASL) Mechanism”, RFC 4616, DOI 10.17487/RFC4616, August 2006, <https://www.rfc-editor.org/info/rfc4616>.

[RFC4642] Murchison, K., Vinocur, J., and C. Newman, “Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)”, RFC 4642, DOI 10.17487/RFC4642, October 2006, <https://www.rfc-editor.org/info/rfc4642>.

[RFC4680] Santesson, S., “TLS Handshake Message for Supplemental Data”, RFC 4680, DOI 10.17487/RFC4680, October 2006, <https://www.rfc-editor.org/info/rfc4680>.

[RFC4681] Santesson, S., Medvinsky, A., and J. Ball, “TLS User Mapping Extension”, RFC 4681, DOI 10.17487/RFC4681, October 2006, <https://www.rfc-editor.org/info/rfc4681>.

[RFC4712] Siddiqui, A., Romascanu, D., Golovinsky, E., Rahman, M., and Y. Kim, “Transport Mappings for Real-time Application Quality-of-Service Monitoring (RAQMON) Protocol Data Unit (PDU)”, RFC 4712, DOI 10.17487/RFC4712, October 2006, <https://www.rfc-editor.org/info/rfc4712>.

[RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, “Internet Denial-of-Service Considerations”, RFC 4732, DOI 10.17487/RFC4732, December 2006, <https://www.rfc-editor.org/info/rfc4732>.

[RFC4743] Goddard, T., “Using NETCONF over the Simple Object Access Protocol (SOAP)”, RFC 4743, DOI 10.17487/RFC4743, December 2006, <https://www.rfc-editor.org/info/rfc4743>.

[RFC4744] Lear, E. and K. Crozier, “Using the NETCONF Protocol over the Blocks Extensible Exchange Protocol (BEEP)”, RFC 4744, DOI 10.17487/RFC4744, December 2006, <https://www.rfc-editor.org/info/rfc4744>.

[RFC4785] Blumenthal, U. and P. Goel, “Pre-Shared Key (PSK) Ciphersuites with NULL Encryption for Transport Layer Security (TLS)”, RFC 4785, DOI 10.17487/RFC4785, January 2007, <https://www.rfc-editor.org/info/rfc4785>.

[RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault, “Calendaring Extensions to WebDAV (CalDAV)”, RFC 4791, DOI 10.17487/RFC4791, March 2007, <https://www.rfc-editor.org/info/rfc4791>.

[RFC4823] Harding, T. and R. Scott, “FTP Transport for Secure Peer-to-Peer Business Data Interchange over the Internet”, RFC 4823, DOI 10.17487/RFC4823, April 2007, <https://www.rfc-editor.org/info/rfc4823>.

[RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, “The Flexible Authentication via Secure Tunneling Extensible Authentication Protocol Method (EAP-FAST)”, RFC 4851, DOI 10.17487/RFC4851, May 2007, <https://www.rfc-editor.org/info/rfc4851>.

[RFC4964] Allen, A., Ed., Holm, J., and T. Hallin, “The P-Answer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to Talk over Cellular”, RFC 4964, DOI 10.17487/RFC4964, September 2007, <https://www.rfc-editor.org/info/rfc4964>.

[RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., “The Message Session Relay Protocol (MSRP)”, RFC 4975, DOI 10.17487/RFC4975, September 2007, <https://www.rfc-editor.org/info/rfc4975>.

[RFC4976] Jennings, C., Mahy, R., and A. B. Roach, “Relay Extensions for the Message Sessions Relay Protocol (MSRP)”, RFC 4976, DOI 10.17487/RFC4976, September 2007, <https://www.rfc-editor.org/info/rfc4976>.

[RFC4992] Newton, A., “XML Pipelining with Chunks for the Internet Registry Information Service”, RFC 4992, DOI 10.17487/RFC4992, August 2007, <https://www.rfc-editor.org/info/rfc4992>.

[RFC5018] Camarillo, G., “Connection Establishment in the Binary Floor Control Protocol (BFCP)”, RFC 5018, DOI 10.17487/RFC5018, September 2007, <https://www.rfc-editor.org/info/rfc5018>.

[RFC5019] Deacon, A. and R. Hurst, “The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments”, RFC 5019, DOI 10.17487/RFC5019, September 2007, <https://www.rfc-editor.org/info/rfc5019>.

[RFC5023] Gregorio, J., Ed. and B. de hOra, Ed., “The Atom Publishing Protocol”, RFC 5023, DOI 10.17487/RFC5023, October 2007, <https://www.rfc-editor.org/info/rfc5023>.

[RFC5024] Friend, I., “ODETTE File Transfer Protocol 2.0”, RFC 5024, DOI 10.17487/RFC5024, November 2007, <https://www.rfc-editor.org/info/rfc5024>.

[RFC5049] Bormann, C., Liu, Z., Price, R., and G. Camarillo, Ed., “Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)”, RFC 5049, DOI 10.17487/RFC5049, December 2007, <https://www.rfc-editor.org/info/rfc5049>.

[RFC5054] Taylor, D., Wu, T., Mavrogiannopoulos, N., and T. Perrin, “Using the Secure Remote Password (SRP) Protocol for TLS Authentication”, RFC 5054, DOI 10.17487/RFC5054, November 2007, <https://www.rfc-editor.org/info/rfc5054>.

[RFC5091] Boyen, X. and L. Martin, “Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems”, RFC 5091, DOI 10.17487/RFC5091, December 2007, <https://www.rfc-editor.org/info/rfc5091>.

[RFC5158] Huston, G., “6to4 Reverse DNS Delegation Specification”, RFC 5158, DOI 10.17487/RFC5158, March 2008, <https://www.rfc-editor.org/info/rfc5158>.

[RFC5216] Simon, D., Aboba, B., and R. Hurst, “The EAP-TLS Authentication Protocol”, RFC 5216, DOI 10.17487/RFC5216, March 2008, <https://www.rfc-editor.org/info/rfc5216>.

[RFC5238] Phelan, T., “Datagram Transport Layer Security (DTLS) over the Datagram Congestion Control Protocol (DCCP)”, RFC 5238, DOI 10.17487/RFC5238, May 2008, <https://www.rfc-editor.org/info/rfc5238>.

[RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. Khartabil, “Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information”, RFC 5263, DOI 10.17487/RFC5263, September 2008, <https://www.rfc-editor.org/info/rfc5263>.

[RFC5281] Funk, P. and S. Blake-Wilson, “Extensible Authentication Protocol Tunneled Transport Layer Security Authenticated Protocol Version 0 (EAP-TTLSv0)”, RFC 5281, DOI 10.17487/RFC5281, August 2008, <https://www.rfc-editor.org/info/rfc5281>.

[RFC5364] Garcia-Martin, M. and G. Camarillo, “Extensible Markup Language (XML) Format Extension for Representing Copy Control Attributes in Resource Lists”, RFC 5364, DOI 10.17487/RFC5364, October 2008, <https://www.rfc-editor.org/info/rfc5364>.

[RFC5422] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, “Dynamic Provisioning Using Flexible Authentication via Secure Tunneling Extensible Authentication Protocol (EAP-FAST)”, RFC 5422, DOI 10.17487/RFC5422, March 2009, <https://www.rfc-editor.org/info/rfc5422>.

[RFC5469] Eronen, P., Ed., “DES and IDEA Cipher Suites for Transport Layer Security (TLS)”, RFC 5469, DOI 10.17487/RFC5469, February 2009, <https://www.rfc-editor.org/info/rfc5469>.

[RFC5734] Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Transport over TCP”, STD 69, RFC 5734, DOI 10.17487/RFC5734, August 2009, <https://www.rfc-editor.org/info/rfc5734>.

[RFC5878] Brown, M. and R. Housley, “Transport Layer Security (TLS) Authorization Extensions”, RFC 5878, DOI 10.17487/RFC5878, May 2010, <https://www.rfc-editor.org/info/rfc5878>.

[RFC5953] Hardaker, W., “Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)”, RFC 5953, DOI 10.17487/RFC5953, August 2010, <https://www.rfc-editor.org/info/rfc5953>.

[RFC6042] Keromytis, A., “Transport Layer Security (TLS) Authorization Using KeyNote”, RFC 6042, DOI 10.17487/RFC6042, October 2010, <https://www.rfc-editor.org/info/rfc6042>.

[RFC6176] Turner, S. and T. Polk, “Prohibiting Secure Sockets Layer (SSL) Version 2.0”, RFC 6176, DOI 10.17487/RFC6176, March 2011, <https://www.rfc-editor.org/info/rfc6176>.

[RFC6353] Hardaker, W., “Transport Layer Security (TLS) Transport Model for the Simple Network Management Protocol (SNMP)”, STD 78, RFC 6353, DOI 10.17487/RFC6353, July 2011, <https://www.rfc-editor.org/info/rfc6353>.

[RFC6367] Kanno, S. and M. Kanda, “Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)”, RFC 6367, DOI 10.17487/RFC6367, September 2011, <https://www.rfc-editor.org/info/rfc6367>.

[RFC6739] Schulzrinne, H. and H. Tschofenig, “Synchronizing Service Boundaries and <mapping> Elements Based on the Location-to-Service Translation (LoST) Protocol”, RFC 6739, DOI 10.17487/RFC6739, October 2012, <https://www.rfc-editor.org/info/rfc6739>.

[RFC6749] Hardt, D., Ed., “The OAuth 2.0 Authorization Framework”, RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.

[RFC6750] Jones, M. and D. Hardt, “The OAuth 2.0 Authorization Framework: Bearer Token Usage”, RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/info/rfc6750>.

[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., “Enrollment over Secure Transport”, RFC 7030, DOI 10.17487/RFC7030, October 2013, <https://www.rfc-editor.org/info/rfc7030>.

[RFC7465] Popov, A., “Prohibiting RC4 Cipher Suites”, RFC 7465, DOI 10.17487/RFC7465, February 2015, <https://www.rfc-editor.org/info/rfc7465>.

[RFC7507] Moeller, B. and A. Langley, “TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks”, RFC 7507, DOI 10.17487/RFC7507, April 2015, <https://www.rfc-editor.org/info/rfc7507>.

[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, “Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”, BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.

[RFC7562] Thakore, D., “Transport Layer Security (TLS) Authorization Using Digital Transmission Content Protection (DTCP) Certificates”, RFC 7562, DOI 10.17487/RFC7562, July 2015, <https://www.rfc-editor.org/info/rfc7562>.

[RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, “Deprecating Secure Sockets Layer Version 3.0”, RFC 7568, DOI 10.17487/RFC7568, June 2015, <https://www.rfc-editor.org/info/rfc7568>.

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

[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier”, RFC 8422, DOI 10.17487/RFC8422, August 2018, <https://www.rfc-editor.org/info/rfc8422>.

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

[Bhargavan2016] Bhargavan, K. and G. Leuren, “Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH”, DOI 10.14722/ndss.2016.23418, February 2016, <https://www.mitls.org/downloads/transcript-collisions.pdf>.

[NIST800-52r2] National Institute of Standards and Technology, “Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations NIST SP800-52r2”, DOI 10.6028/NIST.SP.800-52r2, August 2019, <https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r2.pdf>.

[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, “Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts”, RFC 3316, DOI 10.17487/RFC3316, April 2003, <https://www.rfc-editor.org/info/rfc3316>.

[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, “STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)”, RFC 3489, DOI 10.17487/RFC3489, March 2003, <https://www.rfc-editor.org/info/rfc3489>.

[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, “Transport Layer Security (TLS) Extensions”, RFC 3546, DOI 10.17487/RFC3546, June 2003, <https://www.rfc-editor.org/info/rfc3546>.

[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol”, RFC 3588, DOI 10.17487/RFC3588, September 2003, <https://www.rfc-editor.org/info/rfc3588>.

[RFC3734] Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Transport Over TCP”, RFC 3734, DOI 10.17487/RFC3734, March 2004, <https://www.rfc-editor.org/info/rfc3734>.

[RFC3920] Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core”, RFC 3920, DOI 10.17487/RFC3920, October 2004, <https://www.rfc-editor.org/info/rfc3920>.

[RFC4132] Moriai, S., Kato, A., and M. Kanda, “Addition of Camellia Cipher Suites to Transport Layer Security (TLS)”, RFC 4132, DOI 10.17487/RFC4132, July 2005, <https://www.rfc-editor.org/info/rfc4132>.

[RFC4244] Barnes, M., Ed., “An Extension to the Session Initiation Protocol (SIP) for Request History Information”, RFC 4244, DOI 10.17487/RFC4244, November 2005, <https://www.rfc-editor.org/info/rfc4244>.

[RFC4347] Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security”, RFC 4347, DOI 10.17487/RFC4347, April 2006, <https://www.rfc-editor.org/info/rfc4347>.

[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, “Transport Layer Security (TLS) Extensions”, RFC 4366, DOI 10.17487/RFC4366, April 2006, <https://www.rfc-editor.org/info/rfc4366>.

[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. Moeller, “Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)”, RFC 4492, DOI 10.17487/RFC4492, May 2006, <https://www.rfc-editor.org/info/rfc4492>.

[RFC4507] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State”, RFC 4507, DOI 10.17487/RFC4507, May 2006, <https://www.rfc-editor.org/info/rfc4507>.

[RFC4572] Lennox, J., “Connection-Oriented Media Transport over the Transport Layer Security (TLS) Protocol in the Session Description Protocol (SDP)”, RFC 4572, DOI 10.17487/RFC4572, July 2006, <https://www.rfc-editor.org/info/rfc4572>.

[RFC4934] Hollenbeck, S., “Extensible Provisioning Protocol (EPP) Transport Over TCP”, RFC 4934, DOI 10.17487/RFC4934, May 2007, <https://www.rfc-editor.org/info/rfc4934>.

[RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, “Transport Layer Security (TLS) Session Resumption without Server-Side State”, RFC 5077, DOI 10.17487/RFC5077, January 2008, <https://www.rfc-editor.org/info/rfc5077>.

[RFC5081] Mavrogiannopoulos, N., “Using OpenPGP Keys for Transport Layer Security (TLS) Authentication”, RFC 5081, DOI 10.17487/RFC5081, November 2007, <https://www.rfc-editor.org/info/rfc5081>.

[RFC5101] Claise, B., Ed., “Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information”, RFC 5101, DOI 10.17487/RFC5101, January 2008, <https://www.rfc-editor.org/info/rfc5101>.

[RFC5246] Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”, RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.

[RFC5415] Calhoun, P., Ed., Montemurro, M., Ed., and D. Stanley, Ed., “Control And Provisioning of Wireless Access Points (CAPWAP) Protocol Specification”, RFC 5415, DOI 10.17487/RFC5415, March 2009, <https://www.rfc-editor.org/info/rfc5415>.

[RFC5456] Spencer, M., Capouch, B., Guy, E., Ed., Miller, F., and K. Shumard, “IAX: Inter-Asterisk eXchange Version 2”, RFC 5456, DOI 10.17487/RFC5456, February 2010, <https://www.rfc-editor.org/info/rfc5456>.

[RFC6012] Salowey, J., Petch, T., Gerhards, R., and H. Feng, “Datagram Transport Layer Security (DTLS) Transport Mapping for Syslog”, RFC 6012, DOI 10.17487/RFC6012, October 2010, <https://www.rfc-editor.org/info/rfc6012>.

[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, “Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)”, RFC 6083, DOI 10.17487/RFC6083, January 2011, <https://www.rfc-editor.org/info/rfc6083>.

[RFC6084] Fu, X., Dickmann, C., and J. Crowcroft, “General Internet Signaling Transport (GIST) over Stream Control Transmission Protocol (SCTP) and Datagram Transport Layer Security (DTLS)”, RFC 6084, DOI 10.17487/RFC6084, January 2011, <https://www.rfc-editor.org/info/rfc6084>.

[RFC6347] Rescorla, E. and N. Modadugu, “Datagram Transport Layer Security Version 1.2”, RFC 6347, DOI 10.17487/RFC6347, January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[RFC6460] Salter, M. and R. Housley, “Suite B Profile for Transport Layer Security (TLS)”, RFC 6460, DOI 10.17487/RFC6460, January 2012, <https://www.rfc-editor.org/info/rfc6460>.

[RFC6614] Winter, S., McCauley, M., Venaas, S., and K. Wierenga, “Transport Layer Security (TLS) Encryption for RADIUS”, RFC 6614, DOI 10.17487/RFC6614, May 2012, <https://www.rfc-editor.org/info/rfc6614>.

[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, “Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)”, RFC 7457, DOI 10.17487/RFC7457, February 2015, <https://www.rfc-editor.org/info/rfc7457>.

[RFC8143] Elie, J., “Using Transport Layer Security (TLS) with Network News Transfer Protocol (NNTP)”, RFC 8143, DOI 10.17487/RFC8143, April 2017, <https://www.rfc-editor.org/info/rfc8143>.

[RFC8261] Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, “Datagram Transport Layer Security (DTLS) Encapsulation of SCTP Packets”, RFC 8261, DOI 10.17487/RFC8261, November 2017, <https://www.rfc-editor.org/info/rfc8261>.

[RFC8446] Rescorla, E., “The Transport Layer Security (TLS) Protocol Version 1.3”, RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8447] Salowey, J. and S. Turner, “IANA Registry Updates for TLS and DTLS”, RFC 8447, DOI 10.17487/RFC8447, August 2018, <https://www.rfc-editor.org/info/rfc8447>.

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

Спасибо всем, кто представил данные об использовании протоколов, а также рецензентам и тем, кто помог внести улучшения в документ, включая Michael Ackermann, David Benjamin, David Black, Deborah Brungard, Alan DeKok, Viktor Dukhovni, Julien Élie, Adrian Farrelll, Gary Gapinski, Alessandro Ghedini, Peter Gutmann, Jeremy Harris, Nick Hilliard, James Hodgkinson, Russ Housley, Hubert Kario, Benjamin Kaduk, John Klensin, Watson Ladd, Eliot Lear, Ted Lemon, John Mattsson, Keith Moore, Tom Petch, Eric Mill, Yoav Nir, Andrei Popov, Michael Richardson, Eric Rescorla, Rich Salz, Mohit Sethi, Yaron Sheffer, Rob Sayre, Robert Sparks, Barbara Stark, Martin Thomson, Sean Turner, Loganaden Velvindron, Jakub Wilk, Christopher Wood.

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

Kathleen Moriarty

Center for Internet Security (CIS)

East Greenbush, NY

United States of America

Email: Kathleen.Moriarty.ietf@gmail.com

Stephen Farrell

Trinity College Dublin

Dublin

2

Ireland

Phone: +353-1-896-2354

Email: stephen.farrell@cs.tcd.ie


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

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

nmalykh@protocols.ru

1Transport Layer Security – защита транспортного уровня.

2Datagram TLS – TLS для дейтаграмм.

3Internet Engineering Task Force.

4Internet Engineering Steering Group.

5Authenticated encryption with associated data.

6International Data Encryption Algorithm – международный алгоритм шифрования данных.

7Cipher Block Chaining – цепочка шифрованных блоков.

8Message authentication code – код проверки подлинности сообщения.

9Pseudorandom Function – псевдослучайная функция.

10HMAC-based Extract-and-Expand Key Derivation Function – функция вывода ключей на основе HMAC.

Рубрика: RFC | Оставить комментарий

setcap

image_print

SETCAP

PDF

Утилита для управления возможностями файлов в Linux.

Синтаксис

setcap [-q] [-n <rootuid>] [-v] {capabilities|-|-r} filename [ ... capabilitiesN fileN ]

Описание

Без опции -v (verify – проверка) setcap устанавливает указанные возможности для каждого файла, заданного параметром filename. Необязательный аргумент -n <rootuid> можно использовать для установки возможности, используемого лишь в пространстве имен пользователя, владеющего идентификатором root. Опция -v служит для проверки связывания указанных возможностей с файлом. При указании опций -v и -n проверяется также аргумент -n <rootuid>.

Возможности указываются с помощью cap_from_text, как описано ниже.

Функция cap_from_text() выделяет и инициализирует состояние возможности в рабочем хранилище. Функция устанавливает содержимое вновь созданного состояния возможности в соответствии с понятной человеку строкой символов в стиле языка C (nul-завершение), указанной buf_p и возращает указатель на созданное состояние.
Текстовое представление возможности состоит из одного или множества разделенных пробелами «слов», каждое из которых указывает те или иные операции из набора возможностей, которые включаются или отключаются после выполнения команды (по умолчанию все отключено).

Каждое слово представляет собой список разделенных запятыми имен возможностей (или all), за которым следует список действий. Список действий включает последовательность пар «оператор-флаги». Операторами могут служить =, + и -, а флагами – e, i и p. Регистр флагов имеет значение и они указывают группу (набор), к которой относятся возможности Effective, Inheritable (наследуется) и Permitted (разрешено), соответственно.

В списке имен регистр символов не учитывается. Специальное имя all указывает все возможности, что эквивалентно заданию полного списка возможностей. Безымянные возможности можно указывать номером. Это позволяет библиотеке libcap поддерживать возможности, которые еще не были выделены к моменту компиляции библиотеки.

Оператор = задает для указанного имени сначала сброс всех 3 параметров возможности, а затем их установку в соответствии с флагами (не обязательны для этого оператора). Например, all=p сбросит установку Effective и Inheritable для батарейного питания и установит Permitted, а cap_fowner=ep установит в Effective и Permitted возможности смены владельца файла (override-file-ownership) и сбросит их в Inheritable.

При указании первым оператора = без списка возможностей предполагается воздействие на все возможности (all). Например, варианты all=, =, и cap_chown,<every-other-capability>= будут эквивалентны.

Операторы + и требуют явного указания впереди списка возможностей, а после оператора – явных флагов. Оператор + включает все указанные в списке возможности в соответствии с флагами, а оператор отключает. Например, all+p включает для всех возможностей Permitted, а cap_fowner-i отключает override-file-ownership в группе Inheritable.

Список действий может включать множество пар «оператор-флаги», действия применяются слева направо. Например, cap_fowner+p-i эквивалентно cap_fowner+p cap_fowner-i, а cap_fowner+pe-i эквивалентно cap_fowner=+pe.

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

Специальная строка -r служит для удаления набора возможностей файла. Отметим, что установка пустого набора возможностей отличается от удаления набора. Пустой набор может использоваться для предотвращения исполнения файла с привилегиями, несмотря на то, что превалирующие наборы Ambient и Inheritable позволили бы это.

Флаг -q служит для сокращения выводимых программой сведений.

Список возможностей

Для выполнения проверки прав доступа в традиционных системах UNIX процессы делят на две категории – привилегированные (идентификатор эффективного пользователя равен 0, как у root), и непривилегированные (ID эффективного пользователя не равен 0). Для привилегированных процессов проверки прав в ядре не выполняются, а для не привилегированных процессов выполняется полная проверка на основе возможностей процесса (обычно, эффективные UID и GID, а также и список дополнительных групп).

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

CAP_AUDIT_CONTROL (2.6.11)

Включение и выключение аудит ядра, изменение фильтрующих правил аудита, чтение состояния аудита и фильтрующие правила.

CAP_AUDIT_READ (3.16)

Чтение протокола аудита через многоадресный сокет netlink.

CAP_AUDIT_WRITE (2.6.11)

Запись данных в журнал аудита ядра.

CAP_BLOCK_SUSPEND (3.5)

Возможности, которые могут приводить к блокированию приостановки системы (epoll  EPOLLWAKEUP, /proc/sys/wake_lock).

CAP_BPF (5.8)

Привилегированные операции BPF (bpf, bpf_helpers). Возможность добавлена в Linux 5.8 для разгрузки перегруженной возможности CAP_SYS_ADMIN.

CAP_CHECKOUT_RESTORE (5.9)

    • Обновление /proc/sys/kernel/ns_last_pid (pid_namespaces);
    • использование свойства set_tid в clone3;
    • чтение содержимого символьной ссылки /proc/[pid]/map_files для других процессов.

Возможность добавлена в Linux 5.9 для переноса функциональности checkpount/restote из CAP_SYS_ADMIN.

CAP_CHOWN

Произвольные изменения UID и GID для файлов.

CAP_DAC_OVERRIDE

Пропуск проверки доступа к файлу на чтение, запись и выполнение (DAC или discretionary access control – избирательный контроль доступа).

CAP_DAC_READ_SEARCH

    • Пропуск проверки доступа к файлу на чтение и к каталогу на чтение и выполнение (просмотр);
    • вызов open_by_handle_at;
    • использование linkat с флагом AT_EMPTY_PATH для создания ссылки на файл, заданным дескриптором.

AP_FOWNER

    • Пропуск проверки доступа для операций, которые обычно требуют совпадения UID файловой системы процесса и UID файла (например, chmod,  utime), исключая операции, охватываемые CAP_DAC_OVERRIDE и CAP_DAC_READ_SEARCH, системы процесса и UID файла (например, chmod  utime),  исключая операции, охватываемые CAP_DAC_OVERRIDE и CAP_DAC_READ_SEARCH;
    • изменение флагов inode (ioctl_iflags) у произвольных файлов;
    • установка списков контроля доступа (ACL) для произвольных файлов;
    • игнорирование закрепляющего бита при удалении файла;
    • установка O_NOATIME для произвольных файлов в open и fcntl.

CAP_FSETID

Позволяет не сбрасывать биты режима set-user-ID и set-group-ID при изменении файла любыми дополнительными GID вызывающего процесса.

CAP_IPC_LOCK

Блокировка памяти (mlock, mlockall, mmap, shmctl).

CAP_IPC_OWNER

Отмена проверки доступа для операций с объектами System V IPC.

CAP_KILL

ioctl с операцией KDSIGACCEPT.

CAP_LEASE

(2.4) Установка аренды для произвольных файлов (fcntl).

CAP_LINUX_IMMUTABLE

Установка флагов inode FS_APPEND_FL и FS_IMMUTABLE_FL (ioctl_iflags).

CAP_MAC_ADMIN

(2.6.25) Изменение MAC или состояния. Реализована в Smack Linux Security Module (LSM).

CAP_MAC_OVERRIDE

(2.6.25) Замещение мандатного контроля доступа (MAC). Реализована в Smack LSM.

CAP_MKNOD

(2.4) Создание специальных файлов с помощью mknod.

CAP_NET_ADMIN

Различные сетевые операции:

    • настройка интерфейса;
    • управление IP МСЭ, трансляцией адресов и ведением учёта;
    • изменение таблиц маршрутизации;
    • привязка к любому адресу для организации прозрачного прокси;
    • назначение типа обслуживания (TOS);
    • сброс статистики драйвера;
    • управление режимом захвата (promiscuous);
    • включение групповой рассылки (multicasting);
    • использование setsockopt для включения параметров сокета SO_DEBUG, SO_MARK, SO_PRIORITY (для приоритетов вне диапазона 0 – 6), SO_RCVBUFFORCE и SO_SNDBUFFORCE.

CAP_NET_BIND_SERVICE

Привязка сокета к привилегированным портам домена Internet (номера портов меньше 1024).

CAP_NET_BROADCAST

(не используется) Позволяет выполнять широковещание с сокета и прослушивание многоадресных рассылок.

CAP_NET_RAW

Использование сокетов RAW и PACKET и привязка к любому адресу для создания прозрачного прокси.

CAP_PERFMON (5.9)

Управление механизмами мониторига, включая:

    • вызов perf_event_open;
    • реализация операций BPF, влияющих на производительность.

Возможность добавлена в Linux 5.9 для разгрузки перегруженной возможности CAP_SYS_ADMIN.

CAP_SETGID

Произвольные действия с GID процесса и списком дополнительных GID, подмена GID при передаче возможностей сокета через доменные сокеты UNIX, запись отображения идентификатора пользователя в пользовательское пространство (user_namespaces).

CAP_SETFCAP

(2.6.24) Устанавливает произвольные возможности для файла.

CAP_SETPCAP

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

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

CAP_SETUID

Произвольные действия с UID процесса (setuid, setreuid, setresuid, setfsuid), подмена UID при передаче возможностей сокета через доменные сокеты UNIX, запись отображения идентификатора пользователя в пользовательское пространство (user_namespaces).

CAP_SYS_ADMIN

    • Управление системой, включая quotactl, mount, umount, swapon, swapoff, sethostname, setdomainname;
    • привилегированные операции syslog (начиная с Linux 2.6.37, для этих операций нужно использовать CAP_SYSLOG);
    • команды VM86_REQUEST_IRQ vm86;
    • функциональность checkpoint/restore, обеспечиваемая CAP_CHECKPOIBT_RESTORE (предпочтительна);
    • функциональность BPF, обеспечиваемая CAP_BPF (предпочтительна);
    • функциональность мониторинга производительности, обеспечиваемая CAP_PERFMON (предпочтительна);
    • операции IPC_SET и IPC_RMID над произвольными объектами System V IPC;
    • перезапись ограничения ресурса RLIMIT_NPROC;
    • операции над расширенными атрибутами trusted и security (xattr);
    • использование lookup_dcookie;
    • использование ioprio_set для назначения классов планирования ввода-вывода IOPRIO_CLASS_RT и (до Linux 2.6.25) IOPRIO_CLASS_IDLE;
    • подмена PID при передаче возможостей сокета через доменные сокеты UNIX;
    • превышение системного ограничения (/proc/sys/fs/file-max) на количество открытых файлов в системных
      вызовах, открывающих файлы (например, accept, execve, open, pipe);
    • использование флагов CLONE_*, создающих новые пространства имён с помощью clone и unshare
      (начиная с Linux 3.8 для создания пользовательских пространств никаких возможностей не требуется);
    • вызовы perf_event_open;
    • доступ к информации о привилегированном событии perf;
    • вызовы setns (требуется CAP_SYS_ADMIN в целевом пространстве имён);
    • вызовы fanotify_init;
    • привилегированные операции KEYCTL_CHOWN и KEYCTL_SETPERM в keyctl;
    • вызовы ptrace PTRACE_SECCOMP_GET_FILTER для получения дампа фильтров seccomp трассируемого;
    • операция MADV_HWPOISON в madvise;
    • использование TIOCSTI в ioctl для вставки символов во входную очередь терминала, отличного от управляющего терминала вызывающего;
    • устаревший системный вызов nfsservctl;
    • устаревший системный вызов bdflush;
    • привилегированные операции ioctl над блочными устройствами;
    • привилегированные операции ioctl над файловой системой;
    • привилегированные операции ioctl над устройством /dev/random (random);
    • установка фильтров seccomp без начальной установки атрибута потока no_new_privs;
    • изменение правил разрешения и запрета для групп управления устройствами;
    • операция ptrace PTRACE_SECCOMP_GET_FILTER для получения дампа фильтров seccomp трассируемого;
    • операция ptrace PTRACE_SETOPTIONS для приостановки защиты seccomp трассируемого (т. е., флаг PTRACE_O_SUSPEND_SECCOMP)
    • административные операции над многими драйверами устройств;
    • изменение значений приоритета autogroup путем записи в /proc/[pid]/autogroup.

CAP_SYS_BOOT

Использование reboot и kexec_load.

CAP_SYS_CHROOT

Использование chroot и смена примонтированных пространств имен с помощью setns.

CAP_SYS_MODULE

Загрузка и выгрузка модулей ядра (init_module и delete_module), в ядрах до версии 2.6.25 – отзыв возможностей из системного набора Bounded.

CAP_SYS_NICE

    • Снижение приоритета процесса (nice, setpriority) и изменение приоритета произвольных процессов;
    • задание политики планирования в реальном масштабе времени для вызывающего процесса, а также политики планирования и приоритетов для произвольных процессов (sched_setscheduler, sched_setparam, shed_setattr);
    • привязка к ЦП для произвольных процессов (sched_setaffinity);
    • назначение класса планирования ввода-вывода и приоритета для произвольных процессов (ioprio_set);
    • применение migrate_pages к произвольным процессам для их переноса на произвольные узлы;
    • применение move_pages к произвольным процессам;
    • использование флага MPOL_MF_MOVE_ALL в mbind и move_pages.

CAP_SYS_PACCT

Использование acct.

CAP_SYS_PTRACE

    • Трассировка любого процесса с помощью ptrace;
    • применение get_robust_list к произвольным процессам;
    • перенос данных в память произвольного процесса (или из нее) с помощью process_vm_readv и process_vm_writev;
    • изучение процессов с помощью kcmp.

CAP_SYS_RAWIO

  • Операции ввода-вывода из портов (iopl и ioperm);
  • доступ к /proc/kcore;
  • использование операции FIBMAP в ioctl(2);
  • создание устройств для доступа к специальным регистрам x86 (MSR, msr);
  • обновление /proc/sys/vm/mmap_min_addr;
  • отображение памяти по адресам меньше значения, заданного в /proc/sys/vm/mmap_min_addr;
  • отображение файлов в /proc/bus/pci;
  • доступ к /dev/mem и /dev/kmem;
  • выполнение различных команд устройств SCSI;
  • определённые операции с устройствами hpsa и cciss;
  • некоторые специальные операции с другими устройствами.

CAP_SYS_RESOURCE

  • Использование зарезервированного пространства файловых систем ext2;
  • вызовы ioctl, управляющие журналом ext3;
  • превышение ограничений дисковой квоты;
  • увеличение ограничений по ресурсам (setrlimit);
  • перезапись ограничений ресурсов RLIMIT_NPROC;
  • превышение максимального числа консолей при выделении консоли;
  • превышение максимального числа раскладок;
  • использование более 64hz прерывания из часов реального времени;
  • установка значения msg_qbytes очереди сообщений System V больше /proc/sys/kernel/msgmnb (msgop и msgctl);
  • разрешение RLIMIT_NOFILE ограничивать число файловых дескрипторов, передаваемых в обход, при передаче другому процессу через доменный сокет UNIX (unix);
  • переопределение /proc/sys/fs/pipe-size-max при назначении вместимости канала с помощью команды F_SETPIPE_SZ в fcntl;
  • использование F_SETPIPE_SZ для увеличения вместимости канала сверх /proc/sys/fs/pipe-max-size;
  • переопределение /proc/sys/fs/mqueue/queues_max, /proc/sys/fs/mqueue/msg_max, /proc/sys/fs/mqueue/msg-size_max при создании очередей сообщений POSIX (mq_overview);
  • операция prctl PR_SET_MM();
  • установка в /proc/[pid]/oom_score_adj значения меньше последнего, заданного процессом с помощью CAP_SYS_RESOURCE.

CAP_SYS_TIME

Настройка системных часов (settimeofday, stime, adjtimex) и часов реального времени (аппаратных).

CAP_SYS_TTY_CONFIG

Использование vhangup(2) и привилегированные операции ioctl с виртуальными терминалами.

CAP_SYSLOG (2.6.37)

Привилегированные операции syslog, просмотр адресов ядра в /proc  и  других  интерфейсах, когда значение /proc/sys/kernel/kptr_restrict = 1 (kptr_restrict в proc).

CAP_WAKE_ALARM (3.0)

Вызов чего-либо при пробуждении системы (установка таймеров CLOCK_REALTIME_ALARM и CLOCK_BOOTTIME_ALARM).

Группы (наборы) возможностей потока

Каждый поток (нить) имеет несколько групп (наборов) возможностей из числа перечисленных выше. Группа может быть пустой.

Permitted – разрешенные возможности

Ограничивающее надмножество набора Effective с возможностями, которые поток может предполагать. Этот набор также ограничивает список возможностей, которые могут быть добавлены в наследуемый набор потоком без CAP_SETPCAP в своём наборе Effective.

Если поток отменяет возможность в своем наборе Permitted, он не сможет вернуть ее (без вызова execve из программы с set-user-ID-root или программы, чьи возможности для файла позволяют это).

Inheritable – наследуемые возможности

Этот набор возможностей, сохраняемых при вызове execve. Наследуемые возможности остаются таковыми при выполнении любой программы и добавляются в набор Permitted, если у выполняющейся программы установлены соответствующие биты в наследуемом наборе для файлов.

Поскольку наследуемые возможности обычно не сохраняются после execve, если выполнение происходит не от суперпользователя, приложениям, которым нужно выполнять вспомогательные программы с расширенными возможностями, нужно применять внешние возможности (Ambient), описанные ниже.

Bounding

(на уровне потока, начиная с Linux 2.6.25) Механизм, который может использоваться для ограничения возможностей, предоставляемых вызовом execve.

Начиная с Linux 2.6.25, этот набор задается на уровне потока, а в более ранних версиях это атрибут системы для всех потоков.

Effective

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

Ambient – внешние (охватывающие) возможности

(начиная с Linux 4.3) Набор возможностей, сохраняемый после execve для непривилегированных программ. Для набора внешних возможностей соблюдается правило, в соответствии с которым возможность не может  быть внешней, если она не входит в оба набора Permitted и Inheritable.

Набор внешних возможностей можно изменять с помощью prctl. Этот набор автоматически сужается при сужении соответствующего набора Permitted и Inheritable.

Выполнение программы, меняющей UID или GUI из-за установленного бита set-user-ID или set-group-ID, а также програмы, которая может устанавливать возможности для файла, сбрасывает набор Ambient. Внешние возможности добавляются к набору Permitted и назначаются набору Effective при вызове execve. Если внешние возможности расширяют набор Permitted или Effective при вызове execve, это не вызывает режим защищенного исполнения (secure-execution), описанный в ld.so.

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

Поток может менять свои возможности с помощью capset.

Начиная с версии 2.6.24 файл /proc/sys/kernel/cap_last_cap показывает максимальное численное значение возможностей, поддерживаемых работающим ядром. Это позволяет определить старший бит, который можно установить в наборе возможностей.

Возможности для файлов

Начиная с ядра 2.6.24 поддерживается связывание наборов возможностей с исполняемым файлом с помощью утилиты setcap. Наборы возможностей хранятся в расширенном атрибуте (setxattr, xattr) с именем security.capability. Для записи в этот атрибут требуется возможность CAP_SETFCAP. Наборы возможностей файла вместе с наборами возможностей потока определяют реальные возможности потока после вызова execve.

Для файла поддерживатся три набора возможностей.

Permitted (ранее forced)

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

Inheritable (ранее allowed)

Пересечение (AND) этого набора с набром наследуемых потоком возможностей определяет для потока набор Permitted после вызова execve.

Effective

По сути, это не набор возможностей, а просто бит, при установке которого вызов execve переносит все вновь разрешенные для потока возможности в новый набор Effective. При сброшенном бите ни одна из вновь разрешенных вызовом execve возможностей потока не присутствует в новом наборе Effective.

Установка бита предполагает, что любая из возможностей Effective или Inheritable для файла, которая заставляет поток обретать соответствующую возможность Permitted в результате вызова execve (Правила преобразования), также будет включена в набор Effective. Поэтому при включении возможности для файла (setcap, cap_set_file, cap_set_fd) установка бита Effective для любой возможности должна сопровождаться установкой этого флага для всех других возможностей, где установлен флаг Permitted или Inheritable.

Правила преобразования

При выполнении execve ядро рассчитывает новые возможности процесса, как показано ниже.

P'(ambient)     = (файл привилегированный) ? 0 : P(ambient)
P'(permitted)   = (P(inheritable) & F(inheritable)) | (F(permitted) & P(bounding)) | P'(ambient)
P'(effective)   = F(effective) ? P'(permitted) : P'(ambient)
P'(inheritable) = P(inheritable)    [>т. е. не меняется]
P'(bounding)    = P(bounding)       [т. е. не меняется]

где P() указывает значение возможности потока до вызова execve, P'() – возможности после вызова, F() – набор возможностей для файла.

Отметим некоторые детали, относящиеся к правилам преобразования возможностей:

  • набор Ambient появился лишь в Linux 4.3 и при преобразовании набора внешних возможностей в процессе execve привилегированным считается файл, имеющий возможности или установленный бит set-user-ID или set-group-ID bit set;

  • до Linux 2.6.25 набор Bounding был системным атрибутом для всех потоков и это значение использовалось для расчетов при вызове execve как P(bounding).

Отметим, что при описанном выше преобразовании возможности файла можно игнорировать (считать пустыми) по тем же причинам, которые служат для игнорирования битов set-user-ID и set-group-ID. Возможности файлов игнорируются при загрузке ядра с опцией no_file_caps option.

Текст подготовлен на основании материалов man из Mageia 8.

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

nmalykh@protocols.ru

Рубрика: Linux | Комментарии к записи setcap отключены

RFC 8972 Simple Two-Way Active Measurement Protocol Optional Extensions

image_print
Internet Engineering Task Force (IETF)                         G. Mirsky
Request for Comments: 8972                                        X. Min
Updates: 8762                                                  ZTE Corp.
Category: Standards Track                                      H. Nydell
ISSN: 2070-1721                                        Accedian Networks
                                                                R. Foote
                                                                   Nokia
                                                             A. Masputra
                                                              Apple Inc.
                                                              E. Ruffini
                                                                  OutSys
                                                            January 2021

Simple Two-Way Active Measurement Protocol Optional Extensions

Необязательные расширения протокола STAMP

PDF

Аннотация

Этот документ описывает необязательные расширения для протокола STAMP), позволяющего измерять параметры производительности. Документ также определяет идентификатор тестовой сессии (STAMP Test Session Identifier) обновляя тем самым RFC 8762.

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

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

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

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

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

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

Оглавление

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

1. Введение

Простой протокол активных двухсторонних измерений (Simple Two-way Active Measurement Protocol или STAMP) [RFC8762] задает базовую функциональность STAMP. В этом документе описаны необязательные расширения, использующие кодирование TLV. Такие расширения дополняют базовые функции STAMP, такие как измерение односторонней или круговой задержки, задержки при обработке, потери пакетов, их дублирование и нарушение порядка доставки. Спецификация определяет необязательные расширения STAMP, их формат и теорию работы. Определен также идентификатор тестовых сессий (STAMP Test Session Identifier) в качестве обновления [RFC8762].

2. Используемые соглашения

2.1. Сокращения

BDS

BeiDou Navigation Satellite System (навигационная система BeiDou).

BITS

Building Integrated Timing Supply (устройство синхронизации здания).

CoS

Class of Service (класс обслуживания).

DSCP

Differentiated Services Code Point (код дифференцированного обслуживания).

ECN

Explicit Congestion Notification (явное увкдомление о перегрузке).

GLONASS

Global Orbiting Navigation Satellite System (глобальная орбитальная спутниковая система навигации).

GPS

Global Positioning System (глобальная система позиционирования) [GPS].

HMAC

Hashed Message Authentication Code (хэшированный код аутентификации сообщения).

LORAN-C

Long Range Navigation System Version C (система навигации дальнего действия, версия C).

MBZ

Must be Zero (должно быть 0).

NTP

Network Time Protocol (протокол сетевого времени) [RFC5905].

PMF

Performance Measurement Function (функция измерения производительности).

PTP

Precision Time Protocol (протокол точного времени) [IEEE.1588.2008].

RP

Reverse Path (обратный путь).

SMI

Structure of Management Information (структура информации управления).

SSID

STAMP Session Identifier (идентификатор сессии STAMP).

SSU

Synchronization Supply Unit (блок синхронизации).

STAMP

Simple Two-way Active Measurement Protocol (простой протокол активного двухстороннего измерения).

TLV

Type-Length-Value (тип, размер, значение).

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

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

3. Идентификатор сессии STAMP

STAMP Session-Sender передает тестовые пакеты рефлектору STAMP Session-Reflector. Рефлектор принимает пакеты от Session-Sender и действует в соответствии со своей конфигурацией и необязательными управляющими сигналами в тестовых пакетах от Session-Sender. Протокол STAMP определяет два формата пакетов – один для STAMP Session-Sender, другой для STAMP Session-Reflector и может работать в режиме с аутентификацией или без нее. Тестовые пакеты STAMP без аутентификации совместимы в линии с пакетами TWAMP-Test без аутентификации [RFC5357].

По умолчанию STAMP использует симметричные пакеты, т. е. размер пакетов, переданных Session-Reflector , совпадает с размером пакетов, полученных рефлектором.

Сессия STAMP идентифицируется квартетом (4-tuple) из IP-адресов отправителя и получателя, а также портов UDP на той и другой стороне). STAMP Session-Sender может создавать уникальный для него идентификатор сессии SSID, представляющий собой 2-октетное положительное целое число. Правила генерации SSID определяются реализацией. В [NUM-IDS-GEN] тщательно проанализированы базовые алгоритмы для генерации идентификаторов и их уязвимости. Например, реализация может использовать алгоритмы, описанные в параграфе 7.1 [NUM-IDS-GEN]. Реализации недопустимо назначать один идентификатор разным тестовым сессиям STAMP. Session-Sender может применять SSID для идентификации тестовых сессий STAMP. При использовании SSID идентификатор должен включаться в каждый тестовый пакет данной сессии. Расположение SSID в режиме без аутентификации показано на рисунке 1.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |             SSID              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                         MBZ (28 октетов)                      |
|                                                               |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            TLVs                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Формат расширенного пакета без аутентификации.


Реализация STAMP Session-Reflector, поддерживающая эту спецификацию, должна идентифицировать сессию STAMP по SSID в комбинации с обычным квартетом для сессии. Перед началом тестовой сессии рефлектору должны быть предоставлены все элементы, идентифицирующие сессию. STAMP Session-Reflector должен отбрасывать не соответствующие сессии пакеты STAMP. Способ предоставления идентификационных данных сессии выходит за рамки документа. Соответствующая спецификации реализация STAMP Session-Reflector должна копировать значение SSID из полученных тестовых пакетов в отражаемые пакеты, как показано на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |           SSID                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Receive Timestamp                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Session-Sender Sequence Number                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                  Session-Sender Timestamp                     |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate |           MBZ                 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL |                   MBZ                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            TLVs                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Формат отраженного расширенного пакета без аутентификации.


Не поддерживающий эту спецификацию STAMP Session-Reflector будет возвращать нулевое значение поля SSID в отраженных пакетах STAMP и Session-Sender может прервать сессию при получении такого поля SSID. Реализация Session-Sender должна поддерживать управление поведением в таких случаях. Если тестовая сессия не прерывается, Session-Sender может передавать базовые пакеты STAMP [RFC8762] или продолжить передачу пакетов с SSID.

Размещение поля SSID в режиме с аутентификацией показано на рисунках 3 и 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Sequence Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      MBZ (12 октетов)                         |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Timestamp                              |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Error Estimate         |            SSID               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                                                               ~
|                         MBZ (68 октетов)                      |
~                                                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                       HMAC (16 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            TLVs                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (12 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          Timestamp                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         Error Estimate        |            SSID               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (4 октетов)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Receive Timestamp                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (8 октетов)                        |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Session-Sender Sequence Number                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MBZ (12 октетов)                       |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                 Session-Sender Timestamp                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session-Sender Error Estimate |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
|                        MBZ (6 октетов)                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Ses-Sender TTL |                                               |
+-+-+-+-+-+-+-+-+                                               +
|                                                               |
|                        MBZ (15 октетов)                       |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        HMAC (16 октетов)                      |
|                                                               |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            TLVs                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Формат отраженного расширенного пакета с аутентификацией.

4. TLV-расширения для STAMP

Кодирование TLV обеспечивает гибкий механизм расширения для необязательных информационных элементов за счет включения необязательного поля TLV в тестовый пакет STAMP. Это поле TLV может содержать другие TLV в зависимости от семантики (внешнего) TLV. TLV имеют однооктетное поле STAMP TLV Flags, однооктетное поле Type и двухоктетное поле Length, указывающее размер поля Value в октетах. Если поле Type для TLV или суб-TLV имеет значение из диапазона Private Use [RFC8126], размер должен быть не меньше 4 и первые четыре октета должны содержать фирменный код SMI (Private Enterprise Code), как указано в субреестре IANA SMI Network Management Private Enterprise Codes, с сетевым полядком байтов. Остальная часть поля Value определяется производителем. В последующих параграфах описано применение TLV для STAMP, расширяющее базовую спецификацию STAMP.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type      |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                            Value                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Формат TLV в расширенном пакете STAMP.


STAMP TLV Flags

8-битовое поле. Формат и интерпретация описаны ниже.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле, указывающее размер поля Value в октетах.

Value

Поле переменного размера, кодирование и интерпретация которого определяются значением поля Type.

Для всех многобайтовых полей в TLV, определенных этой спецификацией, используется сетевой порядок байтов.

Формат поля STAMP TLV Flags показан на рисунке 6, а флаги местоположения определены в параграфе 5.2.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|U|M|I|R|R|R|R|R|
+-+-+-+-+-+-+-+-+

Рисунок 6. Формат поля флагов.


U (Unrecognized)

Session-Sender должен устанавливать U = 1 перед отправкой расширенного пакета STAMP, а Session-Reflector должен устанавливать U = 1, если он не понимает данный TLV. Для известных TLV рефлектор должен указывать в отраженных пакетах U = 0.

M (Malformed)

Session-Sender должен устанавливать M = 1 перед отправкой расширенного пакета STAMP, а Session-Reflector должен устанавливать M = 1, если считает формат TLV некорректным (поле Length не соответствует типу или оставщаяся часть пакета STAMP меньше размера данного TLV). В остальных случаях рефлектор должен указывать в отраженных пакетах M = 0.

I (Integrity)

Session-Sender должен устанавливать I = 0 перед отправкой расширенного пакета STAMP, а Session-Reflector должен устанавливать I = 1, если расширения STAMP не прошли проверку HMAC (параграф 4.8). В остальных случаях рефлектор должен указывать в отраженных пакетах I = 0.

R

Зарезервированные на будущее флаги, которые должны содержать 0 при передачи и игнорироваться при получении.

Узел STAMP (Session-Sender или Session-Reflector), получивший тестовый пакет, должен проверить, является пакет базовым или содержит TLV. Узел должен сравнить значение поля Length в заголовке UDP и размер базового пакета STAMP в режиме (с аутентификацией или без нее), заданном конфигурацией сессии STAMP. Если разница превышает размер заголовка UDP, тестовый пакет включает STAMP TLV, следующие сразу за базовым пакетом STAMP. Рефлектор, не поддерживающий принятые расширения, не будет обрабатывать их, а просто скопирует в отраженный пакет, как указано в параграфе 4.3 [RFC8762]. Поддерживающий TLV рефлектор укажет необработанные им TLV установкой для них флага U = 1.

STAMP Session-Sender, получающий отраженные пакеты STAMP с TLV, должен проверить все TLV как указано ниже.

  • При установленном флаге U система STAMP должна пропустить обработку соответствующего TLV.

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

  • При установленном флаге I система STAMP должна отбросить все TLV и должна прекратить обработку оставшейся части пакета STAMP.

  • Если реализация Session-Reflector не распознает значение поля Type, она должна включить копию TLV в отраженный пакет STAMP и должна установить для нее U = 1. Рефлектор должен пропускать обработку неизвестных TLV.

  • При нарушении формата TLV обработка TLV расширений должна прекращаться. Session-Reflector должен скопировать оставшуюся часть полученного пакета STAMP в отраженный пакет и должен установить M = 1.

4.1. TLV дополнительного заполнения

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                         Extra Padding                         ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 7. TLV дополнительного заполнения.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле, указывающее размер поля Value в октетах.

Extra Padding

Это поле следует заполнять псевдослучайными значениями, но можно заполнить нулями. Реализация должна контролировать поле Extra Padding.

Блок Extra Padding TLV похож на поле Packet Padding в пакетах TWAMP-Test [RFC5357]. Применение Extra Padding TLV рекомендуется для тестов STAMP, использующих пакеты, размер которых превышает базовый [RFC8762] размер, составляющий 44 октета в режиме без аутентификации и 112 – в режиме с аутентификацией. Extra Padding TLV может присутствовать в пакете STAMP в нескольких экземплярах.

4.2. TLV местоположения

STAMP Session-Sender может включать Location TLV переменного размера для запроса информации о местоположении рефлектора. Отправителю недопустимо заполнять в этом случае какие-либо поля, за исключением STAMP TLV Flags, Type и Length. Рефлектор должен проверять корректность формата TLV и следовать описанной в разделе 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        Destination Port       |          Source Port          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                         Sub-TLVs                              ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 8. Location TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле, указывающее размер поля Value в октетах.

Destination Port

2-октетное поле с номером целевого порта UDP в принятом пакете STAMP.

Source Port

2-октетное поле с номером порта отправителя UDP в принятом пакете STAMP.

Sub-TLVs

Последовательность суб-TLV, определенная ниже, которые Session-Sender использует для запроса информации о местоположении. Session-Reflector отвечает на них соответствующими суб-TLV для типа адреса (например, IPv4 или IPv6), используемого им.

Отметим, что все поля, не заполненные отправителем или рефлектором, передаются с заполнением нулями.

4.2.1. Суб-TLV местоположения

Location TLV использует формат, показанный на рисунке 5. Обработка флагов U и M для этого суб-TLV выполняется в соответствии с разделом 4. Для флага I отправитель и рефлектор должны устанавливать значение 0 до передачи, а на приемной стороне флаг игнорируется. Ниже приведены типы суб-TLV для Location TLV, определенные этой спецификацией (таблица 5).

Source MAC Address

12-октетный блок суб-TLV с Type = 1. Поле Length должно иметь значение 8, поле Value является 8-октетным MBZ, которое должно заполняться нулями при передаче и игнорироваться при получении.

Source EUI-48 Address

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        EUI-48  Address                        |
+                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                               |            MBZ                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 9. Поле Value в суб-TLV Source EUI-48 Address.

12-октетный блок суб-TLV MAC-адресом отправителя EUI-48 и Type = 2. Поле Length должно иметь значение 8.

EUI-48 Address

6-октетное поле.

MBZ

2-октетное поле, которое должно заполняться нулями при передаче и игнорироваться при получении.

Source EUI-64 Address

12-октетный блок суб-TLV, содержащий MAC-адрес EUI-64 для отправителя и Type = 3. Поле Length должно иметь значение 8, а Value содержит 8-октетный адрес EUI-64.

Destination IP Address

20-октетный блок суб-TLV с Type = 4. Поле Length должно иметь значение 16, а 16-октетное поле MBZ должно заполняться нулями при передаче и игнорироваться при получении.

Destination IPv4 Address

20-октетный блок суб-TLV с адресом получателя IPv4 и Type = 5. Поле Length должно иметь значение 16.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         IPv4 Address                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                        MBZ (12 октетов)                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 10. Поле Value в суб-TLV IPv4 Address.

IPv4 Address

4-октетное поле.

MBZ

12-октетное поле, которое должно заполняться нулями при передаче и игнорироваться при получении.

Destination IPv6 Address

20-октетный блок суб-TLV с адресом получателя IPv6 и Type = 6. Поле Length должно иметь значение 16, а Value содержит 16-октетный адрес IPv6.

Source IP Address

20-октетный блок суб-TLV с Type = 7. Поле Length должно иметь значение 16, а Value содержит 16-октетное поле MBZ, которое должно заполняться нулями при передаче и игнорироваться при получении.

Source IPv4 Address

20-октетный блок суб-TLV с адресом отправителя IPv4 и Type = 8. Поле Length должно иметь значение 16, а Value содержит показанные ниже поля (рисунок 10).

IPv4 Address

4-октетное поле.

MBZ

12-октетное поле, которое должно заполняться нулями при передаче и игнорироваться при получении.

Source IPv6 Address

20-октетный блок суб-TLV с адресом отправителя IPv6 и Type = 9. Поле Length должно иметь значение 16, а Value содержит 16-октетный адрес IPv6.

4.2.2. Теория работы Location TLV

Session-Reflector, принимающий расширенный пакет STAMP с Location TLV, должен включить в отраженный пакет Location TLV, размер которого совпадает с размером Location TLV в полученном пакете. В соответствии с локальной политикой Session-Reflector может не сообщать значения некоторых полей, заполнив их нулями. Реализация Session-Reflector с учетом состояния должна обеспечивать управление политикой заполнения полей.

Session-Sender может включить суб-TLV Source MAC Address в Location TLV. Рефлектор, получивший Location TLV с суб-TLV Source MAC Address, должен включить суб-TLV Source EUI-48 Address, если MAC-адрес отправителя тестового пакета имеет формат EUI-48. Session-Reflector должен копировать MAC-адрес отправителя в поле EUI-48. В противном случае Session-Reflector должен использовать суб-TLV Source EUI-64 Address и должен копировать значение Source MAC Address из полученного пакета в поле EUI-64. Если полученный пакет STAMP не имеет поля Source MAC Address, рефлектор должен заполнить поле EUI-64 нулями до передачи отраженного пакета.

Session-Sender может включить суб-TLV Destination IP Address в Location TLV. Рефлектор, получивший Location TLV с суб-TLV Destination IP Address, должен включить суб-TLV Destination IPv4 Address, если IP-адрес отправителя полученного пакета относится к семейству IPv4. Session-Reflector должен копировать значение IP-адреса получателя в поле IPv4 Address. В противном случае Session-Reflector должен использовать суб-TLV Destination IPv6 Address и должен копировать значение IP-адреса получателя в поле IPv6 Address.

Session-Sender может включить суб-TLV Source IP Address в Location TLV. Рефлектор, получивший Location TLV с суб-TLV Source IP Address, должен включить суб-TLV Source IPv4 Address, если IP-адрес отправителя в полученном пакете относится к семейству IPv4. Session-Reflector должен копировать значение IP-адреса отправителя в поле IPv4 Address. В противном случае Session-Reflector должен использовать суб-TLV Source IPv6 Address и должен копировать значение IP-адреса отправителя в поле IPv6 Address.

Location TLV можно применять для определения IP-адреса и порта и MAC-адреса последнего интервала (last-hop) для пакета STAMP. MAC-адрес может указывать переключение пути на последнем интервале, адрес IP и порт UDP покажут наличие на пути маршрутизаторов NAT. Это позволяет отправителю узнать IP-адрес рефлектора, расположенного за транслятором NAT и обнаружить изменения в отображении NAT, которые могут приводить к отправке пакетов STAMP не тому рефлектору.

4.3. TLV характеристик временных меток

STAMP Session-Sender может включать Timestamp Information TLV для запроса информации у рефлектора. Отправителю недопустимо указывать информационные поля, за исключением STAMP TLV Flags, Type и Length. Все остальные поля должны заполняться нулями. Session-Reflector должен проверять поле Length в TLV и при некорректном значении выполнять процедуру, описанную в разделе 4 для TLV с ошибкой формата.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Sync Src In  | Timestamp In  | Sync Src Out  | Timestamp Out |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                    Optional sub-TLVs                          ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 11. Timestamp Information TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле, указывающее размер поля Value в октетах (рисунок 5).

Sync Src In

1-октетное поле, указывающее источник синхронизации часов на входе Session-Reflector. Имеется несколько методов синхронизации, например, протокол NTP (Network Time Protocol) [RFC5905] (таблица 7).

Timestamp In

1-октетное поле, указывающее метод, с помощью которого Session-Reflector получает временную метку T2. Это может быть аппаратный источник, подключенный через API к местным часам (wall clock) или удаленный источник (через плоскость управления). Возможные источники синхронизации указаны в таблице 9.

Sync Src Out

1-октетное поле, указывающее источник синхронизации часов на выходе Session-Reflector. Имеется несколько методов синхронизации выхода Session-Reflector (таблица 7).

Timestamp Out

1-октетное поле, указывающее метод, с помощью которого Session-Reflector получает временную метку T3 (таблица 9).

Optional sub-TLVs

Необязательное поле переменного размера.

4.4. TLV класса обслуживания

STAMP Session-Sender может включать CoS TLV в тестовые пакеты STAMP. Формат CoS TLV показан на рисунке 12.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   DSCP1   |   DSCP2   |ECN| RP|          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 12. TLV класса обслуживания.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле со значением 4.

DSCP1

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

DSCP2

Значение поля DSCP во входных пакетах рефлектора.

ECN

Значение поля ECN во входных пакетах рефлектора.

RP (Reverse Path)

2-октетное поле, для которго Session-Sender должен устанавливать значение 0.

Reserved

16-битовое поле, которое должно заполняться нулями при передаче и игнорироваться при получении.

STAMP Session-Reflector, получающий пакет с CoS TLV, должен включить CoS TLV в отраженный пакет. От также должен копировать значения полей DSCP и ECN из заголовка IP в принятом пакете STAMP в поле DSCP2 отраженного пакета. Кроме того, Session-Reflector должен использовать локальные правила для проверки соответствия CoS значению поля DSCP1, разрешенному в домене. При соответствии Session-Reflector должен установить поле DSCP в заголовке IP отраженного пакеты в соответствии с полем DSCP1 в полученном пакете. В противном случае Session-Reflector должен использовать значение DSCP из полученного пакета STAMP и установить RP = 1. При получении отраженного пакета с RP = 0 Session-Sender будет сохранять значения DSCP и ECN для анализа CoS в обратном направлении. Если в отраженном пакете RP = 1, CoS анализирется лишь для прямого направления.

Можно использовать перемаркировку CoS для разных сценариев (например, 2G, 3G, LTE в мобильных сетях) в одной сети. Однако при некорректной настройке будет сложно определить причину избыточной потери пакетов служб верхних уровней, тогда как для нижележащего уровня уровень потерь будет нормальным. использование CoS TLV в тестах STAMP помогает в поиске неполадок, а также проверке правил Diffserv при обработке CoS, требуемой конфигурацией.

4.5. TLV прямого измерения

Direct Measurement TLV позволяет собирать пакеты по профилю, т. е. из определенного потока данных, передаваемого от Session-Sender к Session-Reflector. Определение относящихся к профилю пакетов выходит за рамки документа и отдается на откуп оператору.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Session-Sender Tx counter  (S_TxC)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Session-Reflector Rx counter  (R_RxC)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Session-Reflector Tx counter  (R_TxC)             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 13. Direct Measurement TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле, указывающее размер поля Value в октетах. Поле должно иметь значение 12.

Session-Sender Tx counter (S_TxC)

4-октетное поле, к котором Session-Sender должен указывать число передаваемых по профилю пакетов.

Session-Reflector Rx counter (R_RxC)

4-октетное поле, которое Session-Sender должен устанавливать в 0, а Session-Reflector – игнорировать при получении. Рефлектор должен указывать в отраженных пакетах число принятых по профилю пакетов.

Session-Reflector Tx counter (R_TxC)

4-октетное поле, которое Session-Sender должен устанавливать в 0, а Session-Reflector – игнорировать при получении. Рефлектор должен указывать число переданных по профилю пакетов.

Session-Sender может включать Direct Measurement TLV в пакеты STAMP. При получении пакета STAMP с Direct Measurement TLV рефлектор должен включать этот блок TLV в отраженный пакет. Session-Reflector должен копировать значение поля S_TxC из полученного пакета в то же поле отраженного пакета.

4.6. TLV отчета о сети доступа

STAMP Session-Sender может включать Access Report TLV (рисунок 14) для индикации рефлектору изменения статуса сети доступа. Определение сети доступа выходит за рамки документа.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|     Type      |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   ID  |  Resv |  Return Code  |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 14. Access Report TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле со значением 4.

ID (Access ID)

4-битовый идентификатор сети доступа, например, 3GPP (технологии радиодоступа, заданные 3GPP) или не-3GPP (доступ, не описанный 3GPP) [TS23501].

1

Сеть 3GPP.

2

Другая сеть (не-3GPP).

Другие значения недействительны и TLV с такими значениями должны отбрасываться.

Resv

4-битовое поле, которое должно заполнятся нулями при передаче и игнорироваться при получении.

Return Code

1-октетное поле, идентифицирующее сигнал отчета, например, доступность или недоступность. Значение предоставляется конечной точке STAMP, механизмом, выходящим за рамки этого документа. Возможные значения приведены в параграфе 5.6.

Reserved

2-октетное резервное поле, которое должно заполнятся нулями при передаче и игнорироваться при получении.

STAMP Session-Sender, включающий Access Report TLV, устанавливает в поле Access ID значение, соответствующее типу сети, для которое передается отчет. Отправитель также указывает значение поля Return Code в соответствии с рабочим состоянием сети доступа. Механизм определения этого состояния выходит за рамки спецификации. Рефлектор, получивший тестовый пакет с Access Report TLV, должен включить такой TLV в отраженный пакет. Рефлектор должен скопировать в поля Access ID и Return Code значения из соответствующих полей принятого пакета.

Session-Sender должен запустить таймер повторной передачи после отправки тестового пакета с Access Report TLV. Таймер должен быть остановлен при получении отраженного пакета STAMP с Access Report TLV. Если отсчет таймера завершается до приема такого пакета, Session-Sender должен повторить тестовый пакет с Access Report TLV. Этот повтор следует выполнять до 4 раз, после чего процедуру нужно прервать. Установка значения таймера определяется локальной политикой и сетевым окружением. По умолчанию для таймера повтора Access Report TLV следует устанавливать значение 3 секунды. Реализация должна обеспечивать управления значением таймера и числом повторов.

Access Report TLV используется функцией измерения производительности (Performance Measurement Function или PMF) в системе управления доступом, коммутацией и разделением для сети 5G networks [TS23501]. PMF в пользовательском оборудовании выступает как STAMP Session-Sender, а PMF в пользовательской плоскости (User Plane) – как STAMP Session-Reflector.

4.7. Follow-Up Telemetry TLV

Session-Reflector может оказаться способным поместить в поле Follow-Up Timestamp лишь временную метку типа SW Local (таблица 9). Однако система хостинга может предоставлять временную метку ближе к началу реальной передачи пакета, даже если невозможно доставить информацию отправителю (Session-Sender) вовремя для самого пакета. Тем не менее, эта метка может быть важна для Session-Sender, поскольку она повышает точность измерения задержки в сети за счет минимизации влияния задержки в выходных очередях.

STAMP Session-Sender может включать Follow-Up Telemetry TLV для запроса информации у рефлектора. Session-Sender должен указать в полях Follow-Up Telemetry Type и Length подходящие для него значения. Поля Sequence Number и Follow-Up Timestamp должны заполняться отправителем нулями и игнорироваться рефлектором при получении пакета STAMP с Follow-Up Telemetry TLV. Рефлектор должен проверить значение поля Length в тестовом пакете STAMP. Если это значение недействительно, рефлектор должен обнулить поля Sequence Number и Follow-Up Timestamp, а также установить флаг M в поле STAMP TLV Flags отраженного пакета. Если рефлектор работает без поддержки состояния (параграф 4.2 в [RFC8762]), он должен обнулять поля Sequence Number и Follow-Up Timestamp.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |           Length              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        Sequence Number                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Follow-Up Timestamp                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Timestamp M  |                     Reserved                  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 15. Follow-Up Telemetry TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле со значением 16.

Sequence Number

4-октетное поле, указывающее порядковый номер последнего пакета, отраженного в данной сессии STAMP. Поскольку Session-Reflector работает в режиме с поддержкой состояния (параграф 4.2 в [RFC8762]), это будет порядковый номер Session-Reflector из предыдущего отраженного пакета.

Follow-Up Timestamp

8-октетное поле, хормат которого задает флаг Z в поле Error Estimate базового пакета STAMP, который содержится в этом отраженном пакете от Session-Reflector, как описано в параграфе 4.2.1 [RFC8762]. Поле содержит временную метку момента передачи отраженного пакета с указанным номером.

Timestamp M(ode)

1-октетное поле, указывающее метод получения Follow-Up Timestamp элементом, передающим отраженный пакет STAMP (см. таблицу 9).

Reserved

2-октетное резервное поле, которое должно заполнятся нулями при передаче и игнорироваться при получении.

4.8. HMAC TLV

STAMP в режиме с аутентификацией защищает целостность данных в базовом пакете STAMP. Расширения STAMP предназначены для предоставления дополнительных сведений об условиях в сети и их целостность тоже важна. Все базовые пакеты STAMP с аутентификацией (параграфы 4.2.2 и 4.3.2 в [RFC8762]), совместимые с этой спецификацией, должны также аутентифицировать дополнительные TLV путем включения HMAC TLV, за исключением случаев наличия лишь Extended Padding TLV. Блок HMAC TLV должен помещаться после всех TLV, включенных в пакет STAMP, за исключением Extra Padding TLV. Включение HMAC TLV в другое место расширенного тестового пакета STAMP должно считаться отказом при проверке HMAC, как указано ниже. HMAC TLV можно применять для защиты целостности расширений STAMP в режиме без аутентификации. Реализация расширений STAMP должна обеспечивать элементы управления для включения защиты целостности расширений в режиме без аутентификации.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|STAMP TLV Flags|      Type     |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                              HMAC                             |
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 16. HMAC TLV.


STAMP TLV Flags

8-битовое поле флагов, формат которого показан на рисунке 6.

Type

1-октетное поле, определяющее интерпретацию поля Value. Значения выделяются IANA (параграф 5.1).

Length

2-октетное поле со значением 16.

HMAC

16-октетное поле с кодом HMAC для всех предшествующих TLV.

Как определено в [RFC8762], STAMP использует HMAC-SHA-256 с отсечкой до 128 битов (см. [RFC4868]). Все вопросы использования ключей, рассмотренные в параграфе 4.4 [RFC8762], полностью применимы к HMAC TLV. Управление ключами HMAC и механизмы их распространения выходят за рамки этой спецификации. Предполагается, что HMAC TLV будет отслеживать изменения базового протокола STAMP [RFC8762], включая применение более совершенных криптографических алгоритмов. Расчет HMAC выполняется в соответствии с [RFC2104] для конкатенации поля Sequence Number в стандартном пакете STAMP и всех предшествующих TLV. Подпись должна отсекаться до 128 битов и помещаться в поле HMAC. Если HMAC TLV имеется в расширенном пакете STAMP, например, в режиме с аутентификацией, значение HMAC должно проверяться до использования данных, включенных в STAMP TLV. Если проверка HMAC рефлектором завершается отказом, Session-Reflector должен прекратить обработку полученного расширенного пакета STAMP. В этом случае рефлектор должен копировать TLV из полученного пакета STAMP в отраженный пакет и должен устанавливать флаг I = 1 в каждом TLV, копируемом в отраженный пакет, до отправки отраженного пакета. Если Session-Sender получает расширенный пакет STAMP с I = 1, он должен прервать обработку TLV в отраженном пакете. Если проверка HMAC у Session-Sender завершилась отказом, Session-Sender должен прервать обработку TLV в расширенном отраженном пакете STAMP.

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

Агентство IANA создало в реестре Simple Two-way Active Measurement Protocol (STAMP) TLV Types перечисленные в слудующих параграфах субреестры.

5.1. Субреестр STAMP TLV Types

В IANA создан субреестр STAMP TLV Types, коды в котором выделяются в соответствии с [RFC8126], как указано в таблице 1.

Таблица 1. Процедуры регистрации для субреестров типов STAMP TLV.

Диапазон

Процедура регистрации

1 – 175

IETF Review

176 – 239

First Come First Served

240 – 251

Experimental Use

252 – 254

Private Use

В соответствии с этим документом в IANA создан субреестр STAMP TLV Types (таблица 2).

Таблица 2. Типы STAMP TLV.

Значение

Название

Документ

0

Резерв

RFC 8972

1

Extra Padding

RFC 8972

2

Location

RFC 8972

3

Timestamp Information

RFC 8972

4

Class of Service

RFC 8972

5

Direct Measurement

RFC 8972

6

Access Report

RFC 8972

7

Follow-Up Telemetry

RFC 8972

8

HMAC

RFC 8972

255

Резерв

RFC 8972

5.2. Субреестр STAMP TLV Flags

В IANA создан субреестр STAMP TLV Flags, коды в котором выделяются по процедуре IETF Review [RFC8126]. Флаги занимают 8 битов. В соответствии с этим документом в IANA создан субреестр STAMP TLV Flags (таблица 3).

Таблица 3. Флаги STAMP TLV.

Бит

Символ

Название

документ

0

U

Unrecognized TLV

RFC 8972

1

M

Malformed TLV

RFC 8972

2

I

Integrity check failed

RFC 8972

5.3. Субреестр STAMP Sub-TLV Types

В IANA создан субреестр STAMP Sub-TLV Types, значения в котором выделяются в соответствии с [RFC8126], как указано в таблице 4.

Таблица 4. Процедуры регистрации для субреестров типов STAMP суб-TLV.

Диапазон

Процедура регистрации

1 – 175

IETF Review

176 – 239

First Come First Served

240 – 251

Experimental Use

252 – 254

Private Use

В соответствии с этим документом в IANA создан субреестр STAMP Sub-TLV Types (таблица 5).

Таблица 5. Типы STAMP суб-TLV.

Значение

Название

TLV

Документ

0

Резерв

RFC 8972

1

Source MAC Address

Location

RFC 8972

2

Source EUI-48 Address

Location

RFC 8972

3

Source EUI-64 Address

Location

RFC 8972

4

Destination IP Address

Location

RFC 8972

5

Destination IPv4 Address

Location

RFC 8972

6

Destination IPv6 Address

Location

RFC 8972

7

Source IP Address

Location

RFC 8972

8

Source IPv4 Address

Location

RFC 8972

9

Source IPv6 Address

Location

RFC 8972

255

Резерв

RFC 8972

5.4. Субреестр STAMP Synchronization Sources

В IANA создан субреестр STAMP Synchronization Sources, значения в котором выделяются в соответствии с [RFC8126], как указано в таблице 6.

Таблица 6. Процедуры регистрации для источников синхронизации STAMP.

Диапазон

Процедура регистрации

1 – 127

IETF Review

128 – 239

First Come First Served

240 – 249

Experimental Use

250 – 254

Private Use

В соответствии с этим документом в IANA создан субреестр STAMP Synchronization Sources (таблица 7).

Таблица 7. Источники синхронизации STAMP.

Значение

Название

Документ

0

Резерв

RFC 8972

1

NTP

RFC 8972

2

PTP

RFC 8972

3

SSU/BITS

RFC 8972

4

GPS/GLONASS/LORAN-C/BDS/Galileo

RFC 8972

5

Local free-running

RFC 8972

255

Резерв

RFC 8972

5.5. Субреестр STAMP Timestamping Methods

В IANA создан субреестр STAMP Timestamping Methods, значения в котором выделяются в соответствии с [RFC8126], как указано в таблице 8.

Таблица 8. Процедуры регистрации для методов указания временных меток STAMP.

Диапазон

Процедура регистрации

1 – 127

IETF Review

128 – 239

First Come First Served

240 – 249

Experimental Use

250 – 254

Private Use

В соответствии с этим документом в IANA создан субреестр STAMP Timestamping Methods (таблица 9).

Таблица 9. Методы получения временных меток STAMP.

Значение

Название

Документ

0

Резерв

RFC 8972

1

HW Assist

RFC 8972

2

SW Local

RFC 8972

3

Control Plane

RFC 8972

255

Резерв

RFC 8972

5.6. Субреестр STAMP Return Codes

В IANA создан субреестр STAMP Return Codes, коды в котором выделяются в соответствии с [RFC8126], как указано в таблице 10.

Таблица 10. Процедуры регистрации для кодов возврата STAMP.

Диапазон

Процедура регистрации

1 – 127

IETF Review

128 – 239

First Come First Served

240 – 249

Experimental Use

250 – 254

Private Use

В соответствии с этим документом в IANA создан субреестр STAMP Return Codes (таблица 11).

Таблица 11. Коды возврата STAMP.

Значение

Название

Документ

0

Резерв

RFC 8972

1

Network available

RFC 8972

2

Network unavailable

RFC 8972

255

Резерв

RFC 8972

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

Этот документ определяет расширения протокола STAMP [RFC8762] и наследует все вопросы безопасности, связанные с базовым протоколом. В документе также определен блок HMAC TLV, обеспечивающий защиту целостности расширения STAMP, но он не защищает от replay-атак (повторное использование пакетов). Использование HMAC TLV описано в параграфе 4.8.

Для защиты от TLV с некорректным форматом реализации Session-Sender и Session-Reflector должны:

  • проверять значение флага M;

  • проверять корректность значения поля Length.

Поскольку эта спецификация задает механизм тестирования отображений DSCP, документ наследует все вопросы безопасности, рассмотренные в [RFC2474]. Мониторинг т необязательное управдение DSCP с помощью CoS TLV можно использовать через Internet так, что Session-Sender и Session-Reflector будут размещаться в доменах с разными профилями CoS. Поэтому важна проверка оператором набора значений CoS, применяемых в домене Session-Reflector. Реализации Session-Reflector также следует поддерживать локальную политику для подтверждения возможности использования значения поля DSCP, переданного Session-Sender (параграф 4.4).

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

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

[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication”, RFC 2104, DOI 10.17487/RFC2104, February 1997, <https://www.rfc-editor.org/info/rfc2104>.

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

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

[RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, “Simple Two-Way Active Measurement Protocol”, RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.

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

[GPS] “Global Positioning System (GPS) Standard Positioning Service (SPS) Performance Standard”, GPS SPS 5th Edition, April 2020.

[IEEE.1588.2008] “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems”, IEEE Std. 1588-2008, DOI 10.1109/IEEESTD.2008.4579760, July 2008, <https://doi.org/10.1109/IEEESTD.2008.4579760>.

[NUM-IDS-GEN] Gont, F. and I. Arce, “On the Generation of Transient Numeric Identifiers”, Work in Progress, Internet-Draft, draft-irtf-pearg-numeric-ids-generation-06, 13 January 2021, <https://tools.ietf.org/html/draft-irtf-pearg-numeric-ids-generation-06>.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers”, RFC 2474, DOI 10.17487/RFC2474, December 1998, <https://www.rfc-editor.org/info/rfc2474>.

[RFC4868] Kelly, S. and S. Frankel, “Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec”, RFC 4868, DOI 10.17487/RFC4868, May 2007, <https://www.rfc-editor.org/info/rfc4868>.

[RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, “A Two-Way Active Measurement Protocol (TWAMP)”, RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, “Network Time Protocol Version 4: Protocol and Algorithms Specification”, RFC 5905, DOI 10.17487/RFC5905, June 2010, <https://www.rfc-editor.org/info/rfc5905>.

[TS23501] 3GPP, “Technical Specification Group Services and System Aspects; System Architecture for the 5G System (5GS); Stage 2 (Release 16)”, 3GPP TS 23.501, 2019.

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

Аворы признательны за внимательное рецензирование и вдумчивые комментарии Tianran Zhou, Rakesh Gandhi, Yuezhong Song и Yali Wang. Срасибо Al Morton за его замечанию и ценные предложения. Авторы также признательны за комментарии и предложения, полученные от Martin Duke.

Участники работы

Ниже указан человек, внесший вклад в текст этого документа.

Guo Jun

ZTE Corporation

68# Zijinghua Road

Nanjing

Jiangsu, 210012

China

Phone: +86 18105183663

Email: guo.jun2@zte.com.cn

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

Greg Mirsky

ZTE Corp.

Email: gregimirsky@gmail.com

Xiao Min

ZTE Corp.

Email: xiao.min2@zte.com.cn

Henrik Nydell

Accedian Networks

Email: hnydell@accedian.com

Richard Foote

Nokia

Email: footer.foote@nokia.com

Adi Masputra

Apple Inc.

One Apple Park Way

Cupertino, CA 95014

United States of America

Email: adi@apple.com

Ernesto Ruffini

OutSys

via Caracciolo, 65

20155 Milan

Italy

Email: eruffini@outsys.org

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

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

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

Рубрика: RFC | Комментарии к записи RFC 8972 Simple Two-Way Active Measurement Protocol Optional Extensions отключены

Как новые технологии меняют отрасль Web-разработки

image_print

Artur Meyster

https://twitter.com/arturmeyster
https://www.linkedin.com/in/meyster

Артур Мейстер (Artur Meyster) – технический директор Career Karma (YC W19) –  онлайн-площадки для подбора людей, меняющих свою карьеру, с учебными курсами по программированию. Он также является ведущим подкаста Breaking Into Startups, в котором рассказывают о людях с нетрадиционным образованием, пришедшим в технологическую индустрию.

Как новые технологии меняют отрасль Web-разработки

Новые технологии меняют всю сферу разработки. Хорошо это или плохо, новинки внедряются и обратного пути нет. Отрасль web-разработок также испытывает влияние новых технологий. Ускоренные страницы для мобильных приложений, голосовой поиск и искусственный интеллект (artificial intelligence или AI) — это лишь несколько технологий, применяемых сегодня для улучшения web-сайтов.

Web-дизайнерам приходится приспосабливаться к новым потребностям рынка. Например, компании сегодня полагаются на цифровой маркетинг для повышения объема продаж и уровня узнаваемости своего бренда, но достичь этого можно лишь с помощью web-сайтов. Поэтому web-разработчикам нужно создавать более эффективные web-сайты с лучшими характеристиками и производительностью.

Точно так же использование дополненной реальности (augmented reality или AR) для покупок в сети ставит перед web-разработчиками новые задачи и требует от них оставаться в курсе современных событий.

Чтобы понять, как новые технологии влияют на отрасль web-разработки, нужно принять во внимание несколько аспектов.

Искусственный интеллект и машинное обучение

Сегодня разработчики применяют машинное обучение и AI для улучшения web-сайтов беспрецедентными способами. Благодаря машинному обучению, сайты способны предоставлять персонифицированные услуги и пользователи получают адаптированную для них информацию. По сути, такие компании, как Netflix, Spotify и Youtube использовали машинное обучение, чтобы предлагать содержимое на основе ввода от пользователя. Сейчас пользователи чувствуют себя комфортно, поскольку не приходится тратить время на просмотр не интересующего их содержимого.

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

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

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

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

Системы управления содержимым

Системы управления содержимым (Content management systems или CMS) служат для упрощения процесса создания web-сайтов. Фактически пользователям не нужны познания в сфере web-разработки и достаточно просто понимать, какой информацией они хотят поделиться, и добавить на сайт несколько виджетов. Однако создание уникальных сайтов с помощью таких CMS как WordPress или Wix может быть затруднего необходимостью использовать базовые макеты и темы.

С другой стороны, для владельцев компании web-разработчики могут не иметь существенного значения при создании визуально привлекательных web-сайтов, поскольку CMS просты в использовании. Web-сайты создаются на базе хостинг-провайдеров, предоставляющих доступ к файлам и базам данных.

Ускоренные страницы для мобильных приложений

Ускоренные страницы для мобильных приложений (Accelerated mobile pages или AMP) получили широкое распространение с обретением популярности смартфонами. Фактически большинство пользователей сейчас применяет мобильные устройства с высокой скоростью доступа в сеть, что требует быстрой загрузки web-сайтов. Использование AMP обеспечивает решение нескольких проблем. Например, эта технология не только повышает привлекательность мобильных приложений, но и снижает нагрузку на сервер. Фактически, это улучшает взаимодействие с пользователем и снижает нагрузку на серверы хостинг-провайдера.

Однако не все идеально и AMP также имеет свои недостатки. Во-первых, использование ускоренных страниц снижает интеграцию рекламы с сайтом и у результате владельцы сайта могут столкнуться со снижением дохода. Во-вторых, сайты электронной коммерции используют динамические элементы, не поддерживаемые AMP. По этой причине приходится перенаправлять клиента, посещающего web-сайт, что может снизить доверие к компании. И, наконец, имеются ограничения для содержимого web-сайтов, поскольку финальное представление находится под контролем Google.

Дополненная реальность

Web-дизайнеры внедрили технологию дополненной реальности (AR) в камеры смартфонов и web-камеры, чтобы помочь клиентам выбирать продукцию. Фактически, применение AR улучшает взаимодействие с пользователем как в настольных системах, так и в мобильных устройствах. Пользователь может через свою камеру показать все, что пожелает, и увидеть нужную продукцию. Например, в сфере обустройства дома можно выбрать продукцию и показать свое окружение через камеру, чтобы увидеть, как будет выглядеть комната. В модной розничной торговле пользователи могут просмотреть наряды и увидеть, что им лучше подходит. Разумно отметить, что дополненная реальность изменила способы покупок через сеть, повысив уровень удовлетворенности клиентов.

Рубрика: Разное | Комментарии к записи Как новые технологии меняют отрасль Web-разработки отключены

RFC 8966 The Babel Routing Protocol

image_print
Internet Engineering Task Force (IETF)                     J. Chroboczek
Request for Comments: 8966             IRIF, University of Paris-Diderot
Obsoletes: 6126, 7557                                        D. Schinazi
Category: Standards Track                                     Google LLC
ISSN: 2070-1721                                             January 2021

The Babel Routing Protocol

Протокол маршрутизации Babel

PDF

Аннотация

Babel представляет собой протокол маршрутизации на основе вектора удаленности (distance-vector) с предотвращением петель, который устойчив к отказам и эффективен как в кабельных, так и в беспроводных сетях. Документ описывает протокол маршрутизации Babel и отменяет RFC 6126 и RFC 7557.

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

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

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

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

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

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

Оглавление

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

1. Введение

Протокол маршрутизации Babel на основе вектора удаленности с предотвращением петель предназначен для отказоустойчивой и эффективной маршрутизации для сетей, использующих префиксы и плоскую маршрутизацию (многосвязные сети – mesh), как в сравнительно стабильных проводных системах, так и в очень динамичных беспроводных сетях. Этот документ описывает протокол маршрутизации Babel и отменяет [RFC6126] и [RFC7557].

1.1. Свойства

Основным свойством, которое делает протокол Babel подходящим для нестабильных сетей, является то, что он, в отличие от простых протоколов на основе вектора удаленности [RIP], строго ограничивает частоту и продолжительность аномалий маршрутизации, таких как петли и «черные дыры» в процессе схождения маршрутов. Даже после обнаружения перемещения элемента (mobility event) сеть Babel обычно остается свободной от петель. После такого события Babel быстро пересчитывает конфигурацию, которая не содержит петель и сохраняет связность, но не обязательно является оптимальной. Эта операция во многих случаях даже не требует обмена пакетами. Затем Babel выполняет медленную процедуру схождения (может занимать минуты) для получения оптимальной конфигурации. Это достигается за счет использования упорядоченных маршрутов – метода, впервые примененного в маршрутизации Destination-Sequenced Distance-Vector (упорядоченные по адресатам векторы удаленности) [DSDV].

Более точно, протокол Babel имеет перечисленные ниже свойства:

  • когда каждый префикс исходит лишь от одного маршрутизатора, в протоколе Babel не возникает петель;

  • когда один префикс исходит от нескольких маршрутизаторов, Babel может иногда создавать временные маршрутные петли, которые исчезают за время, пропорциональное диаметру петли, и больше никогда (до произвольного момента сбора мусора (garbage-collection или GC)) вовлеченные маршрутизаторы не будут попадать в петлю для того же префикса;

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

Babel обеспечивает оценку качества каналов и поддерживает достаточно произвольную метрику. При соответствующей настройке Babel может реализовать маршрутизацию по кратчайшему пути (shortest-path) или использовать метрику, например, на основе числа теряемых пакетов.

Узлы Babel устанавливают связи между собой даже при настройке с разными параметрами. Например, мобильный узел с небольшой батареей, может использовать большие временные интервалы (сообщения hello, обновления и т. п.), нежели узел с питанием от электросети. И наоборот, узел с высоким уровнем мобильности может сократить временные интервалы. Возможность создавать такие неоднородные сети делают протокол Babel адаптируемым к работе в неуправляемых и беспроводных средах.

Babel является гибридным протоколом маршрутизации в том смысле, что он может передавать маршруты для разных протоколов сетевого уровня (IPv4 и IPv6), независимо от протокола, используемого для передачи пакетов Babel.

1.2. Ограничения

Протоколу Babel присущи два ограничения, делающие его непригодным в некоторых средах. Во-первых, протокол Babel основан на периодическом обновлении таблиц маршрутизации вместо использования надежного транспорта, что ведет к росту служебного трафика в больших стабильных сетях по сравнению с протоколами, которые передают обновления лишь при наличии изменений. Для таких сетей больше подходят такие протоколы как OSPF [OSPF], IS-IS [IS-IS] или EIGRP3 [EIGRP].

Во-вторых, если не реализован второй алгоритм, описанный в параграфе 3.5.4, Babel устанавливает время удержания при удалении префикса. Хотя это время не применяется к удаляемому префиксу и поэтому не препятствует быстрому схождению после восстановления префикса, оно применимо для более коротких префиксов, которые охватывает удаленный. Это может сделать реализации Babel, не поддерживающие необязательный алгоритм, описанный в параграфе 3.5.4, не подходящими для сетей с автоматическим агрегированием префиксов.

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

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

2. Концептуальное описание протокола

Babel является протоколом на основе вектора удаленности с предотвращением петель. Он основан на алгоритме Беллмана-Форда (Bellman-Ford), как известный протокол RIP [RIP], но включает множество усовершенствований, предотвращающих возникновение петель или быстро устраняющих петли без их повторного появления.

Концептуально алгоритма Bellman-Ford выполняется параллельно для каждого источника маршрутной информации (получателя трафика данных). Далее источник обозначается S с напоминанием, что алгоритм выполняется параллельно для всех источников.

2.1. Стоимость, метрика, соседство

Для каждой пары смежных узлов A и B протокол Babel рассчитывает абстрактное значение, называемое стоимостью канала от A к B и обозначаемое C(A, B). Для данного маршрута между любыми двумя (не обязательно смежными) узлами метрикой маршрута будет сумма стоимости всех каналов на пути. Цель алгоритма маршрутизации заключается в расчете для каждого S дерева маршрутов в S с минимальной метрикой.

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

Узел Babel периодически передает сообщения Hello всем своим соседям, а также периодически передает сообщения IHU (I Heard You – я вас слышу) каждому соседу, от которого недавно получено сообщение Hello. На основе информации из сообщений Hello и IHU от соседа B узел A рассчитывает стоимость C(A, B) для канала от A до B.

2.2. Алгоритм Беллмана-Форда

Каждый узел A поддерживает две части данных – оценку расстояния до S – D(A) и следующий маршрутизатор в направлении S – NH(A). Исходно D(S) = 0, D(A) бесконечная, а NH(A) не определен.

Периодически каждый узел B передает всем своим соседям обновление маршрутов в сообщении, содержащем D(B). Когда сосед A узла B получает обновление маршрутов, он проверяет, выбран ли B его следующим интервалом. Если это так, в качестве NH(A) указывается B, а для D(A) устанавливается C(A, B) + D(B). В противном случае A сравнивает C(A, B) + D(B) с текущим значением D(A). Если это значение меньше, полученное обновление анонсирует лучший маршрут по сравнению с выбранным и в качестве NH(A) устанавливается B, а D(A) получает значение C(A, B) + D(B).

Возможен ряд усовершенствований этого алгоритма и они применяются в протоколе Babel. В частности скорость схождения может быть увеличена за счет отправки в дополнение к обычным плановым обновлениям не запланированных «триггерных обновлений» при обнаружении существенных изменений в топологии. Кроме того, узел может поддерживать множество дополнительных маршрутов, которые были анонсированы соседями, отличными от выбранного им соседа, и которые могут применяться сразу же, если произойдет отказ выбранного соседа.

2.3. Временные петли в Bellman-Ford

Хорошо известно, что естественное применение алгоритма Bellman-Ford к распределенной маршрутизации может вызывать временные петли после изменения топологии. Рассмотрим пример, показанный на рисунке.

         B
      1 /|
   1   / |
S --- A  |1
       \ |
      1 \|
         C


После схождения будет D(B) = D(C) = 2 и NH(B) = NH(C) = A.

Предположим, что на канале между S возник отказ, как показано на рисунке.

         B
      1 /|
       / |
S     A  |1
       \ |
      1 \|
         C


При обнаружении этого отказа узел A сменит следующий интервал на B (который продолжает анонсировать маршрут к S с метрикой 2), анонсирует метрику 3, а затем – новый маршрут с метрикой 3. Этот процесс смены выбранных соседей и увеличения их метрики продолжается, пока метрика не станет «бесконечной» (значение превысит все другие метрики, которые протокол маршрутизации способен передавать).

2.4. Условия осуществимости

Алгоритм Bellman-Ford очень устойчив к отказам и его свойства сходимости сохраняются при задержке маршрутизаторами получения маршрутов или отбрасывании некоторых обновлений. Маршрутизаторы Babel отбрасывают полученные анонсы маршрутов, пока они не уверены, что восприятие маршрута не создаст петли. Более формально, определяется условие, когда анонсы маршрутов, известные как «условие осуществимости» (feasibility condition), гарантируют отсутствие маршрутных петель, где все маршрутизаторы игнорируют обновления, не соответствующие условию осуществимости. Фактически, это возвращает алгоритм Bellman-Ford в семейство алгоритмов маршрутизации, параметризуемых условием выполнимости.

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

Другой пример условия выполнимости применяется в протоколе маршрутизации DSDV [DSDV], а также в протоколе AODV4 [RFC3561] и основан на наблюдении, что маршрутные петли могут возникать лишь после переключения маршрутизатора на маршрут, метрика которого больше выбранного ранее маршрута. Поэтому можно считать маршрута выполнимым, когда его метрика на локальном узле будет не больше метрики выбранного с маршрута, т. е. анонс с метрикой D(B) воспринимается узлом A, когда C(A, B) + D(B) <= D(A). Если все маршрутизаторы следуют этому ограничению, метрика на каждом маршрутизаторе не возрастает и всегда сохраняется следующий инвариант: если A выбрал B как следующий интервал, то D(B) < D(A), что означает отсутствие петель в графе пересылки.

Babel использует более тонкое условие выполнимости, выведенное из EIGRP [DUAL]. Для маршрутизатора A, определяется дистанция выполнимости (достижимости) A FD(A), как меньшая из метрик, анонсируемая A для S любому из своих соседей. Обновление переданное соседом B считается выполнимым, если анонсируемая узлом B метрика D(B) строго меньше дистанции достижимости A, т. е. D(B) < FD(A).

Легко видеть, что это условие не более ограничительно по сравнению с DSDV. Предположим, что узел A выполняет условие достижимости DSDV. Тогда D(A) не возрастает и в любой момент D(A) <= FD(A). Далее предположим, что A получает соответствующее условию DSDV обновление с анонсом метрики D(B). Поскольку обновление соответствует DSDV, C(A, B) + D(B) <= D(A), следовательно D(B) < D(A), а, поскольку D(A) <= FD(A), то и D(B) < FD(A). Чтобы увидеть, что это меньшее ограничение, рассмотрим приведенный ниже рисунок, где A выбрал маршрут через B и D(A) = FD(A) = 2. Поскольку D(C) = 1 < FD(A), маршрут через C достижим для A, хотя его метрика C(A, C) + D(C) = 5 больше чем для выбранного в данный момент маршрута.

   B
1 / \ 1
 /   \
S     A
 \   /
1 \ / 4
   C


Чтобы показать, что условие выполнимости сохраняет гарантию отсутствия петель, напомним, что с тот момент, когда A воспринимает обновление от B, анонсируемая B метрика D(B) не меньше FD(B), поскольку она меньше FD(A), в этот момент FD(B) < FD(A). Поскольку это свойство сохраняется, когда A передает обновления и выбирает другой следующий интервал, это будет верно всегда и гарантирует отсутствие петель в графе пересылки.

2.5. Решение проблемы истощения – нумерованные маршруты

Обычно определенное выше условие осуществимости вызывает истощение (starvation), когда у маршрутизатора не остается доступных маршрутов. Рассмотрим показанную на рисунке ситуацию, где A и B выбрали прямой маршрут к S.

   A
1 /|        D(A) = 1
 / |       FD(A) = 1
S  |1
 \ |        D(B) = 2
2 \|       FD(B) = 2
   B


Предположим, что канал между A и S оказался разорван.

   A
   |
   |       FD(A) = 1
S  |1
 \ |        D(B) = 2
2 \|       FD(B) = 2
   B


Единственный маршрут от A до S, проходящий через B, не является осуществимым и страдает от ложного истощения. В этот момент все субдерево, страдающее от истощения, должно быть сброшено, что, по сути, и делает EIGRP при выполнении глобальной синхронизации всех маршрутов в истощенном субдереве («активная» фаза EIGRP).

Babel менее резко реагирует на истощение, используя нумерованные маршруты, введенные в DSDV и адаптированные AODV. В дополнение к метрике каждый маршрут имеет порядковый номер, который является неубывающим целым числом, распространяемым через сеть без изменения и инкрементируемым лишь источником. Пара (s, m), где s – порядковый номер, а m – метрика, называется дистанцией (расстоянием).

Полученное обновление выполнимо если оно новее дистанции достижимости, поддерживаемой принимающим узлом или столь же свежее и его метрика строго меньше. Более формально, если FD(A) = (s, m), обновление с дистанцией (s’, m’) выполнимо, если s’ > s или s = s’ и m’ < m.

Предположим, что S имеет порядковый номер 137. Тогда приведенный выше рисунок примет вид

      A
      |
      |       FD(A) = (137, 1)
   S  |1
    \ |        D(B) = (137, 2)
   2 \|       FD(B) = (137, 2)
      B


После того, как S увеличит свой порядковый номер и новый номер будет распространен узлу B, мы получим

   A
   |
   |       FD(A) = (137, 1)
S  |1
 \ |        D(B) = (138, 2)
2 \|       FD(B) = (138, 2)
   B


И маршрут через B становится выполнимым.

Отметим, что порядковые номера используются для определения достижимости, но они не применяются при выборе маршрутов. Узел игнорирует порядковые номера в процессе определения лучшего маршрута к данному адресату (параграф 3.6). Иное поведение вызвало бы осцилляции маршрутов при распространении порядкового номера через сеть и могло бы даже создать постоянные «черные дыры» с экзотической метрикой.

2.6. Запросы

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

Babel использует другой подход. Когда узел обнаруживает, что он страдает от потенциально ложного истощения, этот узел передает явный запрос источнику для получения нового порядкового номера. Этот запрос пересылается поэтапно (hop by hop) к источнику, независимо от условия выполнимости. При получении запроса источник увеличивает свой порядковый номер и в широковещательном режиме передает обновление, которое пересылается запросившему узлу.

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

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

2.7. Префикс от нескольких маршрутизаторов

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

Поскольку синхронизация порядковых номеров между маршрутизаторами проблематична, Babel считает маршруты к одному префиксу разными сущностями, когда они приходят от разных маршрутизаторов. Каждый анонс маршрутов содержит router-id создавшего его маршрутизатора, а дистанции выполнимости поддерживаются не на уровне префикса, а на уровне источника, который представляет собой пару (router-id – префикс). Фактически Babel гарантирует отсутствие петель в графе пересылки для каждого источника. Поскольку объединение множества ациклических графов не всегда является ациклическим, Babel не гарантирует отсутствия петель в случае происхождения префикса от нескольких маршрутизаторов, но любые петли устраняются на время, пропорциональное диаметру петли, когда обновление «обойдет петлю».

Рассмотрим показанную ниже топологию, где узел A выбрал маршрут по умолчанию через S, а B – через S’.

           1     1     1
::/0 -- S --- A --- B --- S' -- ::/0


Предположим, что одновременно отказали оба принятых по умолчанию маршрута. В этом случае ничто не мешает узлу A переключиться на B, а B – одновременно переключиться на A. Однако, как только A успешно анонсирует новый маршрут узлу B, маршрут через A станет невыполнимым для B. И наоборот, как только B анонсирует свой маршрут через A, маршрут через B станет невыполнимым для A.

Фактически петля исчезает не позднее прохождения маршрутной информации через нее. Поскольку этот процесс может быть задержан потерей пакетов, Babel прилагает некоторые усилия для обеспечения гарантированной доставки обновлений после смены router-id (параграф 3.7.2).

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

2.8. Перекрывающиеся префиксы

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

После отказа маршрута в общем случае некорректно переключаться на маршрут, включающий отказавший. Рассмотрим показанный на рисунке пример.

           1     1
::/0 -- A --- B --- C


Предположим, что узел C отказал. Если B пересылает пакеты для C по принятому по умолчанию маршруту, возникнет петля, которая будет сохраняться, пока A не узнает об отсутствии у B прямого маршрута к C. Узел B избегает этой ловушки, устанавливая «невыполнимый» маршрут после вызванного отказом пропадания маршрута. Этот маршрут поддерживается, пока не будет гарантии, что утраченный маршрут отменен всеми соседями B (параграф 3.5.4).

3. Работа протокола

Каждый узел Babel (speaker) имеет свой идентификатор (router-id) – произвольную стороку размером 8 октетов, которая предполагается уникальной в домене маршрутизации. Идентификаторы могут выделяться, например, случайным образом или выводиться из адресов канального уровня. Кодирование протокола становиться чуть более компактным при выделении router-id в стиле присвоения идентификаторов узлов IPv6 (см. описание флага R в параграфе 4.6.9.).

3.1. Передача и прием сообщений

Пакеты протокола Babel передаются в теле дейтаграмм UDP (раздел 4). Каждый пакет Babel может содержать множество (возможно пустое) TLV, большинство из которых могут включать суб-TLV.

Трафик управления Babel может передаваться по протоколу IPv6 или IPv4, а префиксы любого семейства адресов могут анонсироваться через любой протокол. Таким образом, имеется по меньшей мере две модели естественного развртывания – использование исключительно IPv6 для всего трафика управления или работа двух разных экземпляров протокола, по одному для каждого семейства адресов. Рекомендуется применять исключительное использование IPv6 для всего управляющего трафика, поскольку одновременное применение двух протоколов удваивает трафик, предназначенный для обнаружения соседей и оценки качества каналов.

Адресом отправителя пакетов Babel всегда является индивидуальный адрес (link-local в случае IPv6). Пакеты Babel могут передаваться по стандартному (link-local) групповому или индивидуальному (link-local) адресу. При обычной работе узел Babel передает своим соседям групповые и индивидуальные пакеты.

За исключением подтверждений, все Babel TLV могут передаваться по групповому или индивидуальному адресу и семантика TLV от этого не зависит. Поэтому узлу Babel не требуется определять адрес получателя в принятом пакете для его интерпретации.

К передаваемым узлом Babel пакетам могут применяться произвольные вариации задержки (jitter). Исходящие TLV буферизуются и их следует передавать со случайной задержкой. Это преследует две цели – избежать синхронизации узлов Babel в сети [JITTER] и обеспечить возможность объединения множества TLV в один пакет.

Максимальная задержка TLV может зависеть от TLV. Когда описание протокола указывает срочность TLV (параграфы 3.7.2 и 3.8.1), такие TLV должны передаваться в течение короткого времени, называемого тайм-аутом срочности (urgent timeout), рекомендуемые значения тайм-аута приведены в Приложении B. Когда TLV регулируется тайм-аутом, заданным в предшествующем TLV, как в случае подтверждений (параграф 4.6.4), обновлений (параграф 3.7) и IHU (параграф 3.4.2), TLV должны передаваться достаточно быстро, чтобы уложиться в указанное время (с небольшим запасом на задержку распространения). В остальных случаях TLV следует отправлять в течение половины интервала Multicast Hello.

Для предотвращения отбрасывания пакетов (отправителем или получателем) следует вносить задержку между последовательными пакетами с одного интерфейса с учетом ограничений, указанных выше. Однако следует отметить, что задержка может препятствовать возможности агрегирования пакетов для некоторых канальных технологий (например, IEEE 802.11 [IEEE802.11]).

3.2. Структуры данных

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

3.2.1. Арифметика порядковых номеров

Порядковые номера (seqno) включаются во многие структуры данных Babel и интерпретируются как целые числа с модулем 216. Используемая в этом документе арифметика порядковых номеров описана ниже.

Для данного порядкового номера s и неотрицательного целого числа n сумма s и n определяется выражением

      s + n (по модулю 216) = (s + n) MOD 2^(16)

или его эквивалентом

      s + n (по модулю 216) = (s + n) AND 65535

где MOD операция деления по модулю, дающая неотрицательное целое число, а AND побитовое пересечение (И). Для двух порядковых номеров s и s’ отношение s меньше s’ (s < s’) определяется выражением

      s < s' (по модулю 216), когда 0 < ((s' - s) MOD 2^(16)) < 32768

или его эквивалентом

      s < s' (по модулю 216), когда s /= s' и ((s' - s) AND 32768) = 0.

3.2.2. Порядковый номер узла

Порядковый номер узла – это 16-битовое целое число, включаемое в обновления, передаваемые для маршрутов, исходящих из этого узла.

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

3.2.3. Таблица интерфейсов

Таблица интерфейсов содержит список всех интерфейсов, на которых узел использует протокол Babel. Каждая запись таблицы включает порядковый номер исходящего Multicast Hello (16-битовое целое число, которое передается в каждом Multicast Hello TLV на этом интерфейсе и инкрементируется с модулем 216 при передаче Multicast Hello). Отметим, что порядковый номер Multicast Hello не связан с порядковым номером узла.

С каждой записью в таблице интерфейсов связано два таймера. Таймер периодических сообщений Multicast Hello управляет плановой отправкой пакетов Multicast Hello и IHU (параграф 3.4). Таймер периодических обновлений (Update) управляет периодической отправкой маршрутных обновлений (параграф 3.7.1). Рекомендуемые значения для таймеров приведены в Приложении B.

3.2.4. Таблица соседей

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

  • интерфейс локального узла, через который доступен этот сосед;

  • адрес интерфейса соседа;

  • историю недавно принятых пакетов Multicast Hello от этого соседа (это может быть, например, последовательность из n битов с небольшим n, указывающая какие из последних n сообщений hello от данного соседа были приняты локальным узлом);

  • история недавно полученных сообщений Unicast Hello от этого соседа;

  • значение «стоимости передачи» из последнего пакета IHU, полученного от этого соседа, или шестнадцатеричное значение FFFF (бесконечность), если истек таймер IHU для данного соседа;

  • ожидаемый порядковый номер Multicast Hello от этого соседа (целое число с модулем 216);

  • ожидаемый порядковый номер Unicast Hello от этого соседа (целое число с модулем 216);

  • порядковый номер исходящего Unicast Hello для этого соседа (целое число с модулем 216), передаваемый в каждом Unicast Hello TLV и инкрементируемый (модуль 216) при отправке Unicast Hello (отметим, что номер исходящего Unicast Hello для соседа отличается от номера исходящего Multicast Hello для интерфейса).

С каждой записью таблицы связано три таймера – Multicast Hello, задающий интервал, передаваемый в плановых Multicast Hello TLV от этого соседа, Unicast Hello с интервалом из плановых Unicast Hello TLV и IHU со значением, кратным (в несколько раз) интервалу из IHU TLV (см. Приложение B).

Отметим, что таблица соседей индексируется по адресам IP, а не router-id, поскольку смежность существует между интерфейсами, а не узлами. Поэтому два узла с несколькими интерфейсами могут иметь несколько отношений смежности, что часто возникает в беспроводных сетях, где участвуют узлы с несколькими радио-модулями.

3.2.5. Таблица источников

Таблица источников служит для записи дистанций выполнимости (feasibility distance) и индексируется триплетами (prefix, plen, router-id). Каждая запись таблицы включает:

  • префикс (prefix, plen), где plen указывает размер префикса в битах, применимый к этой записи;

  • router-id маршрутизатора, от которого исходит этот префикс;

  • пару (seqno, metric), указывающую дистанцию выполнимости для этого источника.

С каждой записью связан таймер «сборки мусора» (garbage-collection), имеющий значение порядка минут и сбрасываемый в соответствии с параграфом 3.7.3.

3.2.6. Таблица маршрутов

Таблица маршрутов содержит известные узлу маршруты и индексируется триплетом (prefix, plen, neighbour). Каждая запись таблицы включает:

  • источник (prefix, plen, router-id) для которого анонсирован этот маршрут;

  • сосед neighbour (запись в таблице соседей), анонсировавший этот маршрут;

  • метрика, с которой маршрут анонсирован соседом, или шестнадцатеричное значение FFFF (бесконечность) для недавно утраченного маршрута;

  • порядковый номер, с которым маршрут анонсирован;

  • адрес next-hop для этого маршрута;

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

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

Отметим, что с каждым маршрутом связаны две разных пары (seqno, metric), одна из которых указывает дистанцию (протяженность) маршрута в таблице, другая – дистанцию выполнимости, которая хранится в таблице источников и используется для всех маршрутов с данным источником.

3.2.7. Таблица ожидающих запросов порядковых номеров

Таблица ожидающих запросов seqno содержит список запросов порядкового номера, которые передал локальный узел (порождены локально или пересланы), но ответы еще не были получены. Таблица индексируется триплетом (prefix, plen, router-id) и каждая запись содержит:

  • prefix, plen, router-id и seqno из запроса;

  • сосед, для которого пересылался запрос (при наличии);

  • небольшое целое число, указывающее повторов, если запрос не был выполнен.

С каждой записбю связан таймер, управляющий повтором запроса и сроком его действия.

3.3. Подтверждения и запросы подтверждений

Узел Babel может запросить у соседа явного подтверждения приема отправленного тому пакета. Хотя использование подтверждений не обязательно, каждый узел Babel должен поддерживать возможность ответа на такие запросы.

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

Передача запросов на подтверждение определяется локальной политикой. Простейшая стратегия – никогда не запрашивать подтверждений и полагаться на периодические обновления в качестве гарантии того, что все доступные маршруты в конечном итоге распространяются по всему домену маршрутизации. Для повышения скорости схождения и снижения объема трафика управления запросы подтверждения могут служить для надежной отправки срочных обновлений (параграф 3.7.2) и отзывов (параграф 3.5.4), особенно при небольшом числе соседей на данном интерфейсе. Поскольку протокол Babel разработан для корректной работы при потере пакетов в ненадежных средах, отправка всех пакетов с запросом подтверждения не обязательна и не рекомендуется, поскольку подтверждения создают дополнительный трафик и могут вызывать дополнительный обмен ARP (Address Resolution Protocol) или ND (Neighbour Discovery).

3.4. Нахождение соседей

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

До того как узел Babel сможет обмениваться маршрутными данными с соседом, он должен создать для этого соседа запись в своей таблице соседей. Когда это следует делать, определяет реализация и приемлемые стратегии включают создание записи при получении любого пакета Babel или при анализе Hello TLV. Для экономии системных ресурсов реализации следует отбрасывать записи, которые не используются слишком долго. Приемлемой стратегией является отбрасывание соседей по тайм-ауту или при пустой истории соответствующих сообщений Hello (см. Приложение A.2).

3.4.1. Определение обратной достижимости

Каждый узел Babel регулярно или не регулярно передает своим соседям Hello TLV для индикации свое активности. В каждом Hello TLV содержится увеличивающийся (модуль 216) порядковый номер и верхняя граница интервала отправки следующего Hello того же типа (см. ниже). Если установлен интервал 0, Hello TLV не указывает нового «обещания». При этом интервал из предыдущего Hello того же типа остается в силе для следующего Hello (если недавнее сообщение Hello нужного типа было получено в момент t0 и включало интервал i, прежнее обещание передать Hello до момента t0 + i остается в силе). Сообщения Hello считаются «плановыми», если они включают отличный от 0 интервал.

Имеется два типа Hello – Multicast Hello, использующие счетчик Hello на уровне интерфейса (Multicast Hello seqno), и Unicast Hello со счетчиком для соседа (Unicast Hello seqno). Сообщения Multicast Hello с данным seqno должны передаваться всем соседям на данном интерфейсе путем отправки по групповому адресу или по индивидуальным адресам каждого соседа (т. е. название Multicast Hello является не совсем точным). Unicast Hello с данным given обычно следует передавать лишь одному соседу (по индивидуальному адресу), поскольку порядковые номера для разных соседей в общем случае не синхронизированы.

Multicast Hello, переданные по групповому адресу могут служить для обнаружения соседей. Узлу следует передавать периодические (плановые) Multicast Hellos, если обнаружение соседей не выполняется вне протокола Babel. Узел может передавать Unicast Hello или неплановые Hello любого типа по любой причине, например для снижения группового трафика или повышения надежности на каналах со слабой поддержкой групповой адресации.

Узел может передать плановое сообщение Hello заранее, а также может изменить запланированный интервал Hello. Интервал Hello можно сократить в любой момент, а также можно увеличить непосредственно перед отправкой Hello TLV, но не следует увеличивать в другие моменты (эквивалентно, узлу следует передать плановые Hello сразу после увеличения интервала Hello).

Что делать с полученными Hello TLV и какую статистику для них поддерживать, определяет локальная реализация. Обычно узлы поддерживают тот или иной тип истории недавно принятых Hello. Пример подходящего алгоритма представлен в Приложении A.1.

После приема Hello или определения его пропуска узел пересчитывает стоимость ассоциации (параграф 3.4.3) и запускает процедуру выбора маршрута (параграф 3.6).

3.4.2. Двухстороннее определение достижимости

Для организации двухсторонней доступности каждый узел периодически передает IHU TLV (я вас слышу) каждому из своих соседей. Поскольку IHU содержат явный интервал, их можно передавать реже, чем Hello для снижения уровня маршрутного трафика в плотных сетях. В частности, их следует передавать реже Hello на каналах с незначительными потерями. Хотя IHU концептуально являются индивидуальными, их можно передавать по групповому адресу, чтобы избежать лишних обменой ARP или Neighbour Discovery и агрегировать множество IHU в один пакет.

В дополнение к периодическим IHU узел может в любой момент передать неплановый пакет IHU. Узел также может в любой момент снизить интервал IHU и может увеличить этот интервал непосредственно перед отправкой IHU, но не следует увеличивать интервал в другие моменты (эквивалентно, узлу следует передавать дополнительные IHU сразу после увеличения интервала Hello).

В каждом IHU TLV содержатся две части данных – rxcost для канала (стоимость приема) с точки зрения отправителя, используемое соседом для расчета стоимости канала (параграф 3.4.3), и интервал между периодическими пакетами IHU. Принявший IHU узел устанавливает значение txcost (стоимость передачи), поддерживаемое в таблице соседей, в соответствии со значением в IHU и сбрасывает таймер IHU, связанный с данным соседом, до значения кратного (в несколько раз) интервалу, полученному в IHU (см. Приложение B). По истечении таймера IHU для соседского txcost устанавливается бесконечное значение.

После обновления соседского txcost принимающий узел пересчитывает стоимость для соседа (параграф 3.4.3) и запускает процедуру выбора маршрута (параграф 3.6).

3.4.3. Расчет стоимости

Стоимость канала к соседу (neighbourship association) рассчитывается по значениям из таблицы соседей, где хранится статистика приема Hello и значения txcost, рассчитанные из пакетов IHU.

Для каждого соседа узел Babel рассчитывает значения, называемое rxcost. Оно обычно выводится из статистики Hello, которая может комбинироваться с другими данными, такими как статистика канального уровня. Значение rxcost передается соседу в каждом IHU.

Поскольку узлы не обязательно передают периодические Unicast Hello, но обычно передают Multicast Hello (параграф 3.4.1), узлу следует использовать алгоритм, который дает конечное значение rxcost, когда имеются лишь Multicast Hello, если не требуется взаимодействие лишь с узлами, которые передают только Multicast Hello.

Использование txcost и rxcost при расчете стоимости канала определяется локальными правилами. Для корректности работы Babel должны выполняться приведенные ниже условия:

  • значение стоимости всегда положительно;

  • если недавно не было принято Hello TLV любого типа, стоимость будет бесконечной;

  • если txcost имеет бесконечное значение, стоимость будет бесконечной.

Рекомендуемая стратегия расчета стоимости канал приведена в Приложении A.2.

3.5. Поддержка таблицы маршрутизации

Концептуально обновления Babel задает квинтет (prefix, plen, router-id, seqno, metric), где (prefix, plen) – префикс для маршрута, router-id – идентификатор маршрутизатора, создавшего обновление, seqno – не уменьшающееся целое число (модуль 216) – порядковый номер маршрутизатора-источника, metric – анонсируемая метрика.

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

3.5.1. Условие осуществимости

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

Дистанция выполнимости задается парой (seqno, metric), где seqno – целое число с модулем 216, а метрика – положительное целое число. Дистанции сравниваются лексикографически с инвертированием номера – дистанция (seqno, metric) считается строго лучше (seqno’, metric’), что записывается в форме

      (seqno, metric) < (seqno', metric')

когда

      seqno > seqno' или (seqno = seqno' и metric < metric')

где порядковые номера сравниваются по модулю 216.

С данным источником (prefix, plen, router-id) дистанция выполнимости узла для этого источника будет минимальной (в соответствии с определенным выше порядком) среди дистанций из всех конечных обновлений, когда-либо переданных этим узлом для префикса (prefix, plen) и данного router-id. Дистанции выполнимости хранятся в таблице источников, как описано в параграфе 3.7.3.

Принятое обновление выполнимо, если оно является отзывом (метрика имеет шестнадцатеричное значение FFFF) или анонсируемая дистанция строго лучше (в соответствии с приведенным выше определением) дистанции выполнимости для соответствующего источника. Точнее говоря, анонс маршрута в (prefix, plen, router-id, seqno, metric) выполним, при выполнении одного из приведенных ниже условий:

  • метрика конечна;

  • нет записи с таблице источников с индексом (prefix, plen, router-id);

  • в таблице источников имеется запись (prefix, plen, router-id, seqno’, metric’) и выполняется одно из условий:

    • seqno’ < seqno;

    • seqno = seqno’ и metric < metric’.

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

3.5.2. Расчет метрики

Метрика маршрута рассчитывается из метрики, анонсированной соседом, и стоимости канала к соседу. Подобно расчету стоимости, вычисление метрики определяется локальной политикой. Используемая Babel функция расчета метрики M(c, m) по локально рассчитанной стоимости канала c и анонсированной соседом метрике m должна лишь соответствовать двум условиям:

  • если стоимость c бесконечная, M(c, m) также бесконечна;

  • функция M является строго монотонной, M(c, m) > m.

Кроме того, для метрики следует выполнять условие

   если m <= m', то M(c, m) <= M(c, m')

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

Приведенные выше условия легко выполняются при использовании аддитивной метрики, т. е. при определении M(c, m) = c + m. Поскольку аддитивная метрика полезна для многий вариантов расчета стоимости, рекомендуется применять ее по умолчанию. В Приложении C описаны методы, позволяющие менять значения той или иной метрики без риска возникновения маршрутных петель.

3.5.3. Получение маршрутов

Когда узел Babel получает обновление (prefix, plen, router-id, seqno, metric) от соседа neigh, он проверяет наличие в таблице маршрутов записи с индексом (prefix, plen, neigh). Если такой записи нет, выполняются следующие операции:

  • если обновление невыполнимо, его можно игнорировать;

  • если метрика бесконечна (обновление служит отзывом неизвестного маршрута), обновление игнорируется;

  • в остальных случаях в таблицу маршрутов включается новая запись с индексом (prefix, plen, neigh), источником (prefix, plen, router-id), порядковым номером seqno и анонсируемой метрикой из обновления.

Если запись имеется в таблице, выполняются следующие операции:

  • если запись выбрана, обновление невыполнимо и router-id в обновлении совпадает с идентификатором маршрутизатора в записи, эту запись можно игнорировать;

  • в остальных случаях порядковый номер записи, анонсируемая метрика, метрика и router-id одновляются, даже когда для таймера срока действия маршрута установлено значение кратное (в несколько раз) интервалу, включенному в обновление (см. Приложение B). Если обновление невыполнимо, запись (невыполнимая) должна незамедлительно стать не выбранной. Если обновление вызвало смену router-id в записи, должно быть передано своевременное уведомление (возможно отзыв), как указано в параграфе 3.7.2.

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

При срабатывании таймера срока действия маршрута поведение за висит от конечности метрики маршрута. Если метрика конечна, для нее устанавливается бесконечное значение и таймер сбрасывается. Если же метрика уже является бесконечной, маршрут удаляется из таблицы.

После обновления таблицы маршрутов запускается процедура выбора (параграф 3.6).

3.5.4. Время удержания

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

Для предотвращения этой проблемы при отзыве префикса P поддерживается запись таблицы маршрутов с бесконечной метрикой, как описано в параграфе 3.5.3. Пока запись поддерживается, пакеты с адресом из P недопустимо пересылать по маршруту с более коротким префиксом. Запись удаляется из таблицы, как только будут получено обновление для P с конечной метрикой и выбран соответствующий маршрут. Если такого обновления не ожидается, бесконечную метрику следует поддерживать по меньшей мере до того момента, пока не будет гарантии, что ни один сосед не выбрал текущий узел в качестве следующего интервала (next-hop) для префикса P. Это можно сделать любым из двух способов:

  • дождаться завершения срока действия маршрута по таймеру (параграф 3.5.3);

  • передать отзыв с запросом подтверждения (параграф 3.3) каждому доступному соседу, который явно не отозвал префикс P, и дождаться всех подтверждений.

Первый вариант проще и гарантирует, что в этот момент для всех маршрутов к префиксу P, указывающих на текущий узел, срок действия закончился. Однако, поскольку срок действия может быть достаточно большим (несколько минут), такое решение препятствует автоматическому агрегированию, создавая ложные «черные дыры» для агрегированных маршрутов. Рекомендуется применять второй вариант, поскольку он значительно сокращает время недоступности префикса при наличии агрегированных маршрутов.

3.6. Выбор маршрута

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

Протокол Babel поддерживает гибкие правила выбора маршрутов, при этом должны обеспечиваться два свойства:

  • маршруты с бесконечной метрикой (отозванные маршруты) никогда не выбираются;

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

Узлы Babel с разными правилами выбора могут взаимодействовать и не будут создавать петель при выполнении этих условий.

При выборе маршрутов недопустим учет порядковых номеров и недопустимо отдавать предпочтение маршруту с большим (более новым) seqno. Отказ от этого будет приводить к осцилляциям маршрутов при распространении нового номера по сети и может вызывать сохраняющиеся «черные дыры», если используемая метрика не дистрибутивна слева (параграф 3.5.2).

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

Для предотвращения такой нестабильности в стратегию выбора маршрута следует включать гистерезис, т. е. учитывать историю маршрута и менять выбранный маршрут на другой, если тот был лучше в течение некоторого времени. Рекомендуемый алгоритм гистерезиса представлен в Приложении A.3.

После выбора маршрута передаются триггерные уведомления (параграф 3.7.2) и запросы (параграф 3.8.2).

3.7. Передача обновлений

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

Кроме того, для надежного и своевременного устранения «черных дыр» узел Babel может передавать отзывы (обновления с бесконечной метрикой) для недавно отозванных префиксов. Если обновление предназначено для маршрута, внесенного в домен Babel локальным узлом (например, оно содержит адрес локального интерфейса, префикс подключенной напрямую сети или префикс из другого протокола маршрутизации), в качестве router-id указывается идентификатор локального маршрутизатора, для метрики указывается произвольное конечное значение (обычно 0) и включается порядковый номер локального маршрутизатора.

Если обновление предназначено для маршрута от другого узла Babel, router-id и порядковый номер берутся из записи таблицы маршрутов, а метрика рассчитывается в соответствии с параграфом 3.5.2.

3.7.1. Периодические обновления

Каждый узел Babel должен анонсировать каждый из выбранных маршрутов на каждом интерфейсе хотя бы один раз в каждый интервал Update. Поскольку в Babel не возникает проблем от маршрутных петель (не требуется «счет до бесконечности») и протокол основан на триггерных обновлениях (параграф 3.7.2), полная передача маршрутов происходит достаточно редко (интервалы предложены в Приложении B).

3.7.2. Триггерные обновления

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

Изменение router-id в выбранном маршруте для данного префикса может служить индикацией образующейся петли, поэтому при каждой смене router-id для данного адресата узел должен передать обновление как срочный блок TLV (см. параграф 3.1). Кроме того, следует предпринять разумные попытки обеспечить получение этого обновления всеми соседями.

Для этого есть две стратегии. Если число соседей невелико, разумно передать обновление с запросом подтверждения, которое будет повторяться несколько раз, пока все соседи не подтвердят прием пакета. При большом числе соседей такой запрос подтверждений может вызвать ощутимый трафик и более предпочтительным вариантом может оказаться простое повторение обновления несколько раз (скажем, 3 для беспроводных сетей или 2 для кабельных). Недопустимо передавать больше 5 копий и их следует разделять небольшим интервалом (параграф 3.1).

Отзыв маршрута вызывает меньше беспокойства – если он придет не всем соседям, может возникнуть «черная дыра», которая, в отличие от петли, не представляет опасности для целостности сети. При отзыве маршрута узлу следует передать триггерное обновление, а также следует предпринять разумные попытки доставить его всем соседям.

Узел может передавать триггерное уведомление при существенном изменении метрики для данного префикса в результате получения обновления, изменения стоимости канала или выбора другого следующего узла (next-hop). Узлу не следует передавать триггерные обновления по иным причинам, таким как незначительные флуктуации метрики маршрутов, смене next-hop без существенного изменения метрики маршрута или распространении нового порядкового номера (за исключением выполнения запроса, как указано в параграфе 3.8).

3.7.3. Поддержка дистанций достижимости

Перед отправкой обновления (prefix, plen, router-id, seqno, metric) с конечной метрикой (т. е. не отзыва) узел Babel обновляет дистанцию выполнимости в таблице источников, как описано ниже.

Если в таблице источников нет записи с индексом (prefix, plen, router-id), создается запись со значениями(prefix, plen, router-id, seqno, metric). Если имеется запись (prefix, plen, router-id, seqno’, metric’) она обновляется:

  • если seqno > seqno’, устанавливается seqno’ := seqno, metric’ := metric;

  • если seqno = seqno’ и metric’ > metric, устанавливается metric’ := metric;

  • в остальных случаях ничего не меняется.

Для записи сбрасывается таймер сборки мусора. Отметим, что дистанция выполнимости не обновляется и таймер сборки мусора не сбрасывается при отправке отзыва маршрута (обновления с бесконечной метрикой).

По завершении отсчета таймера сборки мусора запись удаляется из таблицы источников.

3.7.4. Расщепление горизонта

При работе в транзитивной топологии с симметричными каналами (например, соединения «точка-точка» или проводная ЛВС, такая как Ethernet) узлу Babel следует использовать оптимизацию, называемую «расщеплением горизонта» (split horizon). При использовании ее на данном интерфейсе маршрутные обновления для префикса P не передаются на интерфейс, через который был получен выбранных маршрут в направлении префикса P.

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

3.8. Явные запросы

При обычной работе таблица маршрутов узла заполняется из плановых и триггерных обновлений от соседей. Однако в некоторых обстоятельствах узел может передавать явные запросы для ресинхронизации с источником после перемещения (mobility event) или для предотвращения ненужного завершения срока действия маршрута.

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

3.8.1. Обработка запросов

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

3.8.1.1. Запросы маршрутов

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

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

3.8.1.2. Запросы порядковых номеров

При получении запроса seqno для данного router-id и порядкового номера узел ищет в своей таблице маршрутов выбранную запись для данного префикса. Если такая запись присутствует и имеет конечную метрику, а значения router-id различаются или эти значения совпадают, но порядковый номер записи не меньше (по модулю 216) запрошенного порядкового номера, узел должен передать обновление для данного префикса. Если router-id совпадают, но запрошенный порядковый номер больше (по модулю 216) чем в записи для маршрута, узел сравнивает router-id со своим идентификатором. При совпадении узел увеличивает свой порядковый номер на 1 (по модулю 216) и передает обновления. Узлу недопустимо увеличивать своей номер больше чем на 1 в ответ на один запрос seqno.

Если router-id в запросе не совпадает с идентификатором узла, принявший запрос узел проверяет поле Hop Count в запросе. Если поле имеет значение не меньше 2 и узел анонсирует префикс своим соседям, он выбирает соседа для пересылки тому запроса, как указано ниже.

  • Если узел имеет один или несколько выполнимых маршрутов в направлении запрошенного префикса, где next-hop не является запросившим узлом, он должен переслать запрос слудующему маршрутизатору (next-hop).

  • В остальных случаях, если узел имеет один или несколько (невыполнимых) маршрутов к запрошенному префиксу, где next-hop не является запросившим узлом, ему следует переслать этот запрос следующему маршрутизатору на одном из таких маршрутов.

Для фактической пересылки запроса узел декрементирует счетчик интервалов (hop count) и передает запрос по индивидуальному адресу выбранного соседа. Запрос следует пересылать как срочный TLV (параграф 3.1).

Узлу следует поддерживать список недавно пересланных запросов seqno и пересылать отклики на них (обновление с достаточно большим для удовлетворения запроса seqno) как срочные TLV (параграф 3.1). Узлу следует сравнивать каждый входящий запрос seqno со списком недавно пересылавшихся запросов seqno во избежание избыточной пересылки (т. е. он недавно пересылал запрос с тем же префиксом, prefix, router-id и не меньшим seqno по модулю 216).

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

3.8.2. Передача запросов

Узел Babel может отправлять запросы маршрутов и порядковых номеров по групповым и индивидуальным адресам. Отправка запросов требуется лишь в одном случае (параграф 3.8.2.1).

3.8.2.1. Предотвращение истощения

Когда маршрут отозван или закончился срок его действия, узел Babel обычно переключается на другой выполнимый маршрут для того же префикса. Однако в некоторых случаях таких маршрутов может не оказаться. Узел, потерявший все выполнимые маршруты к данному адресату, но имеющий невыполнимые маршруты к нему с не истекшим сроком действия, должен отправить запрос seqno. Если нет даже таких маршрутов, узел все равно может передать запрос seqno. В поле router-id такого запроса указывается router-id из потерянного маршрута, а запрашиваемым номером является значение из таблицы источников, увеличенное на 1. Запрос включает счетчик интервалов, который служит «механизмом последней надежды» (last-resort) для гарантии сохранения узла в сети и может включать любое значение, превышающее диаметр сети (значение 64 приемлемо по умолчанию).

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

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

3.8.2.2. Работа с невыполнимыми обновлениями

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

Для предотвращения ложного завершения срока действия маршрута, ставшего невыполнимым, узлу следует передать индивидуальный запрос seqno при получении невыполнимого обновления для выбранного маршрута. Порядковый номер для запроса рассчитывается по таблице источников, как указано в параграфе 3.8.2.1.

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

3.8.2.3. Предотвращение завершения срока действия маршрутов

При нормальной работе таймер срока действия маршрута не срабатывает никогда, поскольку время удержания маршрута рассчитывается на основе явного интервала из Update TLV и обновления (возможно отзывы) должны поступать своевременно, чтобы избежать завершения срока действия маршрута.

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

4. Кодирование протокола

Пакет Babel должен передаваться как тело дейтаграммы UDP со значением счетчика интервалов сетевого уровня (hop count) 1 по общеизвестному групповому адресу протокола IPv4 или IPv6 (для IPv6 это адреса link-local). Для потов UDP отправителя и получателя должен указываться общеизвестный номер. Пакеты Babel должны игнорироваться, если адресом отправителя не является адрес IPv6 link-local или адрес IPv4, относящийся к локальной сети, а в качестве порта не указан общеизвестный порт Babel. Пакеты могут игнорироваться, если для получателя указан глобальный (маршрутизируемый) адрес IPv6.

Для минимизации числа передаваемых пакетов и предотвращения фрагментации на нижележащих уровнях узлу Babel следует использовать пакеты максимального размера, вплоть для MTU выходного интерфейса с учетом заголовков нижележащего уровня (28 октетов для UDP по протоколу IPv4 и 48 октетов для UDP по протоколу IPv6). Недопустимо передавать пакеты, размер которых превышает большее из значений MTU выходного интерфейса (с учетом нижележащих заголовков) или 512 октетов. В любом случае размер пакета не может быть больше 216 – 1 с учетом заголовков нижележащего уровня. Каждый узел Babel должен поддерживать прием пакетов размером до большего из значений MTU приемного интерфейса с учетом заголовков нижележащего уровня или 512 октетов. Недопустимо передавать пакеты Babel в джамбограммах IPv6 [RFC2675].

4.1. Типы данных

4.1.1. Представление целых чисел

Многооктетные поля, представляющие целые числа начинаются со старшего октета (формат Big-Endian [IEN137], называемый также сетевым порядком байтов). Базовый протокол использует лишь значения без знака. Если расширению потребуются числа со знаком, оно должно будет задать кодирование (например, дополнение до 2).

4.1.2. Интервалы

Относительные значения времени указываются 16-битовыми числами в сотых долях секунды (centisecond). Это позволяет задать интервалы приблизительно до 11 минут с шагом 10 мсек., что должно быть достаточно для всех применений Babel (см. Прилжение B).

4.1.3. Идентификаторы маршрутизаторов

Идентификатор router-id представляет собой произвольной значение размером 8 октетов. Недопустимо использовать для router-id значения, содержащие только нули (шестнадцатеричное 0000000000000000) или только единицы (шестнадцатеричное FFFFFFFFFFFFFFFF).

4.1.4. Адреса

Поскольку основная работа протокола выполняется с адресами, поддерживается несколько типов их кодирования. Кроме того, в Update TLV может опускаться маска подсети при передаче множества адресов в одном пакете, это называется сжатием адресов (параграф 4.6.9). Варианты кодирования адресов приведены ниже.

AE 0

Шаблонный адрес (строка октетов размером 0).

AE 1

Адрес IPv4 (до 4 октетов).

AE 2

Адрес IPv6 с поддержкой сжатия (до 16 октетов).

AE 3

Адрес IPv6 link-local без сжатия (8 октетов, предполагается префикс fe80::/64).

Семейством адресов, связанным с форматом представления является IPv4 или IPv6. Семейство не определено для AE 0, IPv4 для AE 1 и IPv6 для AE 2 и AE 3.

4.1.5. Префиксы

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

4.2. Формат пакетов

Пакет Babel состоит из 4-октетного заголовка, за которым следует набор TLV (тело пакета) и может следовать еще один набор TLV (трейлер).Формат является расширяемым (см. Приложение D).

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Magic     |    Version    |        Body length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Packet Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|         Packet Trailer...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Magic

Тщательно подобранное произвольное значение 42 (десятичное). Пакеты, в которых первый октет имеет другое значение должны игнорироваться.

Version

Этот документ задает версию 2 протокола Babel. Пакеты, в которых второй октет имеет другое значение должны игнорироваться.

Body length

Размер следующего за заголовком тела пакета (без учета полей Magic, Version, Body length, а также трейлера) в октетах.

Packet Body

Тело пакета, представляющее собой последовательность TLV.

Packet Trailer

Трейлер пакета, содержащий последовательность TLV.

Телом и трейлером пакета служат цепочки TLV. Обычно TLV помещаются в тело пакета, а трейлеры применяются лишь для особых TLV, которые не требуют криптографической защиты. При анализе трейлера получатель должен игнорировать все TLV, в определениях которых явно не указана возможность размещения в трейлере. Из числа определенных в документе TLV таковыми являются лишь Pad1 и PadN. Поскольку эти TLV в любом случае игнорируются, реализация может полностью игнорировать трейлер, даже не анализируя его, пока не используется расширений, определяющих другие TLV для включения в трейлер.

4.3. Формат TLV

Все TLV, за исключением Pad1, имеют показанную на рисунке структуру.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Payload...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Type

Тип TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Payload

Данные TLV (payload), которые представляют собой тело, а в некоторых случаях – набор суб-TLV.

TLV неизвестного типа должны игнорироваться.

4.4. Формат суб-TLV

В заголовке каждого TLV явно указывается размер, однако большинство TLV являются самозавершающими в том смысле, что можно определить размер без явного обращения к полю Length. Если TLV имеет самозавершающий формат, пространство между естественным размером TLV и значением в поле Length может применяться для включения sub-TLV.

Структура суб-TLV не отличается от структры TLV и, кроме Pad1, все суб-TLV имеют показанный ниже формат.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Body...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Type

Тип суб-TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Body

Тело суб-TLV, интерпретация которого зависит от типа суб-TLV и типа содержащего его TLV.

Старший бит типа суб-TLV (шестнадцатеричное значение 80) называется битом обязательности (mandatory). Иными словами, типы суб-TLV от 128 до 255 включают этот бит, который определяет обработку неизвестных суб-TLV. При сброшенном бите неизвестный суб-TLV целиком должен игнорироваться, а остальная часть TLV обрабатывается нормально. Если бит установлен, должен целиком игнорироваться блок TLV (за исключением обновления состояния анализатора с помощью Router-Id, Next Hop, Update TLV, как указано в следующем параграфе).

4.5. Состояние анализатора и кодирование обновлений

В больших сетях основную часть трафика Babel составляют обновления, поэтому были применены способы их эффективного кодирования. Включаемые в обновление данные концептуально разделены на 3 части (параграф 3.5):

  • префикс, порядковый номер и метрика содержатся в самих Update TLV (параграф 4.6.9);

  • router-id берется из Router-Id TLV, предшествующего Update TLV и может использоваться несколькими Update TLV (параграф 4.6.7);

  • следующий интервал (next-hop) берется из адреса отправителя пакета сетевого уровня, содержащего пакет Babel, или из явного Next Hop TLV (параграф 4.6.8).

В дополнение к этому в Update TLV можно опускать префикс анонсируемого префикса, который извлекается из предшествующего Update TLV с тем же семейством адресов (IPv4 или IPv6). Кроме того, в особом случае совпадения router-id с идентификатором интерфейса в адресе IPv6 можно опустить Router-Id TLV и вывести значение router-id из младших битов анонсируемого префикса (параграф 4.6.9).

Для реализации этих методов сокращения в Babel применяется анализатор с учетом состояния, позволяющий TLV ссылаться на данные предыдущего TLV. Состояние анализатора включает указанные ниже данные.

  • Принятый по умолчанию префикс для каждой кодировки адреса с возможностью сжатия. Префикс не определен в начале пакета и обновляется каждым Update TLV с флагом Prefix (параграф 4.6.9).

  • Текущий следующий интервал пересылки (next-hop) для каждого семейства адресов (IPv4 или IPv6). Это адрес отправителя в содержащем обновление пакете для совпадающего семейства адресов в начале пакета, обновляемый каждым Next Hop TLV (параграф 4.6.8);

  • Текущее значение router-id. Значение не определено в начале пакета и обновляется каждым Router-Id TLV (параграф 4.6.7) и Update TLV с флагом Router-Id.

Поскольку состояние анализатора должно быть идентичным в реализациях, оно обновляется до проверки обязательности суб-TLV. Анализ TLV должен обновлять состояние анализатора, даже если в ином случае TLV игнорируется из-за наличия неизвестного обязательного суб-TLV или по иной причине.

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

4.6. Специальные TLV

4.6.1. Заполнение Pad1

 0
 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   Type = 0    |
+-+-+-+-+-+-+-+-+


Type

Значение 0 указывает Pad1 TLV.

Такие TLV игнорируются при получении и могут включаться в трейлер пакета.

4.6.2. Заполнение PadN

 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 = 1   |    Length     |      MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Type

Значение 1 указывает PadN TLV.

Length

Размер тела в октетах без учета полей Type и Length.

MBZ

Должно иметь значение 0, устанавливаемое при передаче.

Такие TLV игнорируются при получении и могут включаться в трейлер пакета.

4.6.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Type = 2   |    Length     |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Opaque            |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


TLV запрашивает у получателя отправку Acknowledgment TLV в течение заданного полем Interval времени.

Type

Значение 2 указывает Acknowledgment Request TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Opaque

Произвольное значение, возвращаемое в Acknowledgment TLV.

Interval

Интервал времени в сотых долях секунды (centisecond), по истечении которого отправитель сочтет пакет потерянным. Установка значения 0 недопустима. Получатель должен передать Acknowledgment TLV до истечения заданного интервала (с запасом на время доставки).

TLV относится к самозавершающим и может включать суб-TLV.

4.6.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 = 3   |    Length     |           Opaque              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


TLV передается узлом в ответ на получение Acknowledgment Request TLV.

Type

Значение 3 указывает Acknowledgment TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Opaque

Значение поля Opaque из Acknowledgment Request, вызвавшего это подтверждение.

Поскольку значения Opaque не уникальны в глобальном масштабе, этот блок TLV должен передаваться по индивидуальному адресу.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.5. Hello

 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 = 4   |    Length     |            Flags              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Seqno              |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


TLV для обнаружения соседей и определения стоимости приема от соседа.

Type

Значение 4 указывает Hello TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Flags

Биты флагов, задающие обработку данного TLV (см. ниже).

Seqno

При установленном флаге Unicast это будет значение порядкового номера Unicast Hello передающего узла для этого соседа. Иначе это будет исходящим порядковым номером Multicast Hello для данного интерфейса.

Interval

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

Формат поля Flags показан на рисунке.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|X|X|X|X|X|X|X|X|X|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


U (Unicast)

Флаг (шестнадцатеричное значение 8000), установка которого указывает Unicast Hello, сброс – Multicast Hello.

X

Все остальные биты должны иметь значение 0 при отправке и игнорируются при получении.

При каждой отправке сообщения Hello должно инкрементиваться значение соответствующего счетчика seqno. Поскольку все Multicast Hello используют общий счетчик seqno для интерфейса на узле, если флаг Unicast сброшен, TLV должен передаваться всем соседям на этом канале, что можно обеспечить отправкой по групповому адресу или передачей групповых пакетов по индивидуальным адресам всех доступных соседей. И наоборот, при установленном флаге Unicast этот блок TLV должен передаваться одному соседу по индивидуальному адресу. Во избежание существенного снижения снижения качества канала не следует передавать несколько Hello TLV в одном пакете.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.6. IHU

 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 = 5   |    Length     |       AE      |    Reserved   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Rxcost             |          Interval             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Address...
+-+-+-+-+-+-+-+-+-+-+-+-


IHU TLV (я слышу вас) служит для подтверждения двухсторонней доступности и передачи стоимости отправки в канал.

Type

Значение 5 указывает IHU TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Address (в большинстве случаев 1 или 3). В качестве оптимизации можно применять 0, если TLV передается по индивидуальному адресу, ассоциация организована по каналу «точка-точка» или двухсторонняя доступность устанавливается средствами другого протокола (вне Babel).

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Rxcost

Значение rxcost, соответствующее передающему узлу интерфейса, адрес которого указан в поле Address. Шестнадцатеричное значени FFFF (бесконечность) указывает недоступность интерфейса.

Interval

Верхняя граница времени по истечении которого предающий узел будет повторять IHU (в сотых долях секнды). Значение 0 недопустимо. Принимающий узел использует это значение для расчета времени удержания данной симметричной ассоциации (связи).

Address

Адрес получателя в формате, заданном полем AE. Сжатие адреса не допускается.

Концептуально IHU адресуется одному соседу. Однако IHU TLV включают явный адрес получателя и могут передаваться по групповому адресу, что позволяет объединить IHU для нескольких соседей в один пакет, избавляя от необходимости использовать обмен ARP или Neighbour Discovery, когда сосед не участвует в трафике данных.

IHU TLV с неизвестным значением в поле AE должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.7. Router-Id

 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 = 6   |    Length     |          Reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                           Router-Id                           +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Router-Id TLV устанавливает значение router-id, которое предполагается следующими Update TLV, как указано в параграфе 4.5. TLV задает router-id даже при наличии в нем неизвестного обязательного суб-TLV.

Type

Значение 6 указывает Router-Id TLV.

Length

Размер тела в октетах без учета полей Type и Length.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Router-Id

Значение router-id для маршрутов, анонсируемых в последующих Update TLV. Недопустимы значения, содержащие только 0 или только 1.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.8. Следующий интервал

 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 = 7   |    Length     |      AE       |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Next hop...
+-+-+-+-+-+-+-+-+-+-+-+-


Next Hop TLV задает адрес следующего интервала (next-hop) для данного семейтсва адресов (IPv4 или IPv6), которые предполагается следующими Update TLV, как указано в параграфе 4.5. TLV задает следующий интервал для последующих Update TLV даже при наличии в нем неизвестного обязательного суб-TLV.

Type

Значение 7 указывает Next Hop TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Address. Следует задавать 1 (IPv4) или 3 (IPv6 link-local), недопустимо указывать 0.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Next hop

Адрес next-hop, анонсируемый последующими Update TLV для этого семейства адресов.

Когда семейство адресов соответствует протоколу сетевого уровня, который передает пакет, Next Hop TLV не требуется и адрес следующего интервала при отсутствии Next Hop TLV берется из адреса отправителя пакета.

Next Hop TLV с неизвестным значением в поле AE должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.9. Обновление

 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 = 8   |    Length     |       AE      |    Flags      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Plen      |    Omitted    |            Interval           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |            Metric             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-


Update TLV анонсирует или отзывает маршрут. В качестве оптимизации может дополнительно устанавливать новое подразумеваемое значение router-id и принятого по умолчанию префикса, как указано в параграфе 4.5.

Type

Значение 8 указывает Update TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Prefix.

Flags

Биты флагов, задающие обработку данного TLV (см. ниже).

Plen

Размер анонсируемого префикса в битах. В случае AE 3 (IPv6 link-local) поле Omitted должно иметь значение 0.

Omitted

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

Interval

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

Seqno

Порядковый номер инициатора для данного обновления.

Metric

Метрика маршрута. Шестнадцатеричное значение FFFF (бесконечность) указывает отзыв маршрута.

Prefix

Анонсируемый префикс размером (Plen/8 – Omitted) с округлением в большую сторону.

Формат поля Flags показан на рисунке.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|P|R|X|X|X|X|X|X|
+-+-+-+-+-+-+-+-+


P (Prefix)

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

R (Router-Id)

Флаг (шестнадцатеричное значение 4000), установка которого указывает, что данный TLV задает новое значение принятого по умолчанию router-id для этого TLV и Update TLV в пакете с тем же кодированием адресов. Значение устанавливается даже при наличии в данном TLV неизвестного обязательного суб-TLV и рассчитывается из первого адреса анонсируемого префикса, как показано ниже.

  • Если размер адреса не меньше 8 октетов из последних 8 октетов адреса извлекается значение router-id.
  • Если размер адреса меньше 8 октетов, новое значение router-id состоит из нужного числа нулевых октетов и поля адреса, записываемого в правую часть router-id. Например, для IPv4 значение router-id будет включать 4 октета нулей, за которыми следует адрес IPv4.

X

Все остальные биты должны иметь значение 0 при отправке и игнорируются при получении.

Расчет префикса, анонсируемого данным Update TLV, выполняется в соответствии с приведенным ниже описанием.

  • Первые Omitted октетов префикса берутся из предыдущего Update TLV с флагом Prefix и тем же кодированием адресов даже при наличии так неизвестного обязательного суб-TLV. Если поле Omitted отлично от 0, но такого TLV нет, данное обновление должно игнорироваться.

  • Следующие (Plen/8 – Omitted) октетов (с округлением вверх) берутся из поля Prefix.

  • Если Plen не кратно 8, все биты вне Plen (младшие (8 – Plen MOD 8) битов последнего октета) сбрасываются.

  • В оставшихся октетах устанавливается 0.

Если поле Metric имеет конечное значение, router-id узла-инициатора для данного анонса берется из префикса, анонсируемого этим обновлением, при наличии флага Router-Id, рассчитанного, как указано выше. В остальных случаях значение берется из предшествующего Router-Id TLV или Update TLV с флагом Router-Id, в зависимости от того, что указано последним, даже при наличии в TLV неизвестного обязательного суб-TLV. При отсутствии подходящего TLV обновление игнорируется.

Адрес следующего интервала (next-hop) для обновления берется из последнего предшествующего Next Hop TLV с тем же семейством адресов (IPv4 или IPv6) в том же пакете даже при наличии неизвестного обязательного суб-TLV. Если такого TLV нет, значение берется из адреса отправителя в пакете сетевого уровня, содержащем данное обновление, если он относится к тому же семейству адресов. В остальных случаях это обновление должно игнорироваться.

Шестнадцатеричное значение FFFF в поле метри указывает отзыв маршрута. В этом случае router-id, next-hop и seqno не используются. AE может иметь значение 0 и в этом случае Update TLV отзывает все маршруты, анонсированные ранее передавшим интерфейсом. Если метрика конечна, установка AE 0 недопустима. Update TLV с конечной метрикой и AE 0 должны игнорироваться. Если метрика бесконечная и AE имеет значение 0, в полях Plen и Omitted должно быть значение 0. Update TLV, не соответствующие этому требованию, должны игнорироваться.

Update TLV с неизвестным значением в поле AE должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.10. Запрос маршрута

 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 = 9   |    Length     |      AE       |     Plen      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      Prefix...
+-+-+-+-+-+-+-+-+-+-+-+-


Route Request TLV приглашает получателя передать обновление для заданного префикса или всю таблицу маршрутов.

Type

Значение 9 указывает Route Request TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Вариант кодирования поля Prefix. Значение 0 указывает запрос полного дампа таблицы маршрутов (шаблонный запрос).

Plen

Размер запрашиваемого префикса в битах.

Prefix

Запрашиваемый префикс, размер которого составляет Plen/8 с округлением в большую сторону.

Route Request TLV приглашает получателя передать обновление (возможно отзыв) для префикса, указанного полями AE, Plen и Prefix или полный дамп его таблицы маршрутов, если AE имеет значение 0 (в этом случае поле Plen должно иметь значение 0 и размер Prefix также должен быть 0). Request TLV с AE 0 и ненулевым Plen должны игнорироваться.

TLV относится к самозавершающим и может включать суб-TLV.

4.6.11. Запрос порядкового номера

 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 = 10  |    Length     |      AE       |    Plen       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Seqno             |  Hop Count    |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                          Router-Id                            +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Prefix...
+-+-+-+-+-+-+-+-+-+-+


Seqno Request TLV приглашает получателя передать Update для данного префикса с данным порядковым номером или переслать запрос, если его нельзя выполнить локально.

Type

Значение 10 указывает Seqno Request TLV.

Length

Размер тела в октетах без учета полей Type и Length.

AE

Формат кодирования поля Prefix. Значение 0 недопустимо.

Plen

Размер запрашиваемого префикса в битах.

Seqno

Запрашиваемый порядковый номер.

Hop Count

Максимальное число пересылок данного TLV плюс 1. Значение 0 недопустимо.

Reserved

Устанавливается 0 при передаче и должно игнорироваться при получении.

Router-Id

Запрашиваемый идентификатор Router-Id. Недопустимы значения, содержащие только 0 или только 1.

Prefix

Запрашиваемый префикс, размер которого составляет Plen/8 с округлением в большую сторону.

Seqno Request TLV приглашает получателя передать Update с конечной метрикой для префикса, указанного полями AE, Plen и Prefix, с router-id, отличным от заданного полем Router-Id, или Seqno не меньше (по модулю 216) указанного в поле Seqno. Если запрос нельзя выполнить локально, он пересылается в соответствии с правилами параграфа 3.8.1.2.

Хотя Seqno Request можно передавать по групповому адресу, его недопустимо пересылать по групповому адресу, а также недопустима пересылка более чем одному соседу. Запрос недопустимо пересылать при Hop Count = 1.

TLV относится к самозавершающим и может включать суб-TLV.

4.7. Специальные суб-TLV

4.7.1. Pad1

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|   Type = 0    |
+-+-+-+-+-+-+-+-+


Type

Значение 0 указывает суб-TLV Pad1.

Суб-TLV игнорируется при получении и может включаться в TLV, поддерживающие суб-TLV.

4.7.2. PadN

 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 = 1   |    Length     |      MBZ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


Type

Значение 1 указывает суб-TLV PadN.

Length

Размер тела в октетах без учета полей Type и Length.

MBZ

Должно иметь значение 0, устанавливаемое при передаче.

Суб-TLV игнорируется при получении и может включаться в TLV, поддерживающие суб-TLV.

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

Агентство IANA зарегистрировало порт UDP с номером 6696, названный babel, для использования протоколом Babel.

Агентство IANA зарегистрировало multicast-группы IPv6 ff02::1:6 и IPv4 224.0.0.111 для протокола Babel.

В IANA создан реестр Babel TLV Types с политикой распределения Specification Required [RFC8126] для типов 0-223 и Experimental Use для типов 224-254. Значения реестра приведены в таблице 1.

Таблица 1.

Тип

Имя

Документ

0

Pad1

RFC 8966

1

PadN

RFC 8966

2

Acknowledgment Request

RFC 8966

3

Acknowledgment

RFC 8966

4

Hello

RFC 8966

5

IHU

RFC 8966

6

Router-Id

RFC 8966

7

Next Hop

RFC 8966

8

Update

RFC 8966

9

Route Request

RFC 8966

10

Seqno Request

RFC 8966

11

TS/PC

[RFC7298]

12

HMAC

[RFC7298]

13

Reserved

14

Reserved

15

Reserved

224-254

Reserved for Experimental Use

RFC 8966

255

Reserved for expansion of the type space

RFC 8966

В IANA создан реестр Babel Sub-TLV Types с политикой распределения Specification Required для типов 0-111 и 128-239 и политикой Experimental Use для типов 112-126 и 240-254. Значения реестра приведены в таблице 2.

Таблица 2.

Тип

Имя

Документ

0

Pad1

RFC 8966

1

PadN

RFC 8966

2

Diversity

[BABEL-DIVERSITY]

3

Timestamp

[BABEL-RTT]

4-111

Unassigned

112-126

Reserved for Experimental Use

RFC 8966

127

Reserved for expansion of the type space

RFC 8966

128

Source Prefix

[BABEL-SS]

129-239

Unassigned

240-254

Reserved for Experimental Use

RFC 8966

255

Reserved for expansion of the type space

RFC 8966

В IANA создан реестр Babel Address Encodings с политикой распределения Specification Required для кодирования адресов (AE) 0-223 и Experimental Use для 224-254. Значения реестра приведены в таблице 3.

Таблица 3.

AE

Имя

Документ

0

Wildcard address

RFC 8966

1

IPv4 address

RFC 8966

2

IPv6 address

RFC 8966

3

Link-local IPv6 address

RFC 8966

4-223

Unassigned

224-254

Reserved for Experimental Use

RFC 8966

255

Reserved for expansion of the AE space

RFC 8966

Реестр Babel Flags Values переименован в Babel Update Flags Values. Для реестра применяется политика распределения Specification Required. Значения реестра приведены в таблице 4.

Таблица 4.

Бит

Имя

Документ

0

Default prefix

RFC 8966

1

Default router-id

RFC 8966

2-7

Unassigned

В IANA создан реестр Babel Hello Flags Values с политикой распределения Specification Required. Значения реестра приведены в таблице 5.

Таблица 5.

Бит

Имя

Документ

0

Unicast

RFC 8966

1-15

Unassigned

Агентство IANA заменило ссылки на RFC 6126 и RFC 7557 во всех перечисленных выше реестрах на данный документ.

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

Как указано в этом документе, протокол Babel является совершенно не защищенным. Без дополнительных механизмов защиты Babel доверяет любой информации, приходящей в открытых дейтаграммах UDP, и действует на основании ее. Злоумышленник в локальной сети может влиять на работу Babel разными способами. Например,

  • подменять пакеты Babel и перенаправлять трафик, анонсируя анонсирования маршруты с меньшей метрикой, большим порядковым номером или более длинным префиксом;

  • создавать некорректно сформированные пакеты, нарушающие работу недостаточно устойчивых реализаций или препятствующие остальной сети;

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

При передаче по протоколу IPv6 пакеты Babel игнорируются, если они не переданы с адреса IPv6 link-local. Поскольку маршрутизаторы не пересылают пакеты IPv6 link-local, это смягчает атаки, указанные выше, необходимостью для злоумышленника иметь доступ к локальному каналу. Для пакетов Babel, переданных по протоколу IPv4 такой естественной защиты нет и это служит одной из причин рекомендуемого использования Babel на основе IPv6 (параграф 3.1).

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

  • Babel по протоколу DTLS [RFC8968] передает основную часть трафика Babel по протоколу DTLS и этот протокол применяется для аутентификации узлов, а также защиты целостности и конфиденциальности.

  • MAC-аутентификация [RFC8967] добавляет код аутентификации сообщений (message authentication code или MAC) в каждый пакет Babel для подтверждения его отправки узлом, знающим общий секрет, и включения дополнительной информации для проверки свежести пакета (предотвращение повторного использования).

Оба механизма позволяют узлам игнорировать пакеты от злоумышленника без требуемых свидетельств. Обеспечивается также целостность сообщений и предотвращается их повторное использование. Babel-DTLS использует асимметричные ключи и обеспечивает конфиденциальность, а Babel-MAC имеет более ограниченную область применения (см. параграфы 1.1, 1.2, 7 в [RFC8967]). Поскольку Babel-MAC проще и более облегчен, его рекомендуется использовать в приложениях Babel, где ограничения протокола допустимы, например, достаточно симметричных ключей, а маршрутные данные не считаются конфиденциальными.

Каждой реализации Babel следует поддерживать BABEL-MAC.

Следует учитывать, что информации, которую мобильный узел Babel анонсирует всему домену маршрутизации, достаточно для определения физического местоположения мобильного узла с неплохой точностью, что может вызывать проблемы приватности даже при защите трафика управления от неаутентифицированных злоумышленников криптографическими механизмами, такими как Babel-DTLS. Эту проблему можно смягчить использованием случайных значений router-id и адресов IP, а также их достаточно частой сменой.

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

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

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

[RFC793] Postel, J., “Transmission Control Protocol”, STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.

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

[RFC8967] Dô, C., Kolodziejak, W., and J. Chroboczek, “MAC Authentication for the Babel Routing Protocol”, RFC 8967, DOI 10.17487/RFC8967, January 2021, <https://www.rfc-editor.org/info/rfc8967>.

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

[BABEL-DIVERSITY] Chroboczek, J., “Diversity Routing for the Babel Routing Protocol”, Work in Progress, Internet-Draft, draft-chroboczek-babel-diversity-routing-01, 15 February 2016, <https://tools.ietf.org/html/draft-chroboczek-babel-diversity-routing-01>.

[BABEL-RTT] Jonglez, B. and J. Chroboczek, “Delay-based Metric Extension for the Babel Routing Protocol”, Work in Progress, Internet-Draft, draft-ietf-babel-rtt-extension-00, 26 April 2019, <https://tools.ietf.org/html/draft-ietf-babel-rtt-extension-00>.

[BABEL-SS] Boutier, M. and J. Chroboczek, “Source-Specific Routing in Babel”, Work in Progress, Internet-Draft, draft-ietf-babel-source-specific-07, 28 October 2020, <https://tools.ietf.org/html/draft-ietf-babel-source-specific-07>.

[DSDV] Perkins, C. and P. Bhagwat, “Highly dynamic Destination-Sequenced Distance-Vector routing (DSDV) for mobile computers”, ACM SIGCOMM ’94: Proceedings of the conference on Communications architectures, protocols and applications, 234-244, DOI 10.1145/190314.190336, October 1994, <https://doi.org/10.1145/190314.190336>.

[DUAL] Garcia Luna Aceves, J. J., “Loop-free routing using diffusing computations”, IEEE/ACM Transactions on Networking, 1:1, DOI 10.1109/90.222913, February 1993, <https://doi.org/10.1109/90.222913>.

[EIGRP] Albrightson, B., Garcia Luna Aceves, J. J., and J. Boyle, “EIGRP — a Fast Routing Protocol Based on Distance Vectors”, Proc. Networld/Interop 94, 1994.

[ETX] De Couto, D., Aguayo, D., Bicket, J., and R. Morris, “A high-throughput path metric for multi-hop wireless networks”, MobiCom ’03: Proceedings of the 9th annual international conference on Mobile computing and networking, 134-146, DOI 10.1145/938985.939000, September 2003, <https://doi.org/10.1145/938985.939000>.

[IEEE802.11] IEEE, “IEEE Standard for Information technology–Telecommunications and information exchange between systems Local and metropolitan area networks—Specific requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications”, IEEE 802.11-2012, DOI 10.1109/ieeestd.2012.6178212, April 2012, <https://doi.org/10.1109/ieeestd.2012.6178212>.

[IEN137] Cohen, D., “On Holy Wars and a Plea for Peace”, IEN 137, 1 April 1980.

[IS-IS] International Organization for Standardization, “Information technology — Telecommunications and information exchange between systems — Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)”, ISO/IEC 10589:2002, 2002.

[JITTER] Floyd, S. and V. Jacobson, “The Synchronization of Periodic Routing Messages”, IEEE/ACM Transactions on Networking, 2, 2, 122-136, DOI 10.1109/90.298431, April 1994, <https://doi.org/10.1109/90.298431>.

[OSPF] Moy, J., “OSPF Version 2”, STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <https://www.rfc-editor.org/info/rfc2328>.

[PACKETBB] Clausen, T., Dearlove, C., Dean, J., and C. Adjih, “Generalized Mobile Ad Hoc Network (MANET) Packet/Message Format”, RFC 5444, DOI 10.17487/RFC5444, February 2009, <https://www.rfc-editor.org/info/rfc5444>.

[RFC2675] Borman, D., Deering, S., and R. Hinden, “IPv6 Jumbograms”, RFC 2675, DOI 10.17487/RFC2675, August 1999, <https://www.rfc-editor.org/info/rfc2675>.

[RFC3561] Perkins, C., Belding-Royer, E., and S. Das, “Ad hoc On-Demand Distance Vector (AODV) Routing”, RFC 3561, DOI 10.17487/RFC3561, July 2003, <https://www.rfc-editor.org/info/rfc3561>.

[RFC6126] Chroboczek, J., “The Babel Routing Protocol”, RFC 6126, DOI 10.17487/RFC6126, April 2011, &