RFC 8505 Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery

Опубликовано 23.11.2018 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                   P. Thubert, Ed.
Request for Comments: 8505                                         Cisco
Updates: 6775                                                E. Nordmark
Category: Standards Track                                         Zededa
ISSN: 2070-1721                                           S. Chakrabarti
                                                                 Verizon
                                                              C. Perkins
                                                               Futurewei
                                                           November 2018

Registration Extensions for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor Discovery

Регистрационные расширения для обнаружения соседей 6LoWPAN

PDF

Аннотация

Эта спецификация обновляет RFC 6775 (спецификация обнаружения соседей в 6LoWPAN) для прояснения роли протокола как метода регистрации с целью упрощения регистрационных операций в маршрутизаторах 6LoWPAN, а также для расширения возможностей регистрации и обнаружения мобильности для разных сетевых технологий, включая регистраторы маршрутизации (Routing Registrar), выполняющие маршрутизацию для путей к хостам и/или функции посредников при обнаружении соседей в сетях со слабым питанием.

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

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

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

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

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

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

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

1. Введение

Сети IPv6 со слабым питанием и потерями (Low-Power and Lossy Network или LLN) поддерживают топологии «звезда» (star) и «ячейки» (mesh). Для таких сетей в документе Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC6775] (его называют также 6LoWPAN Neighbor Discovery (ND)) определён механизм регистрации и центральный регистратор IPv6 ND для обеспечения уникальности адресов. Механизм 6LoWPAN ND снижает зависимость протокола IPv6 ND [RFC4861] [RFC4862] от группового трафика на сетевом уровне и широковещания на канальном.

Эта спецификация обновляет 6LoWPAN ND [RFC6775] для упрощения и обобщения регистрации в маршрутизаторах 6LoWPAN (6LR). В частности, обновлено и расширено поведение и элементы протокола 6LoWPAN ND для:

  • определения последнего места пребывания мобильного узла;

  • упрощения регистрации потока для адресов Link-Local (на локальном канале);

  • поддержки не знающих о маршрутизации узлов-листьев в сети с маршрутизацией;
  • регистрации в сети с маршрутизацией через посредника;
  • обеспечения возможности проверки регистрации с помощью опции ROVR (5.3. Поле ROVR);
  • регистрации на посреднике IPv6 ND (например, Routing Registrar);
  • улучшения поддержки приватности и временных адресов.

Эти функции соответствуют требованиям, приведённым с Приложении B.

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

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

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

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

В этом документе применяются термины и концепции из перечисленных ниже документов.

  • Neighbor Discovery for IP version 6 (IPv6) [RFC4861];

  • IPv6 Stateless Address Autoconfiguration [RFC4862];

  • IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals [RFC4919];

  • Problem Statement and Requirements for IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Routing [RFC6606];

  • Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) [RFC6775].

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

6BBR

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

6CIO

Capability Indication Option – опция индикации возможности.

6LBR

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

6LN

6LoWPAN Node – узел 6LoWPAN.

6LoWPAN

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

6LR

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

ARO

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

DAC

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

DAD

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

DAR

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

DODAG

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

EARO

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

EDA

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

EDAC

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

EDAR

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

LLN

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

NA

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

NCE

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

ND

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

NS

Neighbor Solicitation – предложение соседства.

RA

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

ROVR

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

RPL

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

RS

Router Solicitation – предложение маршрутизатора.

TID

Transaction ID – идентификатор транзакции (порядковый номер в EARO).

2.4. Новые термины

Backbone Link – магистральный канал

Транзитный канал IPv6, соединяющий два или более магистральных маршрутизатора.

Binding – привязка

Ассоциация между адресом IP, MAC3-адресом и другой информацией об узле, владеющем адресом IP.

Registration – регистрация

Процесс, с помощью которого 6LN регистрирует адрес IPv6 в 6LR для подключения к сети LLN.

Registered Node – зарегистрированный узел

6LN, для которого выполнена регистрация с соответствии с полями EARO.

Registering Node – регистрирующий узел

Узел, выполняющий регистрацию (зарегистрированный узел или прокси).

IPv6 ND Registrar – регистратор IPv6 ND

Узел, способный обработать регистрацию через сообщения NS(EARO) или EDAR и отвечающий после этого сообщением NA или EDAC с опцией EARO и соответствующим статусом регистрации.

Registered Address – зарегистрированный адрес

Адрес, зарегистрированный для узла (Registered Node).

RFC 6775-only – поддержка лишь RFC 6775

Реализация, тип узла или сообщение, соответствующее требованиям [RFC6775], но не данного документа.

Route-over network – сеть с маршрутизацией

Сеть, связность с которой обеспечивается уровнем IP.

Routing Registrar – регистратор маршрутизации

Регистратор IPv6 ND, обеспечивающий также услуги доступности для зарегистрированного адреса, включая DAD и proxy NA.

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

Регистратор маршрутизации (Routing Registrar), выполняющий функции посредника для операций 6LoWPAN ND, заданные в этом документе, с целью обеспечения работы нескольких LLN, объединённых магистральным каналом (Backbone Link), как одной подсети IPv6.

Updated – обновленный

6LN, 6LR или 6LBR, поддерживающий данную спецификацию, в отличие от устройств RFC 6775-only.

3. Применимость опций ARO

Опция ARO, описанная в [RFC6775], упрощает DAD для хостов и заполняет записи NCE [RFC4861] в маршрутизаторах. Это снижает зависимость от групповых операций, которые зачастую столь же навязчивы, как широковещание, при работе IPv6 ND (см. [Multicast-over-IEEE802-Wireless]).

В этом документе заданы новые коды состояния для регистраций, отвергнутых 6LR или 6LBR, по причинам, не связанным с дубликатами. Например,

  • недостаточно места на маршрутизаторе;

  • регистрация с устаревшим порядковым номером (например, при перемещении уже после регистрации);

  • некорректное поведение хоста с попыткой зарегистрировать недействительный адрес (например, не указанный, как определено в [RFC4291]);

  • использование хостом адреса, который топологически некорректен для данного канала.

В таких случаях хост будет получать сообщение об ошибке, помогающее выяснить проблему, и сможет повторить попытку (возможно с другим адресом) или зарегистрироваться на ином маршрутизаторе, в зависимости от возвращённой ошибки. Возврат ошибок при регистрации адреса не предназначен для ограничения возможности хостов формировать и регистрировать несколько адресов. Каждый хост может сформировать и зарегистрировать множество адресов по соображениям приватности, используя механизмы, такие как описаны в [RFC4941] (Privacy Extensions for Stateless Address Autoconfiguration in IPv6), например, автоматическую настройку без учёта состояния (Stateless Address Autoconfiguration или SLAAC), и ему следует соблюдать [RFC7934] (Host Address Availability Recommendations).

Как указано в IPv6 ND [RFC4861], маршрутизатору требуется достаточно большое хранилище для записей NCE от всех подключённых напрямую адресов, по которым он пересылает пакеты (неиспользуемые записи могут удаляться). Маршрутизатору, обслуживающему механизм регистрации адресов, требуется место для хранения NCE всех адресов, которые могут быть зарегистрированы на нем, независимо от реального взаимодействия с ними. Число регистраций, поддерживаемых 6LR или 6LBR, должно быть указано в документации производителя, а оператору сети должно быть доступно динамическое использование связанных с этим ресурсов, например, через консоль управления. Администраторы сети должны гарантировать, что маршрутизаторы 6LR и 6LBR в их сети поддерживают нужное число и типы устройств, которые могут регистрироваться на них, с учётом числа требуемых устройствам адресов IPv6, а также поведения адресов и скорости их обновления.

4. Опции и сообщения расширенного обнаружения соседей

Эта спецификация не добавляет опций, а изменяет имеющиеся, обновляя соответствующее поведение.

4.1. Расширенная опция ARO (EARO)

Опция ARO определена в параграфе 4.1 [RFC6775]. Данная спецификация определяет расширенную опцию EARO, основанную на ARO, для использования в сообщениях NS и NA. EARO включает порядковый номер, называемый идентификатором транзакции (Transaction ID или TID), который служит для определения последнего местоположения регистрирующегося мобильного устройства. Новый флаг T указывает, что имеющееся поле TID заполнено, а опция является EARO. Узел 6LN запрашивает услуги маршрутизации или прокси у 6LR, используя новый флаг R в EARO.

Поле EUI-64 переопределено и названо ROVR для включения разных типов информации, например, криптографических данных переменного размера (см. 5.3. Поле ROVR). Можно использовать ROVR большего размера, если совместимость с прежними версиями не требуется в сети LLN. Значение поля Length за вычетом 1 указывает размер поля ROVR в 8-байтовых словах. Более подробно это рассмотрено в параграфе 5.1. Расширение ARO. Формат опции EARO показан на рисунке 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |     Length    |    Status     |    Opaque     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Rsvd | I |R|T|     TID       |     Registration Lifetime     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
...            Registration Ownership Verifier (ROVR)         ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Формат EARO.


Type

33

Length

8-битовое целое число без знака, указывающее размер опции в 8-байтовых словах.

Status

8-битовое целое число без знака, указывающее статус регистрации в отклике NA. В сообщениях NS должно иметь значение 0. См. таблицу 1.

Opaque

Не анализируемое ND значение. 6LN может передавать его без изменений другому процессу. Если поле не используется, оно должно быть установлено в 0.

Rsvd

Резервное поле. Должно устанавливаться в 0 отправителем, а получатель должен игнорировать поле.

I

2-битовое целое число. Значение 0 указывает, что поле Opaque содержит абстрактный индекс, служащий для определения маршрутной топологии, куда предполагается вставка адреса. В этом случае поле Opaque передаётся процессу маршрутизации с указанием того, что оно несёт сведения о топологии (0 указывает принятую по умолчанию). Использование других значений в поле I недопустимо.

R

Регистрирующий узел устанавливает флаг R для запроса услуг доступности (маршрутизации) зарегистрированного адреса у Routing Registrar.

T

Флаг, указывающий, что следующий октет служит TID.

TID

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

Registration Lifetime

16-битовое целое число, указывающее срок регистрации в минутах. Значение 0 говорит о завершении срока регистрации и указывает, что соответствующее состояние должно быть удалено.

Registration Ownership Verifier (ROVR)

Разрешает сопоставление нескольких попыток регистрации одного адреса IPv6. Для совместимости с прежними версиями поле ROVR должно иметь размер 64 бита, в ином случае размер может быть 128, 192 или 256 битов.

Таблица 1. Коды состояния EARO.

Значение

Описание

0-2

Определены в [RFC6775]. Отметим, что значение Status = 1 (дубликат адреса) применимо к зарегистрированному адресу. Если Source Address конфликтует с имеющейся регистрацией, должен применяться статус Duplicate Source Address.

3

Перемещено. Регистрация завершилась отказом, поскольку она не была самой свежей. Этот статус указывает, что регистрация была отвергнута по причине наличия более свежей регистрации, указанной с тем же ROVR и более новым TID. Одной из возможных причин является устаревшая регистрация, которая медленно проходила через сеть и была передана более новой. Это может указывать также на конфликт ROVR.

4

Удалено. Состояние привязки было удалено. Это значение Status может быть помещено в сообщение NA(EARO), переданное как отказ от прокси-регистрации в IPv6 ND Registrar, или в асинхронное сообщение NA(EARO).

5

Запрошена проверка. Для регистрирующего узла возникли сомнения во владении зарегистрированным адресом или приемлемости прокси для регистрации. IPv6 ND Registrar может поместить это значение Status в асинхронные сообщения DAC или NA.

6

Дубликат адреса отправителя. Адрес, указанный в поле отправителя NS(EARO), конфликтует с имеющейся регистрацией.

7

Недействительный адреса отправителя. Адрес отправителя NS(EARO) не является Link-Local.

8

Зарегистрированный адрес не корректен топологически. Зарегистрированный адрес не применим на этом канале.

9

Реестр 6LBR заполнен. Новая регистрация не может быть воспринята по причине заполнения реестра 6LBR. Отметим, что этот код применяется 6LBR вместо Status = 2 при отклике на обмен сообщениями Duplicate Address и передаётся регистрирующему узлу маршрутизатором 6LR.

10

Отказ при проверке. Некорректное подтверждение владения зарегистрированным адресом.

4.2. Расширенные форматы сообщений о дубликатах адресов

Сообщения DAR и DAC используют общий базовый формат, определённый в параграфе 4.4 [RFC6775], и позволяют доставлять сведения из ARO через несколько интервалов пересылки. Расширенный формат DAR и DAC показан на рисунке 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      |CodePfx|CodeSfx|          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Status     |     TID       |     Registration Lifetime     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
...          Registration Ownership Verifier (ROVR)           ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                       Registered Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 2. Формат расширенного сообщения о дубликате адреса.


Ниже перечислены изменённые поля сообщений.

Code

Код ICMP [RFC4443] для сообщений Duplicate Address разделен на два 4-битовых поля Code Prefix и Code Suffix. В поле Code Prefix отправитель должен устанавливать 0, а получатель должен игнорировать поле. Ненулевое значение Code Suffix указывает поддержку данной спецификации. В нем должно устанавливаться значение 1 при работе в режиме совместимости с прежними версиями, где применяется ROVR размером 64 бита. В иных случаях можно устанавливать значение 2, 3, 4, указывающее размер ROVR 128, 192, 256 бита, соответственно.

TID

1-байтовое целое число. Определение и обработка TID соответствуют заданным для EARO в параграфе 4.1. Это поле должно игнорироваться при пустом (null) ICMP Code.

Registration Ownership Verifier (ROVR)

Размер ROVR определяется полем ICMP Code Suffix. Определение и обработка поля ROVR соответствуют заданным для EARO в параграфе 4.1.

4.3. Расширения опции CIO

Эта спецификация определяет 5 новых битов возможностей для опции 6CIO, определённой в [RFC7400] (6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)) для сообщений IPv6 ND. Флаг G определён в параграфе 3.3 [RFC7400].

Флаг D показывает, что 6LBR поддерживает сообщения EDAR и EDAC. Маршрутизатор 6LR, получающий флаг D из анонсов, может обмениваться сообщениями EDAR и EDAC с 6LBR и устанавливать флаг D, а также флаг L в опции 6CIO своих анонсов. Благодаря этому, 6LN могут предпочесть регистрацию на 6LR, способном использовать новые функции 6LBR.

Новые флаги L, B и P указывают, может ли маршрутизатор выступать как 6LR, 6LBR или Routing Registrar (например, 6BBR), соответственно (или в комбинации). Эти флаги не исключают друг друга и обновленный узел может анонсировать несколько функций.

Флаг E указывает возможность использования EARO при регистрации. Маршрутизатор 6LR, поддерживающий эту спецификацию, должен устанавливать флаг E.

 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.


Ниже указаны поля опции.

Type

36

D

6LBR поддерживает сообщения EDAR и EDAC.

L

Узел является 6LR.

B

Узел является 6LBR.

P

Узел является Routing Registrar.

E

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

5. Обновление RFC 6775

EARO (4.1. Расширенная опция ARO (EARO)) обновляет опцию ARO, используемую в сообщениях NS и NA между 6LN и 6LR. Обновление позволяет регистрацию в Routing Registrar для получения дополнительных услуг, таких как возврат возможности маршрутизации по зарегистрированному адресу с помощью обычных средств маршрутизации и/или proxy ND, как показано на рисунке 4.

               Routing
6LN            Registrar
  |                |
  |   NS(EARO)     |
  |--------------->|
  |                |
  |                | Вставка/поддержка
  |                | маршрута к хосту или
  |                | состояния IPv6 ND proxy
  |                | <----------------->
  |   NA(EARO)     |
  |<---------------|
  |                |

Рисунок 4. Поток (пере)регистрации.


EDAR и EDAC обновляют сообщения DAR и DAC для доставки новой информации между 6LR и 6LBR через сеть LLN (mesh). Расширениями ARO являются DAR и DAC при использовании в сообщениях Duplicate Address, передающие дополнительные сведения маршрутизатору 6LBR. В свою очередь, 6LBR может служить посредником при регистрации для получения услуг доступности от Routing Registrar, таких как 6BBR (рисунок 5). Эта спецификация предотвращает поток сообщения Duplicate Address для адресов Link-Local в топологии с маршрутизацией [RFC6606] (параграф 5.6).

                                       Routing
6LN          6LR            6LBR      Registrar
 |            |              |            |
 |<Link-local>|   <Routed>   |<Link-local>|
 |            |              |            |
 |  NS(EARO)  |              |            |
 |----------->|              |            |
 |            | Extended DAR |            |
 |            |------------->|            |
 |            |              |  proxy     |
 |            |              |  NS(EARO)  |
 |            |              |----------->|
 |            |              |            | Вставка/поддержка
 |            |              |            | маршрута к хосту или
 |            |              |            | состояния IPv6 ND proxy
 |            |              |            | <----------------->
 |            |              |  proxy     |
 |            |              |  NA(EARO)  |
 |            | Extended DAC |<-----------|
 |            |<-------------|            |
 |  NA(EARO)  |              |            |
 |<-----------|              |            |
 |            |              |            |

Рисунок 5. Поток (пере)регистрации.


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

В разделе 5 [RFC6775] указано, как 6LN запускает интерфейс и находит доступные 6LR. Регистрирующему узлу следует регистрироваться на 6LR, поддерживающем данную спецификацию, если такой маршрутизатор найден, как указано в параграфе 6.1, вместо регистрации на 6LR, поддерживающем лишь RFC 6775. В иных случаях регистрирующий узел работает в режиме совместимости с прежними версиями, присоединяясь к RFC 6775-only 6LR.

5.1. Расширение ARO

Опция EARO обновляет ARO и совместима с прежней версией тогда и только тогда, когда установлено значение Length = 2. Формат опции EARO на рисунке 1. Вопросы совместимости более подробно рассматриваются в разделе 6. Изменения в сообщении NS и опции ARO описаны ниже.

  • Поле Target Address в NS, содержащее EARO, сейчас показывает регистрируемый адрес в отличие от поля Source Address в NS, указанного в [RFC6775] (см. 5.5. Регистрация целевого адреса). Это изменение позволяет 6LBR передать прокси-регистрацию для адреса 6LN регистратору Routing Registrar и в большинстве случаев избежать использования Source Address в качестве адреса до его регистрации.

  • Поле EUI-64 в ARO переименовано в Registration Ownership Verifier (ROVR) и его не требуется выводить из MAC-адреса (см. 5.3. Поле ROVR).

  • Поле Length в опции может отличаться от 2 и принимать значения от 3 до 5, делая опцию EARO несовместимой с прежней опцией ARO. Увеличение размера соответствует большему полю ROVR, размер которого выводится из значения Length.

  • Добавлено поле Opaque для доставки необрабатываемых данных, передаваемых другому процессу регистрации, например для анонсирования протоколом маршрутизации. Новое поле I указывает тип необрабатываемой информации и процесс, для которого 6LN передаёт Opaque. I = 0 указывает передачу топологических сведений процессу маршрутизации, если регистрация распределяется далее. В этом случае значение 0 в поле Opaque (1) обеспечивает совместимость с прежними версиями, где поле является резервным, и (2) указывает использование принятой по умолчанию топологии.

  • Этот документ задаёт для опции EARO новый флаг R. При установленном флаге Registering Node запрашивает у 6LR обеспечения доступности регистрируемого адреса, например через маршрутизацию или proxy ND. Сброшенный флаг R указывает, что Registering Node является маршрутизатором и будет анонсировать доступность Registered Address по протоколу маршрутизации (такому как RPL [RFC6550]).

  • Поддерживающий эту спецификацию узел должен включать поле TID в опцию EARO и устанавливать флаг T для индикации его присутствия (см. 5.2. Идентификатор транзакции).

  • Спецификация вводит два новых кода состояния, помогающих определить причину отказа (Таблица 1).

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

5.2. Идентификатор транзакции

TID является порядковым номером, который инкрементируется 6LN при каждой перерегистрации на 6LR, и служит для определения свежего запроса на регистрацию, который сеть использует для определения последнего места размещения 6LN. Когда Registered Node зарегистрирован на нескольких 6LR параллельно, для них должны указываться одинаковые значения TID. Это позволяет 6LBR и/или Routing Registrar определить идентичные регистрации и отличать их от перемещений узла (см. примеры в параграфе 5.7 и Приложении A).

5.2.1. Сравнение значений TID

Операции TID полностью совместимы со счётчиком RPL Path Sequence, описанным в параграфе 7.2 [RFC6550] (RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks).

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

Диапазон TID делится на 2 части в стиле [Perlman83], где значения 128 и больше используются как линейная последовательность для индикации перезапуска и загрузки (bootstrap) счётчика, а значения от 0 до 127 служат кольцевым счётчиком в пространстве со 128 именами, как описано в [RFC1982]. Переход от линейного режима к кольцевому отслеживается. При работе в кольцевом режиме слишком удалённые номера считаются несравнимыми, как указано ниже. Окно сравнения SEQUENCE_WINDOW = 16 настраивается на основе значения 2N, а для N данная спецификация задаёт значение 4.

Сравнение значений счётчика выполняется в соответствии с приведёнными ниже правилами.

  1. Перед использованием счётчика его следует инициализировать зависящим от реализации значением не меньше 128, рекомендуется использовать 240 (256 – SEQUENCE_WINDOW).

  2. Когда инкрементирование счётчика ведёт к переходу через максимум, счётчик должен сбрасываться в 0. Для диапазона 128 и больше максимум составляет 255, в диапазоне значений меньше 128 – 127.

  3. При сравнении двух значений счётчика должны применяться приведённые ниже правила.

    1. Если первое значение A относится к диапазону [128-255], а второе B – к диапазону [0-127]:

      1. если (256 + B – A) ≤ SEQUENCE_WINDOW, B считается больше A, A меньше B и они не равны;

      2. если (256 + B – A) > SEQUENCE_WINDOW, A считается больше B, B меньше A и они не равны.

      Например, если A = 240 и B = 5, то (256 + 5 – 240) = 21. Значение 21 больше SEQUENCE_WINDOW (16), поэтому 240 больше чем 5. Если A = 250 и B = 5, то (256 + 5 – 250) = 11. Значение 11 меньше SEQUENCE_WINDOW (16), поэтому 250 меньше чем 5.

    2. Если оба сравниваемых номера относятся к одному диапазону (оба не больше или оба больше 127):

      1. если абсолютное значение разности не превышает SEQUENCE_WINDOW, используется сравнение, заданное в [RFC1982];

      2. если абсолютное значение разности превышает SEQUENCE_WINDOW, считается, что произошла ресинхронизация номеров и они не сравнимы.

  4. Если два номера сочтены несравнимыми (результат сравнения не определён), узлу следует отдать предпочтение номеру, который был инкрементирован позднее. В иных случаях следует выбирать номер, минимизирующий смену состояния узла.

5.3. Поле ROVR

Поле ROVR заменяет EUI-64 в опции ARO, определённой в [RFC6775], и связано с состоянием регистрации в 6LR и 6LBR. ROVR может быть уникальным идентификатором Registering Node, таким как адрес EUI-64 на интерфейсе, а также маркером, получаемым криптографическими методами, который может применяться в дополнительных протокольных обменах для связывания криптографического элемента (ключа) с регистрацией для того, чтобы его мог изменить лишь владелец, подтвердив владение ROVR. Областью действия ROVR является регистрация конкретного адреса IPv6 и недопустимо использовать то же значение ROVR для регистрации другого адреса.

ROVR может использовать разные типы и конкретный тип указывается в сообщении, передающем новый тип. Например, это может быть криптографическая строка, служащая для подтверждения владения регистрацией, как указано в [AP-ND] (Address Protected Neighbor Discovery for Low-power and Lossy Networks). Для поддержки потоков, относящихся к подтверждению владения, эта спецификация вводит в EARO новые коды состояния Validation Requested (запрошена проверка) и Validation Failed (отказ при проверке).

Примечание относительно конфликтов ROVR. Разные методы формирования ROVR работают в разных пространствах имён. В [RFC6775] задано использование адресов EUI-64, [AP-ND] задаёт генерацию криптографических маркеров. Хотя в самом пространстве EUI-64 конфликты не предполагаются, они становятся возможными при реализации [AP-ND] даже на одном узле. Реализация, понимающая пространство имён, должна считать ROVR из разных пространств имён различающимися даже при совпадении их значений. Поддерживающие лишь RFC 6775 маршрутизаторы 6LBR и 6LR будут путать пространства имён, что несколько повышает вероятность конфликтов ROVR. Конфликты ROVR не оказывают влияния при регистрации двумя узлами разных адресов, поскольку значимость ROVR ограничена контекстом одной регистрации. Не предполагается уникальность значений ROVR в рамках одной регистрации, поскольку эта спецификация позволяет узлу применять одно значение ROVR для регистрации нескольких адресов IPv6. Поэтому недопустимо использовать ROVR в качестве ключа для идентификации Registering Node или индекса регистрации. Поле применяется лишь для сопоставления при проверке проверке совпадения меняющего регистрацию узла с узлом, зарегистрировавшим адрес IPv6. Если ROVR не является адресом EUI-64, недопустимо использовать это поле как идентификатор интерфейса с зарегистрированным адресом. Таким образом, регистрация с применением ROVR не будет конфликтовать с регистрацией адреса IPv6, выведенного из EUI-64 и использующего EUI-64 в качестве ROVR согласно [RFC6775].

Регистрирующему узлу следует сохранять ROVR или иметь данные для восстановления значения в постоянной памяти. При отказе от этого такие события, как перезагрузка, будут вызывать потерю состояния и повторная регистрация того же адреса может быть невозможна, пока (1) в 6LR и 6LBR не истечёт срок прежней регистрации или (2) система управления не сбросит соответствующее состояние в сети.

5.4. Расширенные сообщения о дубликатах адресов

Для отображения нового содержимого EARO в сообщениях EDA добавлено поле TID в сообщения EDAR и EDAC, заменившее резервное поле (Reserved), и отличное от 0 значение ICMP Code указывает поддержку этой спецификации. Формат сообщений EDAR и EDAC показан на рисунке 2.

Как и опция EARO, сообщения EDA совместимы с прежними версиями RFC 6775-only, если поле ROVR имеет размер 64 бита. Замечания о совместимости протоколов между 6LN и 6LR применимы к совместимости между 6LR и 6LBR.

5.5. Регистрация целевого адреса

Сообщение NS с опцией EARO является регистрацией тогда и только тогда, когда в нем есть опция SLLA4 (SLLAO) [RFC6775]. EARO можно применять в сообщениях NS и NA между Routing Registrar для определения распределенного состояния регистрации, в этом случае оно не включает опцию SLLA и не путается с регистрацией.

Registering Node – это узел, выполняющий регистрацию на Routing Registrar. Как указано в [RFC6775], это может быть также зарегистрированный узел (Registered Node), регистрирующий один из своих адресов, и указывающий свой MAC-адрес в опции SLLA сообщения NS(EARO).

Эта спецификация добавляет возможность посредничества при регистрации от имени зарегистрированного узла, доступного через сеть LLN. В этом случае Registered Node доступен от Routing Registrar через mesh-конфигурацию, а регистрирующий узел указывает MAC-адрес регистрируемого узла в SLLA в сообщении NS(EARO). Если зарегистрированный узел доступен через конфигурацию с маршрутизацией (route-over) для Registering Node, SLLA в NS(ARO) содержит адрес регистрирующего узла. Это позволяет регистрирующему узлу привлекать пакеты от Routing Registrar и маршрутизировать их через сеть LLN зарегистрированному узлу.

Для выполнения такой операции данная спецификация меняет поведение 6LN и 6LR так, что зарегистрированный узел указывается в поле Target Address сообщений NS и NA, а не в поле Source Address. В соответствии с этим опция TLLA (Target Link-Layer Address Option или TLLAO) указывает адрес канального уровня узла 6LN, владеющего адресом.

Регистрирующий узел (например, 6LBR, являющийся корнем RPL), анонсирующий доступность для 6LN, должен поместить свой адрес канального уровня в опцию SLLA регистрационного сообщения NS(EARO). Это обеспечивает совместимость с 6LoWPAN ND при поддержке тем лишь RFC 6775.

5.6. Адреса Link-Local и регистрация

Узлы LLN часто не имеют кабельных подключений и могут перемещаться. При этом нет никакой гарантии уникальности узла Link-Local среди огромного и способного постоянно меняться числа соседних узлов. В отличие от [RFC6775], эта спецификация требует уникальности адреса Link-Local лишь с точки зрения двух узлов, использующих его для связи (например, 6LN и 6LR в обмене NS/NA). Это упрощает процесс DAD в топологии с маршрутизацией для адресов Link-Local за счёт избавления от обмена сообщениями EDA между 6LR и 6LBR для этих адресов.

Обмен между двумя узлами с адресами Link-Local предполагает между узлами один интервал (hop). Узел должен регистрировать адрес Link-Local в 6LR для получения дальнейшей связности через этот 6LR и, в частности, для использования адреса Link-Local в качестве Source Address при регистрации других (например, глобальных) адресов.

Если не возникает конфликтов с ранее зарегистрированным адресом, адрес Link-Local является уникальным с точки зрения этого 6LR и регистрация не является дубликатом. Два разных 6LR могут заявить один адрес Link-Local при разных адресах канального уровня. В этом случае узел 6LN должен взаимодействовать лишь с одним из 6LR.

Обмен сообщениями EDAR и EDAC между 6LR и 6LBR, обеспечивающий уникальность адреса в домене, охватываемом 6LBR, не требуется для адресов Link-Local.

При передаче NS(EARO) маршрутизатору 6LR узел 6LN должен использовать адрес Link-Local как Source Address для регистрации, независимо от типа регистрируемого адреса IPv6. Этот адрес Link-Local должен быть регистрируемым или ранее зарегистрированным на 6LR адресом.

При старте 6LN узел обычно передаёт групповые сообщения RS и получает одно или множество индивидуальных сообщения RA от 6LR. Если 6LR может обрабатывать сообщения EARO, он помещает опцию 6CIO в свои сообщения RA с флагом E, установленным в соответствии с требованиями параграфа 6.1.

Когда у регистрирующего узла нет ранее зарегистрированного адреса, он должен регистрировать адрес Link-Local, используя его как Source Address и Target Address в сообщении NS(EARO). В таких случаях рекомендуется применять адрес, для которого не требуется DAD (см. [RFC6775]), например, адрес, выведенный из глобально уникального адреса EUI-64. Использование опции SLLA в NS согласуется с имеющимися спецификациями ND, такими как [RFC4429] (Optimistic Duplicate Address Detection (DAD) for IPv6). 6LN затем может использовать этот адрес для регистрации других адресов.

Маршрутизатор 6LR, поддерживающий эту спецификацию, отвечает сообщением NA(EARO), установив нужный статус. Поскольку не выполняется обмена сообщениями EDAR и EDAC для адресов Link-Local, 6LR может сразу же ответить на регистрацию адреса Link-Local, основываясь лишь на имеющемся состоянии и опции SLLA, помещённой в сообщение NS(EARO) в соответствии с [RFC6775].

Узел регистрирует свои уникальные в глобальном масштабе адреса IPv6 (Global Unicast Address или GUA) на 6LR для обеспечения глобальной доступности этих адресов через данный маршрутизатор 6LR. При регистрации с обновлённым 6LR регистрирующий узел не использует GUA как Source Address в отличие от узла, соответствующего [RFC6775]. Для адресов, не относящихся к Link-Local обмен сообщениями EDAR и EDAC должен выполняться в соответствии с [RFC6775], но применяются описанные здесь расширенные форматы DAR и DAC для ретрансляции расширенных сведений в случае EARO.

5.7. Поддержка состояний регистрации

В этом разделе рассматриваются действия протокола, вовлекающие Registering Node, 6LR и 6LBR. Нужно подчеркнуть, что действия с 6LBR применимы лишь к зарегистрированным на этом маршрутизаторе адресам, но это не относится к адресам Link-Local, как указано в параграфе 5.6. Состояние регистрации включает все данные, хранящиеся в маршрутизаторе для этой регистрации, включая NCE. Маршрутизаторы 6LBR и Routing Registrar могут хранить дополнительные сведения и применять протоколы синхронизации, не включённые в этот документ.

6LR не может воспринять новую регистрацию при нехватке места в регистрационном хранилище. В такой ситуации опция EARO возвращается в сообщении NA с кодом состояния Neighbor Cache Full (Status 2, см. [RFC6775] и таблицу 1) и регистрирующий узел может попытаться выполнить регистрацию на другом 6LR.

При заполненном реестре 6LBR не может решить, является ли регистрация нового адреса дубликатом. В таком случае 6LBR отвечает на EDAR сообщением EDAC с новым кодом состояния 6LBR Registry Saturated (таблица 1). Отметим, что этот код применяется 6LBR вместо кода Neighbor Cache Full при ответе в обмене сообщениями Duplicate Address и передаётся регистрирующему узлу маршрутизатором 6LR. Узлу нет смысла повторять регистрацию на другом 6LR, поскольку проблема охватывает всю сеть. Узел может отказаться от этого адреса, отменить регистрацию других адресов для освобождения места или сохранить адрес как «пробный» [RFC4861] для последующего повтора.

Узел обновляет регистрацию путём передачи нового сообщения NS(EARO) для зарегистрированного адреса и 6LR должен сообщить о новой регистрации маршрутизатору 6LBR.

Узлу, прекращающему использовать адрес, следует попытаться отменить его регистрацию на всех 6LR, где адрес был зарегистрирован. Это делается с помощью сообщений NS(EARO) с Registration Lifetime = 0. Если этого не сделать, состояние будет оставаться в сети до завершения текущего Registration Lifetime, что может приводить к истощению ресурсов 6LR даже в случае их корректного планирования. 6LR может применять меры защиты, препятствующие данному узлу или иным узлам владеть запрашиваемым числом адресов (см. 7. Вопросы безопасности).

Узлу, уходящему с конкретного 6LR, следует попытаться отменить на нем регистрацию всех своих адресов и зарегистрироваться на другом 6LR с увеличением TID. Если узел появляется в другом месте, следует использовать асинхронное сообщение NA(EARO) или EDAC с кодом состояния Moved для очистки состояния в прежнем месте. Статус Moved может указывать Routing Registrar в сообщении NA(EARO) для индикации передачи права владения прокси-состоянием другому Routing Registrar в результате перемещения устройства. Если у получателя сообщения есть статус регистрации, соответствующий адресу, ему следует распространить статус по пути пересылки к зарегистрированному узлу (например, обратив имеющийся путь RPL [RFC6550], как предложено в [Efficient-NPDAO]). Независимо от этого, получатель должен очистить указанное состояние.

При получении NS(EARO) с Registration Lifetime = 0 и признании EARO наиболее свежим для данной записи NCE (см. 5.2. Идентификатор транзакции), 6LR сбрасывает NCE. Если адрес был зарегистрирован на 6LBR, маршрутизатор 6LR должен уведомить 6LBR через обмен Duplicate Address, указав Registration Lifetime = 0 и последнее известное значений TID.

При получении сообщения EDAR маршрутизатор 6LBR определяет, является ли TID последним для конкретной записи. Если это так, он отвечает на EDAR сообщением EDAC с кодом статуса 0 (Success) [RFC6775], а запись планируется для удаления. В иных случаях возвращается статус Moved и имеющаяся запись сохраняется.

Когда для адреса запланировано удаления, маршрутизатору 6LBR следует сохранять для него запись NCE со статусом DELAY [RFC4861] в течение настраиваемого интервала для предотвращения ситуаций, когда (1) мобильный узел, отозвавший регистрацию на одном 6LR, ещё не зарегистрировался на другом или (2) новая регистрация ещё не достигла 6LBR в результате задержки в сети. По прошествии заданного времени 6LBR просто удаляет запись.

6. Совместимость с прежними версиями

Эта спецификация меняет поведение партнёров в потоке регистрации. Для совместимости с прежними версиями узел 6LN, регистрирующийся на 6LR, для которого нет сведений о поддержке данной спецификации, должен вести себя в соответствии с [RFC6775]. Если же известно о поддержке 6LR данной спецификации, 6LN должен следовать ей.

Узел 6LN, поддерживающий эту спецификацию, должен всегда применять EARO вместо ARO при регистрации на маршрутизаторе. Это поведение совместимо с прежним, поскольку флаг T и поле TID занимают резервные поля [RFC6775] и будут игнорироваться маршрутизатором, поддерживающим лишь RFC 6775. Поддерживающий эту спецификацию маршрутизатор должен отвечать на NS(ARO) и NS(EARO) сообщением NA(EARO). Не поддерживающий эту спецификацию маршрутизатор будет считать ROVR адресом EUI-64 и соответственно обрабатывать поле. Это не вызовет проблем, если зарегистрированные адреса различаются.

6.1. Поддержка сигнализации EARO

В [RFC7400] определена опция 6CIO, указывающая партнёру возможности узла. Эта опция должна присутствовать в сообщениях RS и RA, если она сведения из неё не известна из предшествующего обмена или не заданы на всех узлах сети. В любом случае опция 6CIO должна помещаться в сообщение RA, передаваемое в ответ на RS с опцией 6CIO.

В параграфе 4.3 задан новый флаг для 6CIOУказывающий поддержку EARO отправителем сообщения. Добавлены также новые флаги 6CIO для указания возможностей отправителя, являющегося 6LR, 6LBR или Routing Registrar (см. параграф 4.3). Там же задан флаг, указывающий поддержку сообщений EDAR и EDAC маршрутизатором 6LBR. Этот флаг действует лишь в сообщениях RA, но не в RS. Дополнительные сведения о 6LBR размещаются в отдельной опции ABRO (Authoritative Border Router Option), помещаемой в RA в соответствии с [RFC6775]. В частности, она должна включаться в сообщения RA, передаваемые в ответ на RS с опцией 6CIO, указывающей возможность выступать в качестве 6LR, поскольку сообщения RA распространяют сведения между маршрутизаторами.

6.2. 6LN с поддержкой только RFC 6775

Поддерживающий лишь RFC 6775 узел 6LN будет использовать зарегистрированный адрес как Source Address в сообщении NS и не будет применять его в EARO. Обновленный 6LR должен воспринимать такую регистрацию, если она действительная в соответствии с [RFC6775], и должен поддерживать соответствующую привязку кэша. Обновленный 6LR должен после этого использовать сообщения DAR и DAC, соответствующие [RFC6775], для индикации маршрутизатору 6LBR отсутствия TID в сообщениях.

Основное отличие от [RFC6775] заключается в том, что обмен сообщениями DAR и DAC для целей DAD не применяется для адресов Link-Local. В любом случае маршрутизатор 6LR должен использоваться EARO в отклике и может указывать любые коды состояния, определённые в этой спецификации.

6.3. 6LR с поддержкой только RFC 6775

Обновленный узел 6LN раскрывает возможности 6LR в опции 6CIO сообщений RA от 6LR. При отсутствии 6CIO в RA предполагается, что 6LR поддерживает лишь RFC 6775. Обновленный узел 6LN должен использовать EARO в запросе независимо от типа 6LR (RFC 6775 или обновленный), это предполагает установку флага T. Узел должен использовать ROVR размером 64 бита, если 6LR поддерживает лишь RFC 6775.

Если обновленный узел 6LN переходит от обновлённого 6LR к маршрутизатору 6LR, поддерживающему лишь RFC 6775, последний будет передавать сообщение DAR в соответствии с RFC 6775, которое невозможно сравнить с обновлённым в плане свежести. Разрешение сообщениям DAR, соответствующим лишь RFC 6775, обновлять состояние, созданное обновлённым протоколом в 6LBR, открывает возможность для атак, поэтому его невозможно принять по умолчанию. Однако при временном существовании в сети обновлённых и унаследованных 6LR для администратора имеет смысл установить политику, разрешающую такое поведение, с использованием той или иной защиты, выходящей за рамки этого документа.

6.4. 6LBR с поддержкой только RFC 6775

Эта спецификация расширяет сообщения о дубликатах адресов для передачи EARO. Как и в случае с сообщениями NS и NA, обновленный маршрутизатор 6LBR должен всегда применять сообщения EDAR и EDAC.

Отметим, что поддерживающий лишь RFC 6775 маршрутизатор 6LBR будет воспринимать и обрабатывать сообщение EDAR, как обычное сообщение DAR (RFC 6775), пока размер ROVR составляет 64 бита. Обновленный маршрутизатор 6LR раскрывает возможности 6LBR через опцию 6CIO в сообщениях RA от 6LR – при отсутствии 6CIO в сообщениях RA предполагается, что 6LBR поддерживает лишь RFC 6775.

Если 6LBR поддерживает лишь RFC 6775, маршрутизатор 6LR должен использовать лишь 64 первых (слева) бита ROVR и помещать результат в сообщение EDAR для поддержки совместимости. Таким образом, сохраняется поддержка DAD.

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

Эта спецификация расширяет [RFC6775] и раздел «Вопросы безопасности» того документа применим и к этому. В частности, канальному уровню следует быть защищённым для предотвращения несанкционированного доступа.

[RFC6775] не защищает содержимое своих сообщений и ожидает, что шифрование нижележащего уровня предотвратит возможные атаки. Эта спецификация требует от MAC-уровня LLN защиты индивидуального трафика к Routing Registrar и от него, а также защиты группового и широковещательного трафика от Routing Registrar для предотвращения вмешательства и повторного использования сообщений ND.

Эта спецификация рекомендует применять защиту приватности (раздел 8) и предотвращения кражи адресов с помощью методов, выходящих за рамки этого документа. Например, [AP-ND] гарантирует владение зарегистрированным адресом на основе криптографических ROVR.

Мошеннический узел может использовать механизм регистрации для атаки на 6LR или 6LBR с целью провоцирования отказов в обслуживании реестра. Реестры 6LR или 6LBR могут переполняться и отказывать в регистрации, что будет препятствовать запрашивающим узлам в использовании новых адресов. Для снижения этих рисков (1) раздел 5.2 предоставляет счётчик инкрементирование которого позволяет обнаруживать и сбрасывать устаревшие состояния регистрации а также способствует отражению атак с повторным использованием пакетов, а (2) раздел 5.7 содержит рекомендации, позволяющие удалять устаревшие регистрации из 6LR и 6LBR как можно быстрее.

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

  • Прекращающему использовать адрес узлу следует попытаться отменить регистрацию адреса на всех 6LR, где он был зарегистрирован.

  • Срок регистрации следует делать индивидуально настраиваемым для каждого адреса или группы адресов. Узлу следует настраивать для каждого адреса (категории адресов) срок ожидаемый регистрации в маршрутизаторе 6LR, где адрес зарегистрирован. В частности, при развёртывании с мобильными или часто меняющимися адресами следует использовать сроки регистрации с порядком значения близким к ожидаемому сроку присутствия с некоторым запасом по времени.

  • Маршрутизаторам (6LR и 6LBR) следует быть настраиваемыми для ограничения числа адресов, которые может регистрировать 1 узел, в качестве меры защиты. В любом случае маршрутизатор должен быть способен поддерживать минимальное число адресов для каждого узла, зависящее от типа устройства, и составляющее от 3 для сильно ограниченных LLN до 10 для более крупных устройств. Узел может распознаваться по его MAC-адресу, если тот не маскируется по соображениям приватности. Рекомендуется применять более строгую (например, по криптографическим свидетельствам) идентификацию узлов. При достижении максимального числа адресов маршрутизатору следует использовать алгоритм LRU5 для очистки адресов, сохраняя хотя бы 1 адрес Link-Local. Маршрутизатору следует пытаться сохранить хотя бы один стабильный адрес, если стабильность можно проверить (например, используемый дольше других адрес).

  • Для предотвращения отказов при регистрации по причине нехватки ресурсов администраторам следует проявлять осторожность и развёртывать достаточно число 6LR в соответствии с потребностями узлов в зоне действия маршрутизаторов. Предполагается, что 6LBR, обслуживающий сеть LLN, является более мощным, чем средний 6LR, но в сети, которая может достигать насыщения, конкретной LLN следует распределять функции 6LBR, например, используя скоростные магистрали и Routing Registrar для объединения LLN.

Узлы LLN зависят от 6LBR и могут применять для своей работы услуги Routing Registrar. Должна быть реализована модель доверия, обеспечивающая возможность служить регистраторами лишь доверенным устройствам, чтобы избежать таких угроз, как «чёрные дыры» или «бомбардировки», когда подставной 6LBR будет нарушать состояние сети, используя статус Removed. Модель доверия должна, как минимум, использовать контроль доступа L2 или проверку ролей (см. Req-5.1 в Приложении B.5).

8. Вопросы приватности

Как указано в разделе 3, этот протокол не ограничивает число адресов IPv6 для каждого устройства. Однако для смягчения атак на службы могут оказаться полезными защитные меры по ограничению числа адресов с достаточно высоким пределом, не препятствующим обычной работе устройств. Хостам следует поддерживать возможность создания и регистрации любых адресов, топологически корректных в подсети, анонсируемой 6LR/6LBR.

Эта спецификация не требует определённого способа формирования адресов IPv6, но не рекомендует применять EUI-64 для формирования индикаторов интерфейса с адресом Link-Local, поскольку это препятствует использованию безопасного обнаружения соседей (Secure Neighbor Discovery или SEND) [RFC3971], криптографического создания адресов (Cryptographically Generated Address или CGA) [RFC3972] и других механизмов защиты приватности.

В [RFC8065] (Privacy Considerations for IPv6 Adaptation-Layer Mechanisms) разъясняется важность приватности и способы формирования адресов с учётом приватности. Все реализации и развёртывания должны учитывать вопросы приватности адресов в своих средах.

Адрес IPv6 узла 6LN в заголовке IPv6 может быть сжат без учёта состояния, если идентификатор интерфейса в адресе IPv6 можно получить из адреса нижележащего уровня. Когда экономия в результате сжатия не критична, например, адреса можно сжать с учётом состояния, применяется редко и/или на одном интервале пересылки, следует учитывать соображения приватности. В частности, новым реализациям следует соблюдать [RFC8064] (Recommendation on Stable IPv6 Interface Identifiers), где рекомендован заданный в [RFC7217] (A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)) механизм создания идентификаторов интерфейсов для использования в SLAAC.

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

Агентство IANA внесло множество изменений в реестр Internet Control Message Protocol version 6 (ICMPv6) Parameters.

9.1. Флаги опции ARO

В IANA создан новый субреестр Address Registration Option Flags в реестре Internet Control Message Protocol version 6 (ICMPv6) Parameters (сведения, относящиеся к ICMPv6, приведены в [RFC4443]). Эта спецификация определяет 8 битов (от 0 до 7) и выделяет бит 6 для флага R, а бит 7 – для флага T (см. 4.1. Расширенная опция ARO (EARO)). Биты выделяются в соответствии с процедурой IETF Review или IESG Approval (см. [RFC8126]). Исходное содержимое реестра указано в таблице 2.

Таблица 2. Новые флаги опции ARO.

Бит

Описание

Документ

0-5

Не выделен

6

Флаг R

RFC 8505

7

Флаг T

RFC 8505

9.2. Поле ARO I

В IANA создан новый субреестр Address Registration Option I-Field в реестре Internet Control Message Protocol version 6 (ICMPv6) Parameters. Эта спецификация определяет 4 целочисленных значения (0 – 3) и выделяет значение 0 для абстрактного индекса выбора топологии (Abstract Index for Topology Selection, см. 4.1. Расширенная опция ARO (EARO)). Значения выделяются в соответствии с процедурой IETF Review или IESG Approval (см. [RFC8126]). Исходное содержимое реестра указано в таблице 3.

Таблица 3. Новый субреестр для поля EARO I.

Значение

Описание

Документ

0

Abstract Index for Topology Selection

RFC 8505

1-3

Не выделены

9.3. Коды ICMP

В IANA создано два новых субреестра в реестре ICMPv6 “Code” Fields, который сам является субреестром кодов ICMPv6 в реестре Internet Control Message Protocol version 6 (ICMPv6) Parameters. Субреестры относятся к типам ICMP 157 (Duplicate Address Request, таблица 4) и 158 (Duplicate Address Confirmation, таблица 5). Для этих типов ICMP поле ICMP Code делится на две части – Code Prefix и Code Suffix и новые субреестры относятся к суффиксам, которые могут принимать значения от 0 до 15. Значения выделяются по процедуре IETF Review или IESG Approval (см. [RFC8126]).

Таблица 4. Суффиксы кодов для сообщений ICMP Type 157 DAR.

Суффикс

Описание

Документ

0

Сообщение DAR

RFC 6775

1

Сообщение EDAR 64-битовым полем ROVR

RFC 8505

2

Сообщение EDAR 128-битовым полем ROVR

RFC 8505

3

Сообщение EDAR 192-битовым полем ROVR

RFC 8505

4

Сообщение EDAR 256-битовым полем ROVR

RFC 8505

5-15

Не выделены

Таблица 5. Суффиксы кодов для сообщений ICMP Type 158 DAC.

Суффикс

Описание

Документ

0

Сообщение DAC

RFC 6775

1

Сообщение EDAC 64-битовым полем ROVR

RFC 8505

2

Сообщение EDAC 128-битовым полем ROVR

RFC 8505

3

Сообщение EDAC 192-битовым полем ROVR

RFC 8505

4

Сообщение EDAC 256-битовым полем ROVR

RFC 8505

5-15

Не выделены

9.4. Новые значения ARO Status

Агентство IANA добавило в субреестр Address Registration Option Status Values значения, указанные в таблице 6.

Таблица 6. Новые значения ARO Status.

Значение

Описание

Документ

3

Перемещён

RFC 8505

4

Удалён

RFC 8505

5

Запрошена проверка

RFC 8505

6

Дубликат адреса отправителя

RFC 8505

7

Недействительный адрес отправителя

RFC 8505

8

Регистрируемый адрес топологически некорректен

RFC 8505

9

Реестр 6LBR переполнен

RFC 8505

10

Отказ при проверке

RFC 8505

9.5. Новые биты 6LoWPAN Capability

Агентство IANA добавило в субреестр 6LoWPAN Capability Bits биты, указанные в таблице 7.

Таблица 7. Новые биты возможностей 6LoWPAN.

Бит

Описание

Документ

10

Поддержка EDA (D)

RFC 8505

11

Возможности 6LR (L)

RFC 8505

12

Возможности 6LBR (B)

RFC 8505

13

Регистратор маршрутизации (P)

RFC 8505

14

Поддержка EARO (E)

RFC 8505

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

[RFC4291] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.

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

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

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

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

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

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

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

[Alternative-Ellip-Curve-Reps] Struik, R., “Alternative Elliptic Curve Representations”, Work in Progress, draft-struik-lwip-curve-representations-00, October 2017.

[AP-ND] Thubert, P., Ed., Sarikaya, B., Sethi, M., and R. Struik, “Address Protected Neighbor Discovery for Low-power and Lossy Networks”, Work in Progress, draft-ietf-6lo-ap-nd-086, October 2018.

[Arch-for-6TiSCH] Thubert, P., Ed., “An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4”, Work in Progress, draft-ietf-6tisch-architecture-17, November 2018.

[Efficient-NPDAO] Jadhav, R., Ed., Thubert, P., Sahoo, R., and Z. Cao, “Efficient Route Invalidation”, Work in Progress, draft-ietf-roll-efficient-npdao-097, October 2018.

[IEEE-802-15-4] IEEE, “IEEE Standard for Low-Rate Wireless Networks”, IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, <https://ieeexplore.ieee.org/document/7460875/>.

[IPv6-Backbone-Router] Thubert, P., Ed. and C. Perkins, “IPv6 Backbone Router”, Work in Progress, draft-ietf-6lo-backbone-router-088, October 2018.

[IPv6-over-802.11ah] Del Carpio Vega, L., Robles, M., and R. Morabito, “IPv6 over 802.11ah”, Work in Progress, draft-delcarpio-6lo-wlanah-01, October 2015.

[IPv6-over-NFC] Choi, Y., Ed., Hong, Y-G., Youn, J-S., Kim, D-K., and J-H. Choi, “Transmission of IPv6 Packets over Near Field Communication”, Work in Progress, draft-ietf-6lo-nfc-12, November 2018.

[IPv6-over-PLC] Hou, J., Liu, B., Hong, Y-G., Tang, X., and C. Perkins, “Transmission of IPv6 Packets over PLC Networks”, Work in Progress, draft-hou-6lo-plc-05, October 2018.

[Multicast-over-IEEE802-Wireless] Perkins, C., McBride, M., Stanley, D., Kumari, W., and JC. Zuniga, “Multicast Considerations over IEEE 802 Wireless Media”, Work in Progress, draft-ietf-mboned-ieee802-mcast-problems-03, October 2018.

[ND-Optimizations] Chakrabarti, S., Nordmark, E., Thubert, P., and M. Wasserman, “IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks”, Work in Progress, draft-chakrabarti-nordmark-6man-efficient-nd-07, February 2015.

[Perlman83] Perlman, R., “Fault-Tolerant Broadcast of Routing Information”, North-Holland Computer Networks 7: pp. 395-405, DOI 10.1016/0376-5075(83)90034-X, 1983, <http://www.cs.illinois.edu/~pbg/courses/cs598fa09/readings/p83.pdf>.

[RFC1958] Carpenter, B., Ed., “Architectural Principles of the Internet”, RFC 1958, DOI 10.17487/RFC1958, June 1996, <https://www.rfc-editor.org/info/rfc1958>.

[RFC1982] Elz, R. and R. Bush, “Serial Number Arithmetic”, RFC 1982, DOI 10.17487/RFC1982, August 1996, <https://www.rfc-editor.org/info/rfc1982>.

[RFC3610] Whiting, D., Housley, R., and N. Ferguson, “Counter with CBC-MAC (CCM)”, RFC 3610, DOI 10.17487/RFC3610, September 2003, <https://www.rfc-editor.org/info/rfc3610>.

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

[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, “SEcure Neighbor Discovery (SEND)”, RFC 3971, DOI 10.17487/RFC3971, March 2005, <https://www.rfc-editor.org/info/rfc3971>.

[RFC3972] Aura, T., “Cryptographically Generated Addresses (CGA)”, RFC 3972, DOI 10.17487/RFC3972, March 2005, <https://www.rfc-editor.org/info/rfc3972>.

[RFC4429] Moore, N., “Optimistic Duplicate Address Detection (DAD) for IPv6”, RFC 4429, DOI 10.17487/RFC4429, April 2006, <https://www.rfc-editor.org/info/rfc4429>.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, RFC 4941, DOI 10.17487/RFC4941, September 2007, <https://www.rfc-editor.org/info/rfc4941>.

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

[RFC7217] Gont, F., “A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)”, RFC 7217, DOI 10.17487/RFC7217, April 2014, <https://www.rfc-editor.org/info/rfc7217>.

[RFC7428] Brandt, A. and J. Buron, “Transmission of IPv6 Packets over ITU-T G.9959 Networks”, RFC 7428, DOI 10.17487/RFC7428, February 2015, <https://www.rfc-editor.org/info/rfc7428>.

[RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, “IPv6 over BLUETOOTH(R) Low Energy”, RFC 7668, DOI 10.17487/RFC7668, October 2015, <https://www.rfc-editor.org/info/rfc7668>.

[RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, “Host Address Availability Recommendations”, BCP 204, RFC 7934, DOI 10.17487/RFC7934, July 2016, <https://www.rfc-editor.org/info/rfc7934>.

[RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, “Recommendation on Stable IPv6 Interface Identifiers”, RFC 8064, DOI 10.17487/RFC8064, February 2017, <https://www.rfc-editor.org/info/rfc8064>.

[RFC8065] Thaler, D., “Privacy Considerations for IPv6 Adaptation-Layer Mechanisms”, RFC 8065, DOI 10.17487/RFC8065, February 2017, <https://www.rfc-editor.org/info/rfc8065>.

[RFC8105] Mariager, P., Petersen, J., Ed., Shelby, Z., Van de Logt, M., and D. Barthel, “Transmission of IPv6 Packets over Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE)”, RFC 8105, DOI 10.17487/RFC8105, May 2017, <https://www.rfc-editor.org/info/rfc8105>.

[RFC8163] Lynn, K., Ed., Martocci, J., Neilson, C., and S. Donaldson, “Transmission of IPv6 over Master-Slave/Token-Passing (MS/TP) Networks”, RFC 8163, DOI 10.17487/RFC8163, May 2017, <https://www.rfc-editor.org/info/rfc8163>.

[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., Przygienda, T., and S. Aldrin, “Multicast Using Bit Index Explicit Replication (BIER)”, RFC 8279, DOI 10.17487/RFC8279, November 2017, <https://www.rfc-editor.org/info/rfc8279>.

[Routing-for-RPL-Leaves] Thubert, P., Ed., “Routing for RPL Leaves”, Work in Progress, draft-thubert-roll-unaware-leaves-05, May 2018.

Приложение A. Применимость и выполненные требования

Эта спецификация расширяет 6LoWPAN ND для включения порядкового номера регистрации и выполнения требования Приложения B.1, за счёт разрешения узлам перемещаться из одной сети LLN в другую. Полная спецификация для обеспечения мобильности на основе использования EARO и определённых в этом документе процедур регистрации приведена в [IPv6-Backbone-Router] (IPv6 Backbone Router). 6BBR является примером регистратора маршрутизации, который выступает как IPv6 ND через магистральный канал, объединяющий несколько LLN и сам канал в одну подсеть IPv6. Предполагаемый поток регистрации для этого случая показан на рисунке 6, где отмечена возможность совмещения любой комбинации 6LR, 6LBR, 6BBR.

6LN              6LR             6LBR            6BBR
 |                |               |                |
 |   NS(EARO)     |               |                |
 |--------------->|               |                |
 |                | Extended DAR  |                |
 |                |-------------->|                |
 |                |               |                |
 |                |               | proxy NS(EARO) |
 |                |               |--------------->|
 |                |               |                | NS(DAD)
 |                |               |                | ------>
 |                |               |                | <ожидание>
 |                |               |                |
 |                |               | proxy NA(EARO) |
 |                |               |<---------------|
 |                | Extended DAC  |                |
 |                |<--------------|                |
 |   NA(EARO)     |               |                |
 |<---------------|               |                |
 |                |               |                |

Рисунок 6. Поток (пере)регистрации.


В [Arch-for-6TiSCH] (An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4) описано, как хост 6LoWPAN ND в режиме переключения каналов с разделением по времени (Time-Slotted Channel Hopping или TSCH) IEEE Std. 802.15.4 [IEEE-802-15-4] можно подключить к Internet через mesh-сеть RPL. Для этого нужно дополнить в протокол 6LoWPAN ND поддержку мобильности и доступности в защищённой управляемой сетевой среде. Этот документ определяет новые операции и выполняет требования, приведённые в Приложении B.2.

Термин LLN в этом документе применяется в широков смысле и охватывает разные типы сетей WLAN и WPAN, включая Low-Power IEEE Std. 802.11, Bluetooth, IEEE Std. 802.11ah и беспроводные mesh-сети IEEE Std. 802.15.4, чтобы выполнить требования к адресам из Приложения B.3.

Эту спецификацию может применять любой беспроводный узел для регистрации своих адресов IPv6 Addresses в Routing Registrar и получения услуг маршрутизации, таких как операции proxy ND через магистральный канал. Это соответствует требованиям Приложения B.4.

Спецификация расширена [AP-ND] для выполнения некоторых связанных с защитой требования Приложения B.5.

В [ND-Optimizations] (IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks) предполагается, что 6LoWPAN ND [RFC6775] можно расширить на другие каналы (сверх IEEE Std. 802.15.4). Метод регистрации полезен, когда применяемый для доставки групповых пакетов IPv6 метод канального уровня недостаточно эффективен в части доставки или потребления энергии в оконечных устройствах (в частности, спящих устройствах с малым потреблением энергии). Значимость такого расширения особенно заметна в случае мобильных беспроводных устройств для снижения группового трафика, связанного с IPv6 ND [RFC4861] [RFC4862] и влияющего на работу беспроводной среды [Multicast-over-IEEE802-Wireless]. Это соответствует требованиям к расширяемости из Приложения B.6.

Приложение B. Требования (не нормативные)

В этом Приложении указаны требования, обсуждавшиеся рабочей группой 6lo для обновления 6LoWPAN ND. Соответствие этих требования имеющимся спецификациям показано в таблице 8.

B.1. Требования, связанные с мобильностью

По причине нестабильности соединений LLN даже стационарные узлы 6LN могут менять точку подключения, например, может произойти смена 6LR-a на 6LR-b, но при этом может не быть возможности уведомить от этом 6LR-a. В результате 6LR-a может привлекать трафик, который он не может больше доставлять. При смене состояния каналов к 6LR нужно идентифицировать устаревшие состояния в 6LR и своевременно восстанавливать доступность, например, с помощью сигналов при обнаружении перемещения или сообщений keep-alive с периодом, соответствующим потребностям приложения.

Req-1.1

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

Req-1.2

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

Req-1.3

Устаревшие состояния должны очищаться в 6LR.

Req-1.4

Узлам 6LN следует также обеспечивать возможность регистрации своего адреса на нескольких 6LR.

B.2. Требования, связанные с протоколами маршрутизации

Точкой подключения 6LN может быть 6LR в mesh-сети LLN. Маршрутизация IPv6 в сети LLN может быть основана на протоколе RPL, определённом IETF для этой конкретной задачи. Органы стандартизации (Standards Development Organization или SDO) рассматривают и другие протоколы на основе ожидаемых характеристик сети. 6LN, подключённому через ND к 6LR, нужно указывать (1) своё участие в протоколах маршрутизации для получения связности через 6LR или (2) предполагать, что связность обеспечивает 6LR.

Указанные обновления позволяют другим спецификациям определять новые службы, такие как улучшенная проверка адресов отправителей (Source Address Validation Improvement или SAVI) (с помощью [AP-ND]), участие в качестве неосведомленного листа в протоколе маршрутизации (например, описанном в [RFC6550] протоколе RPL) (с помощью [Routing-for-RPL-Leaves]), и регистрации магистральных маршрутизаторов в качестве посредников ND в сети LLN (с помощью [IPv6-Backbone-Router]).

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

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

Архитектура BIER9 [RFC8279] предлагает оптимизированный метод поддержки групповой адресации в LLN с весьма ограниченными требованиями к состоянию маршрутизации на узлах.

Req-2.1

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

Req-2.2

С учётом RPL следует расширить опцию ARO, используемую при регистрации, для передачи сведений, позволяющих создать сообщение DAO, как указано в параграфе 6.4 [RFC6550], в частности, рассчитать Path Sequence и, возможно, RPLInstanceID.

Req-2.3

Следует поддерживать и оптимизировать групповые операции, например, использование BIER или MPL10. Приемлемость ND для регистрации в Routing Registrar должна определяться с учётом дополнительных издержек, связанных с регистрацией групповых слушателей (Multicast Listener Discovery Version 2 или MLDv2) для IPv6 [RFC3810].

B.3. Требования, связанные с разными типами каналов со слабым питанием

Механизм 6LoWPAN ND [RFC6775] был определён с акцентом на IEEE Std.802.15.4 и, в частности, возможность вывода идентификатора из глобально уникального адреса EUI-64. В данный момент рабочая группа 6lo расширила метод сжатия заголовков 6LoWPAN HC (Header Compression) [RFC6282] на другие типы каналов, включая ITU-T G.9959 [RFC7428], Master-Slave/Token-Passing [RFC8163], Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy [RFC8105], Near Field Communication [IPv6-over-NFC] и IEEE Std. 802.11ah [IPv6-over-802.11ah], а также сети Bluetooth [RFC7668] и PLC (Power Line Communication) [IPv6-over-PLC].

Req-3.1

Поддержку механизмов регистрации следует расширить на каналы LLN, отличающиеся от IEEE Std.802.15.4, по меньшей мере на каналы, для которых есть спецификации поддержки IPv6 (например, Wi-Fi со слабым питанием).

Req-3.2

В рамках этого расширения следует предоставлять механизм расчёта уникального идентификатора с возможностью создания адреса Link-Local, которому следует быть уникальным в рамках LLN, подключённой к 6LBR, обнаруженному ND, в каждом узле LLN.

Req-3.3

Опцию ARO в регистрации ND следует расширить для формирования подходящего уникального идентификатора.

Req-3.4

ND следует задавать формирование локального для сайта адреса в соответствии с рекомендациями [RFC7217].

B.4. Требования, связанные с операциями Proxy

Работающие в цикле устройства могут не просыпаться в ответ на поиск со стороны узла, использующего IPv6 ND и может потребоваться прокси. Кроме того, таким устройствам может требоваться 6LBR для регистрации в Routing Registrar. Методу регистрации ND следует защищать адреса работающих в цикле устройств, которые большую часть времени «спят» и не способны защитить свои адреса.

Req-4.1

Механизму регистрации следует разрешать сторонним узлам выступать посредником при регистрации адреса от имени 6LN, который может спать или размещаться глубже в структуре LLN.

Req-4.2

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

Req-4.3

Механизму регистрации следует разрешать длительный сон устройств (от нескольких дней до месяца.

B.5. Требования, связанные с безопасностью

Для гарантированной работы потоков 6LoWPAN ND следует избегать подмены ролей 6LR, 6LBR и Routing Registrar. После успешной регистрации узлом своего адреса 6LoWPAN ND следует обеспечивать энергосберегающие способы защиты владения адресов даже для зарегистрированных узлов, находящихся в спящем режиме. В частности, маршрутизаторам 6LR и 6LBR следует поддерживать возможность проверки происхождения последующей регистрации данного адреса от того же узла.

В LLN имеет смысл обеспечивать защиту на базе уровня L2. В процессе загрузки LLN узлы присоединяются к сети через проверку полномочий с помощью Joining Assistant (JA) или Commissioning Tool (CT). После присоединения к сети узлы взаимодействуют по защищённым каналам. Ключи для защиты L2 могут распространяться JA или CT. JA/CT может входить в LLN или находиться все LLN, но в обоих случаях нужно маршрутизировать пакеты между JA/CT и подключающимся узлом.

Req-5.1

Механизмам защиты 6LoWPAN ND следует предоставлять 6LR, 6LBR и Routing Registrar, а также 6LN в роли 6LR средства проверки подлинности и полномочий друг друга в соответствии с ролью.

Req-5.2

Механизмам защиты 6LoWPAN ND следует предоставлять 6LR и 6LBR средства проверки новых регистраций от полномочных устройств. Подключение несанкционированных узлов должно пресекаться.

Req-5.3

Механизмам защиты 6LoWPAN ND не следует сильно увеличивать размер пакетов. В частности, сообщениям NS, NA, DAR, DAC для потока (пере)регистрации не следует быть больше 80 октетов, чтобы они помещались в защищённые кадры IEEE Std.802.15.4 [IEEE-802-15-4].

Req-5.4

Повторяющимся операциям защиты 6LoWPAN ND недопустимо требовать значительной нагрузки на CPU в узлах 6LN. При использовании хэширования ключей следует выбирать механизмы легче SHA-1.

Req-5.5

Число ключей, с которыми приходится работать 6LN, следует минимизировать.

Req-5.6

Механизмам защиты 6LoWPAN ND следует разрешать (1) вариант CCM (Counter with CBC-MAC) [RFC3610], называемый CCM*, для использования на уровнях L2 и L3, а также (2) повторное использование кода защиты, который должен присутствовать на устройстве для вышележащего уровня защиты (например, TLS). Желательна также гибкость и поддержка длинных ключей (например, 256 битов).

Req-5.7

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

Req-5.8

Маршрутизацию пакетов следует продолжать при переходе незащищённого канала в защищённое состояние.

Req-5.9

Механизмам защиты 6LoWPAN ND следует предоставлять 6LR и 6LBR средства проверки соответствия регистрации нового адреса тому же узлу 6LN, который регистрировался изначально. При несоответствии следует определять истинного владельца и отклонять или отвергать регистрацию в случае дубликата.

B.6. Требования, связанные с расширяемостью

Варианты применения автоматического считывания измерителей (Automatic Meter Reading или AMR, операции дерева сбора данных) и расширенной инфраструктуры измерений (Advanced Metering Infrastructure или AMI, двухсторонняя связь между измерителями) показывают наличие большого числа (например, 5000) узлов LLN, относящихся к одному графу RPL DODAG и подключённых к 6LBR через много (например, 15) интервалов пересылки (hop) в LLN.

Req-6.1

Механизму регистрации следует обеспечивать маршрутизатору 6LBR регистрировать тысячи устройств.

Req-6.2

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

B.7. Требования, связанные с эксплуатацией и поддержкой

Параграф 3.8 в [RFC1958] (Architectural Principles of the Internet) гласит: «По возможности избегайте опций и параметров. Любые опции и параметры следует делать настраиваемыми или согласуемыми динамически, а не вручную». Это особенно важно в LLN, где число устройств может быть большим и настройка вручную нежелательна. Возможности динамической настройки устройств LLN также могут быть ограничены сетью или источниками питания.

Администратору сети следует иметь возможность проверить работу сети в пределах возможностей и, в частности, отсутствие переполнения маршрутизаторов 6LBR излишними регистрациями, чтобы можно было при необходимости подключить дополнительные магистральные каналы с дополнительными 6LBR и Routing Registrar.

Req-7.1

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

Req-7.2

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

Req-7.3

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

Req-7.4

В случае отказа при регистрации следует предоставлять сведения об отказе, включая идентификацию узла, отклонившего регистрацию и статус в EARO.

B.8. Соответствие требованиям спецификаций

Таблица 8. Документы с требованиями.

Требование

Документ

Req-1.1

[IPv6-Backbone-Router]

Req-1.2

[RFC6775]

Req-1.3

[RFC6775]

Req-1.4

RFC 8505

Req-2.1

RFC 8505

Req-2.2

RFC 8505

Req-2.3

Req-3.1

Зависит от технологии

Req-3.2

Зависит от технологии

Req-3.3

Зависит от технологии

Req-3.4

Зависит от технологии

Req-4.1

RFC 8505

Req-4.2

RFC 8505

Req-4.3

[RFC6775]

Req-5.1

Req-5.2

[AP-ND]

Req-5.3

Req-5.4

Req-5.5

[AP-ND]

Req-5.6

[Alternative-Ellip-Curve-Reps]

Req-5.7

[AP-ND]

Req-5.8

Req-5.9

[AP-ND]

Req-6.1

RFC 8505

Req-6.2

RFC 8505

Req-7.1

Req-7.2

Req-7.3

Req-7.4

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

Честь и слава Eric Levy-Abegnoli, разработавшему инфраструктуру «защиты первого интервала» (First-Hop Security), на базе которой был реализован первый магистральный маршрутизатор. Большое спасибо Sedat Gormus, Rahul Jadhav, Tim Chown, Juergen Schoenwaelder, Chris Lonvick, Dave Thaler, Adrian Farrel, Peter Yee, Warren Kumari, Benjamin Kaduk, Mirja Kuehlewind, Ben Campbell, Eric Rescorla, Lorenzo Colitti за их вклад и рецензии. Спасибо также Thomas Watteyne за первую в мире реализацию 6LN, сыгравшую важную роль в ранних тестах 6LR, 6LBR и Backbone Router.

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

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

Cisco Systems, Inc.

Building D (Regus) 45 Allee des Ormes

Mougins – Sophia Antipolis

France

Phone: +33 4 97 23 26 34

Email: pthubert@cisco.com

Erik Nordmark

Zededa

Santa Clara, CA

United States of America

Email: nordmark@sonic.net

Samita Chakrabarti

Verizon

San Jose, CA

United States of America

Email: samitac.ietf@gmail.com

Charles E. Perkins

Futurewei

2330 Central Expressway

Santa Clara, CA 95050

United States of America

Email: charliep@computer.org



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


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


nmalykh@protokols.ru




1Internet Engineering Task Force.






2Internet Engineering Steering Group.






3Media Access Control – контроль доступа к среде.






4Source Link-Layer Address – адрес отправителя на канальном уровне.






5Least Recently Used – наиболее давно использованный.






6Работа опубликована в RFC 8928. Прим. перев.






7Работа опубликована в RFC 9009. Прим. перев.






8Работа опубликована в RFC 8929. Прим. перев.






9Bit Index Explicit Replication – явная репликация битовых индексов.






10Multicast Protocol for Low-Power and Lossy Networks – групповой протокол для сетей LLN.



 											


		
						

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

					


					

					
			




	

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