RFC 6775 Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

Опубликовано 27.11.2012 автором Nikolai Malykh 
Internet Engineering Task Force (IETF)                    Z. Shelby, Ed.
Request for Comments: 6775                                     Sensinode
Updates: 4944                                             S. Chakrabarti
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                              E. Nordmark
                                                           Cisco Systems
                                                              C. Bormann
                                                 Universitaet Bremen TZI
                                                           November 2012

Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)

Оптимизация обнаружения соседей для сетей 6LoWPAN

PDF

Аннотация

Работа IETF по персональным беспроводным сетям IPv6 определила сети 6LoWPAN1, такие как IEEE 802.15.4. Эта технология и похожие на неё не применяют или ограничены в применении групповой сигнализации требованиями энергосбережения. Кроме того, беспроводные сети могут не следовать строго концепции подсетей и каналов IP. Протокол обнаружения соседей IPv6 (Neighbor Discovery или ND) не предназначен для нетранзитивных беспроводных каналов, поскольку его зависимость от концепции традиционных каналов IPv6 и активное применение групповой адресации неэффективны, а иногда просто не подходят для сетей со слабым питанием и потерями. В этом документе описана простая оптимизация IPv6 ND, механизмы адресации и обнаружения дубликатов адресов для беспроводных сетей со слабым питанием. Этот документ обновляет RFC 4944, задавая использование описанной здесь оптимизации.

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

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

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

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

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

Авторские права (Copyright (c) 2012) принадлежат 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. Введение

Документ Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944] определяет передачу IPv6 в сетях IEEE 802.15.4 с использованием уровня адаптации между уровнем управления доступом к среде (Media Access Control или MAC) и сетевым уровнем IP. Каналы в персональных беспроводных сетях со слабым питанием (Low-power Wireless Personal Area Network или LoWPAN) характеризуются потерями, малой мощностью, низкой скоростью и небольшими расстояниями, при этом многие устройства могут долго находиться в спящем режиме в целях экономии энергии. Применяемая в обнаружении соседей IPv6 ND [RFC4861] групповая адресация нежелательна в сетях LoWPAN. Кроме того, каналы LoWPAN по своей природе являются асимметричными и непереходными. Сеть LoWPAN может включать множество перекрывающихся частотных диапазонов. Хотя каждый диапазон поддерживает широковещание, их комбинация представляет собой сложную структуру с множественным доступом без широковещания (Non-Broadcast Multiple Access или NBMA) [RFC2491], в которой обычно не поддерживается групповой адресации в масштабе LoWPAN. Область локального канала (Link-local) на деле определяется достижимостью и мощностью радиосигнала. Таким образом, можно считать сеть LoWPAN состоящей из каналов с неопределёнными свойствами связности [RFC5889] в сочетании с допущениями определённой здесь модели адресации.

Эта спецификация вносит указанную ниже оптимизацию IPv6 ND [RFC4861], нацеленную на сети со слабым питанием и потерями, такие как LoWPAN:

  • инициируемое хостом взаимодействие для поддержки спящих хостов;

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

  • регистрация адресов хостов с использованием индивидуальных сообщений запроса соседства (Neighbor Solicitation или NS) и анонсирования соседа (Neighbor Advertisement или NA);

  • новая опция ND для распространения контекста сжатия заголовков 6LoWPAN на хосты;

  • распространение префиксов и контекста сжатия заголовков 6LoWPAN через несколько узлов пересылки (multihop);

  • обнаружение дубликатов адресов (Duplicate Address Detection или DAD) через несколько узлов пересылки с использованием двух новых типов сообщений ICMPv6.

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

Документ определяет 3 новых опции сообщений ICMPv6 – ARO (опция регистрации адреса – Address Registration Option), ABRO (опция полномочного граничного маршрутизатора – Authoritative Border Router Option) и 6CO (опция контекста 6LoWPAN – 6LoWPAN Context Option). Также определены 2 новых типа сообщений ICMPv6 – запрос о дубликатах адреса (Duplicate Address Request или DAR) и подтверждение дублирования адреса (Duplicate Address Confirmation или DAC).

1.1. Недостатки обнаружения соседей IPv6 ND

IPv6 ND [RFC4861] обеспечивает несколько важных механизмов для обнаружения маршрутизаторов, распознавания адресов, обнаружения дубликатов и сообщений Redirect, а также обнаружения префиксов и параметров.

После включения и инициализации сети IPv6 Ethernet узел присоединяет групповой адрес solicited-node на своём интерфейсе и выполняет процедуру обнаружения DAD для полученного адреса на локальном канале (link-local) путём отправки в канал группового сообщения по адресу solicited-node. После этого узел передаёт групповые сообщения по адресу all-routers для запроса анонсов маршрутизаторов (Router Advertisement или RA). При получении хостом действительного RA с флагом A (автономная настройка адреса) он автоматически настраивает адрес IPv6 с анонсированным в RA префиксом. Кроме того, маршрутизаторы IPv6 обычно периодически отправляют в сеть анонсы RA по групповому адресу all-nodes. Узлы передают сообщения Neighbor Solicitation/Neighbor Advertisement для распознавания адреса IPv6 получателя на канале. Сообщения с запросом соседства (Neighbor Solicitation или NS), используемые для распознавания адресов являются групповыми. Процедура DAD и использование периодических сообщений RA предполагают, что узлы большую часть времени включены и доступны.

В ND маршрутизаторы находят хосты, предполагая, что префикс подсети соответствует одному широковещательному домену, а затем передают групповые сообщения NS для поиска хостов и их адресов канального уровня. Кроме того, процедура DAD использует групповую адресацию, предполагая, что все хосты, автоматически настраивающие адреса IPv6 из одного префикса, доступны с использованием одного группового адреса link-local.

Отметим, что бит L (на канале) в опции сведений о префиксе (Prefix Information Option или PIO) может быть сброшен (0) в ND, что отключает использование хостом групповых сообщений NS для распознавания адресов других хостов, но маршрутизаторы все равно применяют групповые сообщения NS для поиска хостов.

По причине потерь в беспроводных сетях и изменчивости радио-окружения набор узлов на канале IPv6 может меняться в зависимости от внешних физических факторов. Канал зачастую нестабилен и узлы могут переходить на другие каналы даже без физического перемещения.

В LoWPAN могут применяться два типа адресов канального уровня – короткие 16-битовые адреса и уникальные 64-битовые адреса, определённые в [RFC4944]. Кроме того, доступный объем данных (payload) на канальном уровне может снижаться до 100 (и менее) байтов, что делает полезным сжатие заголовков.

С учётом упомянутых выше характеристик LoWPAN и устройства протокола IPv6 ND[RFC4861] оптимизация и расширения протокола обнаружения соседей будут полезны для широкого развёртывания IPv6 в сетях со слабым питанием и потерями (например, 6LoWPAN и другие однородные сети со слабым питанием).

1.2. Применимость

В разделе 1 [RFC4861] предусмотрен документ, описывающий работу IP для определённого канального уровня и определяющий исключения из общепринятого [RFC4861]. Данная спецификация расширяет применение IPv6 ND на сети LoWPAN в целях экономии энергии и снижения загрузки вычислительных ресурсов на узлах сети. Документ обновляет [RFC4944], задавая использование описанной здесь оптимизации.

Применимость этой спецификации ограничена сетями LoWPAN, где все узлы подсети поддерживают описанную здесь оптимизацию однородно. Хотя некоторые аспекты оптимизации применимы не только в 6LoWPAN, но и в базовых сетях IPv6 со слабым питанием и потерями, даже в комбинации с [RFC4861], это выходит за рамки документа.

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

Описанная здесь оптимизация применима для разных топологий. Она наиболее полезна в конфигурациях route-over и mesh-under для ячеистой (Mesh) топологии. Однако конфигурации с топологией «звезда» (Star) также выиграют от применения оптимизации за счёт снижения объёма сигнализации, отказоустойчивой обработки непереходного трафика и сжатия заголовков.

1.3. Цели и допущения

Цели

  • Оптимизация ND с использованием механизма, который является минимальным, но достаточным для работы в конфигурациях mesh-under и route-over.

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

  • Оптимизация интерфейсов между хостами и принятыми по умолчанию маршрутизаторами.

  • Поддержка спящих хостов.

  • Распространение контекста на хосты по мере необходимости с использованием сжатия заголовков 6LoWPAN [RFC6282].

  • Распространение контекста и префиксов от граничного маршрутизатора на все маршрутизаторы LoWPAN.

  • Обеспечение механизма DAD для работы через несколько узлов пересылки, подходящего для LoWPAN с маршрутизацией.

Допущения

  • 64-битовые адреса EUI-64 (Extended Unique Identifier) [EUI64] уникальны в глобальном масштабе, а сети LoWPAN однородны.

  • Все узлы сети имеют EUI-64 Interface ID для выполнения автоматической настройки и обнаружения дубликатов адресов.

  • На канальном уровне (L2) предполагается технология со слабым питанием и потерями, такая как IEEE 802.15.4 [RFC4944]. Однако механизм регистрации адресов может быть полезен и для других технологий L2.

  • 6LoWPAN настраивается на использование одного или нескольких глобальных префиксов IPv6, чтобы хосты могли перемещаться между маршрутизаторами LoWPAN без смены адресов IPv6.

  • При использовании механизма multihop DAD (параграф 8.2), каждый маршрутизатор 6LoWPAN (6LoWPAN Router или 6LR) регистрируется на всех граничных маршрутизаторах 6LoWPAN (6LoWPAN Border Router или 6LBR), доступных в LoWPAN.

  • При использовании 16-битовых коротких адресов IEEE 802.15.4 применяется тот или иной метод обеспечения уникальности адресов на канальном уровне. Это можно сделать с помощью DHCPv6, используя DAD на основе опции регистрации адресов (Address Registration Option или ARO, параграф 8.2) или иной метод, не описанный в этом документе.

  • Для сохранения уникальности адресов (см. параграф 5.4 в [RFC4862]), не выведенных из EUI-64, их нужно назначать или проверять на предмет дубликатов одним способом в масштабе всей LoWPAN. Это можно сделать с помощью DHCPv6 для назначения и/или механизма DAD, описанного в параграфе 8.2 (или иного протокола, предназначенного для обнаружения дубликатов).

  • Для корректной работы сжатия заголовков 6LoWPAN [RFC6282] нужен один контекст сжатия на всех хостах, 6LR и 6LBR, которые могут передавать, принимать или пересылать данный пакет. Если используется описанный в параграфе 8.1 метод распространения контекста сжатия, это предполагает, что все 6LBR должны координировать данные контекста, распространяемые в одной сети LoWPAN.

  • Эта спецификация описывает работу ND в одной сети LoWPAN. Участие узла в нескольких LoWPAN одновременно возможно, но выходит за рамки документа.

  • Поскольку LoWPAN использует префикс(ы) во всей сети, перемещение узлов в рамках LoWPAN не создаёт проблем. Перемещение узлов между LoWPAN выходит за рамки этого документа.

1.4. Заменяемые функции

Этот документ определяет оптимизацию сообщений ND для интерфейса хост-маршрутизатор и добавляет 2 механизма для топологии с маршрутизацией (route-over). Если не указано иное (в документе, определяющем протокол маршрутизации, применяемый в 6LoWPAN), этот документ применяется в сетях с любым протоколом маршрутизации. Однако протоколы маршрутизации могут предоставлять свои механизмы, поэтому данный документ отмечает некоторые функции как «заменяемые», что означает возможность использования функций протокола маршрутизации, обеспечивающих такой же эффект.

Ниже перечислены функции, которые можно заменить:

  • распространение префиксов и контекста сжатия заголовков 6LoWPAN через несколько узлов пересылки;

  • обнаружение дубликатов адресов (DAD) через несколько узлов пересылки.

Распространение через узлы пересылки (multihop) префиксов (ABRO) и контекста сжатия 6LoWPAN (6CO) выполняются «рука об руку». Если предусмотрена замена одной функции, должна меняться и другая. Рекомендации по реализации и развёртыванию функций приведены в разделе 14.

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

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

Этот документ предполагает знакомство читателя с терминами и концепциями 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], Transmission of IPv6 Packets over IEEE 802.15.4 Networks [RFC4944], IP Addressing Model in Ad Hoc Networks [RFC5889]. В документе применяется терминология [RFC4861], если ниже не приведено другое определение термина.

6LoWPAN link – канал 6LoWPAN

Беспроводный канал с одним (т. е. без пересылки IP) интервалом (hop) к соседу. Эти каналы считаются имеющими неопределённые свойства связности [RFC5889].

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

Хост или маршрутизатор, участвующий в LoWPAN. Термин используется в тех случаях, когда не нужно различать хост и маршрутизатор.

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

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

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

Граничный маршрутизатор расположенный между сетями 6LoWPAN или на стыке 6LoWPAN с другой сетью IP. На границе 6LoWPAN может размещаться 1 или множество 6LBR. Маршрутизаторы 6LBR отвечают за распространение префикса IPv6 для обслуживаемой сети 6LoWPAN. Изолированная сеть LoWPAN также включает 6LBR, обеспечивающий префикс(ы) для неё.

Router – маршрутизатор

6LR или 6LBR. Отметим, что узел в этом документе может выполнять функции маршрутизатора на одних интерфейсах и хоста – на других, как это разрешено в [RFC2460].

Mesh-under

Топология, в которой узлы подключены к 6LBR через mesh-сеть с пересылкой на канальном уровне. Таким образом, в конфигурации mesh-under все хосты IPv6 в LoWPAN находятся в одном интервале IP (hop) от 6LBR. Эта топология имитирует типичную топологию подсети IP с одним маршрутизатором и множеством узлов.

Route-over

Топология, в которой хосты соединены с 6LBR через промежуточные маршрутизаторы L3 (IP) и обычно удалены от 6LBR несколькими узлами пересылки IP. Топология route-over обычно включает 6LBR, набор 6LR и хосты.

Non-transitive link – непереходный канал

Канал с асимметричной достижимостью (reachability) как определено в параграфе 2.2 [RFC4861].

IP-over-foo document

Спецификация, задающая работу IP на основе определённого канального уровня, например [RFC4944] Transmission of IPv6 Packets over IEEE 802.15.4 Networks.

Header compression context – контекст сжатия заголовков

Адресная информация, совместно используемая в LoWPAN для сжатия заголовков 6LoWPAN [RFC6282], позволяющего исключить повторную передачу информации. В контексте адрес (возможно неполный) связан с идентификатором (Context Identifier или CID), который применяется в сжатии как сокращение для полного или части адреса получателя или отправителя.

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

Процесс, в котором узел LoWPAN передаёт сообщения запроса соседства (Neighbor Solicitation или NS) с опцией регистрации адреса (Address Registration Option или ARO) маршрутизатору, создающему запись в кэше соседей (Neighbor Cache Entry или NCE) для узла LoWPAN с определенным временем её сохранения. Таким образом, для маршрутизаторов 6LoWPAN кэш соседей служит фактически не кэшем, а реестром адресов хостов, подключённых к маршрутизатору.

3. Обзор протокола

Описанная оптимизация ND применима к конфигурациям mesh-under и route-over. В плоской (mesh-under) конфигурации имеются лишь граничные маршрутизаторы 6LoWPAN и хосты, здесь нет 6LR.

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

В дополнение к этому имеются механизмы, которые можно применять между 6LR и 6LBR для выполнения DAD через узлы пересылки, а также распространения префиксов и контекста сжатия от 6LBR на все 6LR, которые используют обычные механизмы ND для доставки этой информации хостам.

Протокол устроен так, что конфигурация 6LoWPAN не влияет на взаимодействие хоста с маршрутизатором и это взаимодействие происходит одинаково в плоской и маршрутизируемой топологии.

3.1. Расширения RFC 4861

Ниже указаны оптимизация и расширения для протокола IPv6 ND[RFC4861].

  • Обновление данных RA по инициативе хоста, избавляющее от периодической отправки незапрошенных RA.

  • Отказ от применения DAD при использовании адресов IPv6 на основе EUI-64 по причине их уникальности.

  • Процедура DAD необязательна при назначении адресов через DHCPv6.

  • Новый механизм регистрации адресов с опцией ARO, избавляющий от применения маршрутизаторами групповых сообщений NS для поиска спящих хостов и поддерживающий спящие хосты. Это также позволяет использовать один префикс(ы) IPv6 в сети 6LoWPAN с маршрутизацией и обеспечивает интерфейс между хостом и маршрутизатором для обнаружения дубликатов адресов (DAD).

  • Опции RA и 6CO для данных контекста, применяемых при сжатии заголовков 6LoWPAN.

  • Новый механизм DAD в сети 6LoWPAN с маршрутизацией, использующий сообщения DAR и DAC.

  • Новые механизмы распространения префиксов и данных контекста в сети с маршрутизацией, использующие новую опцию ABRO для управления рассылкой изменений конфигурации.

  • Добавлены константы принятого по умолчанию протокола и изменены некоторые имеющиеся константы ND.

3.2. Назначение адресов

Хосты в 6LoWPAN настраивают свои адреса IPv6 в соответствии с [RFC4861] и [RFC4862] на основе сведений из анонсов маршрутизаторов (RA). Однако использование флага M (управляемая настройка адреса) в этой спецификации более ограничено, чем в [RFC4861]. При установленном флаге M предполагается, что хост применяет DHCPv6 для назначения любых адресов, отличных от EUI-64. При сброшенном флаге M узлы LoWPAN поддерживают DAD и хост может безопасно применять механизм регистрации для проверки уникальности адресов, не являющихся EUI-64.

Маршрутизаторы 6LR могут применять эти же механизмы для настройки своих адресов IPv6.

Маршрутизаторы 6LBR отвечают за поддержку префиксов, выделенных 6LoWPAN, при использовании настройки вручную, DHCPv6 Prefix Delegation [RFC3633] или иных механизмов. В изолированной LoWPAN следует применять префикс уникальных локальных адресов (Unique Local Address или ULA) [RFC4193], создаваемый 6LBR.

3.3. Взаимодействие хоста с маршрутизатором

Хост передаёт сообщения запроса маршрутизатора (RS) при старте или обнаружении недоступности (Neighbor Unreachability Detection или NUD) одного из принятых по умолчанию маршрутизаторов.

Хост получает сообщения RA, которые обычно содержат опцию полномочного граничного маршрутизатора (Authoritative Border Router Option или ABRO) и могут включать одну или несколько опций контекста (6LoWPAN Context Option или 6CO) в дополнение к имеющимся опциям сведений о префиксе (Prefix Information Option или PIO), описанным в [RFC4861].

Когда на хосте настраивается адрес IPv6, не относящийся к локальному каналу (link-local), этот адрес регистрируется хостом на одном или нескольких маршрутизаторах, принятых по умолчанию, с помощью опции ARO в сообщении NS. Хост выбирает срок действия регистрации и повторяет ARO периодически (до завершения срока действия). Время выбирается так, чтобы регистрация сохранялась даже при засыпании хоста. Мобильным узлы, которые часто могут менять точку подключения, следует задавать короткое время регистрации. Подробности регистрации описаны в параграфе 5.5, а семантика протокола – в разделе 9.

Возврат хосту ARO с отличным от 0 полем Status означает отказ при регистрации. Одной из причин отказа может быть обнаружение маршрутизатором занятости адреса IPv6 другим хостом, т. е. хостом с другим EUI-64. Это можно использовать для поддержки адресов, не являющихся EUI-64, таких как временные адреса IPv6 [RFC4941] или адреса на основе Interface ID, являющиеся краткими 16-битовыми адресами IEEE 802.15.4. Причиной отказа может быть также переполнение кэша соседей в маршрутизаторе.

Перерегистрацию адреса можно объединять с NUD для маршрутизатора, поскольку в обоих случаях применяются индивидуальные сообщения NS. Это повышает эффективность, когда хост просыпается для отправки пакета и ему нужно выполнить NUD для проверки доступности маршрутизатора, а также обновить свою регистрацию.

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

В рамках оптимизации при распознавании адресов не применяются групповые сообщения NS как в [RFC4861] и вместо этого маршрутизатор поддерживает записи NCE для всех зарегистрированных адресов IPv6. Если адреса нет в кэше соседей маршрутизатора, это говорит об отсутствии адреса или его назначении хосту, подключённому к другому маршрутизатору 6LoWPAN или внешней сети. В конфигурации м маршрутизаторами используется протокол маршрутизации для пересылки пакетов адресатам.

3.4. Взаимодействие между маршрутизаторами

Взаимодействие между маршрутизаторам происходит лишь в конфигурации route-over, где имеются 6LR (параграф 1.4). Маршрутизаторы 6LR должны действовать как хосты при старте системы и настройке префиксов, передавая сообщения RS и автоматически настраивая свои адреса IPv6, в отличие от маршрутизаторов в [RFC4861].

При распространении префиксов и контекста через узлы пересылки маршрутизаторы 6LR сохраняют полученные (напрямую или опосредованно) от 6LBR опции ABRO, 6CO и сведения о префиксах и распространяют эти данные в анонсах RA, передаваемых другим 6LR или хостам в ответ на RS. В ABRO имеется поле Version Number (параграф 4.3), служащее для ограничения рассылки обновлённых сведений между 6LR.

6LR может выполнять процедуру DAD с одним или несколькими 6LBR, используя новые сообщения с запросом (Duplicate Address Request или DAR) и подтверждения (Duplicate Address Confirmation или DAC) дубликатов, которые содержат сведения из опции ARO. Сообщения DAR и DAC пересылаются между 6LR и маршрутизаторами 6LBR, поэтому правило [RFC4861] для проверки условия Hop Limit=255 не применимо к этим сообщениям. Передаваемым через узлы пересылки сообщениям DAD недопустимо менять записи NCE в маршрутизаторах, поскольку они не защищены проверкой Hop Limit=255.

3.5. Управление кэшем соседей

Применения явной регистрации со сроком действия и желание отказаться от групповой рассылки хостам сообщений NS предполагает, что записи NCE несколько отличаются от [RFC4861]. Это ведёт к трём типам NCE, определяющим момент удаления записи.

Garbage-collectible – пригодные для сборки мусора

Записи, разрешающие удаление при сборке мусора по правилам [RFC4861] в случае нехватки памяти.

Registered – зарегистрировано

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

Tentative – проба

Временные записи с коротким сроком действия, которые обычно преобразуются в Registered.

Отметим, что типы NCE ортогональны состояниям, заданным в [RFC4861].

Взаимодействие хоста с маршрутизатором путём передачи RS ведёт к созданию Tentative NCE. После успешной регистрации узла маршрутизатором эти записи получают статус Registered. При отправке маршрутизатором сообщений RA хостам и получении анонсов RA или групповых сообщений NS от других маршрутизаторов записи получают статус Garbage-collectible. Для адреса IP может в каждый момент существовать NCE лишь одного типа.

Записи NCE в маршрутизаторах могут добавляться или удаляться протоколом маршрутизации, применяемым в 6LoWPAN. Это полезно в случаях, когда протокол маршрутизации передаёт адреса канального уровня соседних маршрутизаторов. В зависимости от деталей протокола маршрутизации такие NCE могут иметь статус Registered или Garbage-collectible.

4. Новые опции и сообщения ND

В этом разделе определены новые опции сообщений ND, используемые спецификацией. Опция регистрации адреса ARO (Address Registration Option) применяется хостами, а опции ABRO и 6CO – в заменяемом взаимодействии между маршрутизаторами. Определены также 2 новых сообщения DAR и DAC между маршрутизаторами.

4.1. Опция ARO

Маршрутизаторам нужно знать набор IP-адресов хостов, доступных напрямую, и соответствующие адреса канального уровня. Эти данные должны поддерживаться с учётом радио-доступности. Для этого добавлена опция регистрации адреса (ARO), которая может включаться в передаваемые хостом индивидуальные сообщения NS. Таким образом, опция может включаться в индивидуальные NS, которые хост передаёт как часть NUD для определения доступности заданного по умолчанию маршрутизатора. ARO используется получившим опцию маршрутизатором для надёжной поддержки кэша соседей. Та же опция включается в соответствующие анонсы NA с полем Status, указывающим результат регистрации. Опция всегда инициируется хостом.

Информация из ARO включается также в сообщения DAR и DAC, передаваемые между 6LR и 6LBR, но она не используется этих сообщениях.

Опция ARO нужна для надёжности и экономии энергии. Срок действия обеспечивает хосту гибкость регистрации адреса, который следует сохранять (продолжать анонсирование маршрутизаторами 6LR в протокол маршрутизации и т. п.) даже при планируемом засыпании.

Отправитель NS включает также адрес EUI-64 [EUI64] интерфейса, на котором адрес регистрируется, служащий уникальным идентификатором при обнаружении дубликатов. Это позволяет отличить перерегистрацию адреса тем же узлом и регистрацию другим узлом (с иным EUI-64) адреса, который уже занят. EUI-64 также служит для доставки NA с кодом ошибки в поле Status по основанному на EUI-64 адресу хоста link-local IPv6 (см. параграф 6.5.2).

При использовании хостами опции ARO должна быть включена опция SLLAO (Source Link-Layer Address Option) [RFC4861] и регистрируемый адрес должен быть адресом IPv6 отправителя сообщения NS.

 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 = 2  |    Status     |   Reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Reserved            |     Registration Lifetime     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                            EUI-64                             +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

33

Length

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

Status

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

Reserved

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

Registration Lifetime

16-битовое целое число без знака, указывающее в минутах время, в течение которого маршрутизатору следует сохранять NCE для отправителя NS с этой опцией.

EUI-64

64-битовое поле, служащее для однозначной идентификации интерфейса с регистрируемым адресом путём включения идентификатора EUI-64 [EUI64] без изменений.

Таблица 1. Значения поля Status в NA.

Статус

Описание

0

Успех

1

Дубликат адреса

2

Переполнение кэша соседей

3-255

Выделяются по процедуре Standards Action [RFC5226]

4.2. Опция 6CO

Опция 6CO (6LoWPAN Context Option) передаёт сведения о префиксе для сжатия заголовков LoWPAN и похожа на PIO в [RFC4861]. Однако префиксы могут быть локальными и удалёнными, поскольку в LoWPAN сжатие может применяться к всем адресам IPv6. Опция позволяет распространять несколько контекстов, указанных CID, для использования в соответствии с [RFC6282]. Контекст может быть префиксом любого размера или адресом (/128), а в одном сообщении RA может передаваться до 16 опций 6CO.

 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    |Context Length | Res |C|  CID  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Reserved           |         Valid Lifetime        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                                                               .
.                       Context Prefix                          .
.                                                               .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 1. Формат опции 6LoWPAN Context.


Type

34

Length

8-битовое целое число без знака, задающее размер (включая поля Type и Length) опции в 8-байтовых словах. Может принимать значение 2 или 3 в зависимости от размера поля Context Prefix.

Context Length

8-битовое целое число без знака, задающее число действительных битов в начале поля Context Prefix (от 0 до 128). Если это поле имеет значение больше 64, поле Length должно иметь значение 3.

C

Флаг сжатия (Compression), указывающий пригодность контекста для сжатия. Непригодный контекст недопустимо применять для сжатия, но следует использовать при декомпрессии, если другой компрессор ещё не получил обновлённые сведения о контексте. Флаг служит для управления жизненным циклом контекста в соответствии с рекомендациями параграфа 7.2.

CID

4-битовый идентификатор контекста, служащий для сжатия по контексту в соответствии с [RFC6282]. Список CID для LoWPAN настраивается на 6LBR, служащем источником данных о контексте для 6LoWPAN.

Res, Reserved

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

Valid Lifetime

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

Context Prefix

Префикс IPv6 или адрес, соответствующий полю CID. Действительный размер поля указывается в поле Context Length, остальные биты заполняются нулями до 8-байтовой границы.

4.3. Опция ABRO

Опция полномочного граничного маршрутизатора (Authoritative Border Router Option или ABRO) нужна при использовании сообщений RA для распространения префиксов и данных контекста в сети с маршрутизацией. В этом случае маршрутизаторы 6LR получают сообщения PIO от других 6LR. Это означает, что 6LR не может просто выбрать последний анонс RA. Для надёжного добавления и удаления префиксов 6LoWPAN нужна информация от полномочного 6LBR. Это делается путём добавления номера версии, устанавливаемого 6LBR и распространяемого маршрутизаторами 6LR с данными префиксов и контекста в данной опции ABRO. При наличии нескольких 6LBR каждый будет использовать своё пространство номеров версий. Поэтому опция должна включать IP-адрес 6LBR, создавшего этот набор сведений.

Опция ABRO должна включаться во все сообщения RA, если эти сообщения служат для распространения информации между маршрутизаторами, как описано в параграфе 8.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 = 3   |          Version Low          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          Version High         |        Valid Lifetime         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                          6LBR Address                         +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Type

35

Length

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

Version Low, Version High

Эти поля совместно образуют поле Version Number – 32-битовое целое число без знака, в котором Version Low задаёт 16 младших битов, а Version High – 16 старших. Номер версии соответствует набору сведений в данном анонсе RA. Полномочный маршрутизатор 6LBR, являющийся источником префикса, увеличивает номер версии при каждом изменении префикса или данных контекста.

Valid Lifetime

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

Reserved

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

6LBR Address

Адрес IPv6 маршрутизатора 6LBR, являющегося источником указанного номера версии.

4.4. Сообщения о дубликатах адресов

Для обменов multihop DAD между 6LR и 6LBR, описанных в параграфе 8.2, определено два новых типа сообщений ICMPv6 – запрос о дубликатах (Duplicate Address Request или DAR) и подтверждение дубликата адреса (Duplicate Address Confirmation или DAC). Для этих целей отказались от использования сообщений NS и NA, поскольку не проверяется условие Hop Limit=255 по причине пересылки промежуточными 6LR. Информация в этих сообщениях совпадает с передаваемой в NS с опцией ARO и применяются те же поля.

Сообщения DAR и DAC имеют одинаковый формат, но разные типы ICMPv6, а поле Status включается лишь в DAC.

 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      |     Code      |          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Status     |   Reserved    |     Registration Lifetime     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                            EUI-64                             +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                       Registered Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Поля IP

IPv6 Source

Адрес передающего маршрутизатора, не являющийся к link-local.

IPv6 Destination

В DAR это адрес 6LBR, не являющийся к link-local, в DAC – просто адрес отправителя DAR.

Hop Limit

Значение MULTIHOP_HOPLIMIT при отправке. При получении поле должно игнорироваться.

Поля ICMP

Type

157 для DAR, 158 для DAC.

Code

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

Checksum

Контрольная сумма ICMP (см. [RFC4443]).

Status

8-битовое целое число без знака, указывающее статус регистрации в DAC. В сообщении DAR должно иметь значение 0 (см. таблицу 1).

Reserved

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

Registration Lifetime

16-битовое целое число без знака, указывающее в минутах время, в течение которого 6LBR следует сохранять запись в таблице DAD (параграф 8.2.2) для зарегистрированного адреса. Значение 0 в DAR указывает, что запись следует удалить из таблицы DAD.

EUI-64

64-битовое поле, служащее для однозначной идентификации интерфейса с регистрируемым адресом путём включения идентификатора EUI-64 [EUI64] без изменений.

Registered Address

128-битовое поле с адресом хоста из поля IPv6 Source в сообщении NS с опцией ARO, переданном хостом.

5. Поведение хоста

Хосты LoWPAN используют опцию ARO в передаваемых сообщениях NS как способ поддержки кэша соседей в маршрутизаторах, что позволяет отказаться от групповых NS для распознавания адресов. В отличие от [RFC4861], хосты инициируют обновление информации, полученной в RA, отправляя RS до завершения срока её действия. Когда NUD указывает недоступность одного или всех принятых по умолчанию маршрутизаторов, хост использует RS для поиска нового набора принятых по умолчанию маршрутизаторов.

5.1. Запрещённые действия

Хосту недопустимо передавать групповые сообщения NS.

5.2. Инициализация интерфейса

При инициализации интерфейса на хосте он следует спецификации [RFC4861]. Адрес link-local формируется на основе идентификатора EUI-64 [EUI64], назначенного интерфейсу в соответствии с [RFC4944] или подходящим документом, описывающим работу IP с данным канальным уровнем (IP-over-foo), а затем хост передаёт сообщения RS, как описано в параграфе 6.3.7 [RFC4861].

Не требуется присоединения группового адреса solicited-node, поскольку никто не передаёт групповых NS в сетях этого типа. Хост должен присоединить групповой адрес all-nodes.

5.3. Отправка RS

Запрос RS форматируется в соответствии с [RFC4861] и передаётся по групповому адресу IPv6 all-routers (см. параграф 6.3.7 в [RFC4861]). Должна включаться также опция SLLAO, чтобы можно было передать в ответ индивидуальный анонс RA. В сообщениях RS недопустимо использовать неуказанный (unspecified) адрес. Если канальный уровень поддерживает передачу пакетов по универсальному (anycast) адресу всем маршрутизаторам, это можно использовать для передачи пакетов маршрутизатору.

Поскольку хосты не зависят от групповых RA при обнаружении маршрутизаторов, они должны обеспечивать разумный повтор запросов RS при пустом списке принятых по умолчанию маршрутизаторов, недоступности одного из таких маршрутизаторов или близком к завершению сроке действия префикса или контекста из предыдущего анонса RA. Рекомендуется устанавливать изначально передачу до 3 (MAX_RTR_SOLICITATIONS) сообщений RS с интервалом не менее 10 секунд (RTR_SOLICITATION_INTERVAL), как указано в [RFC4861], а затем замедлять повторы. После начального повтора передачи хосту следует экспоненциально увеличивать таймер повтора [ETHERNET] для каждого следующего повторения, ограничивая значение 60 секундами (MAX_RTR_SOLICITATION_INTERVAL). В любом случае повтор RS прекращается при получении RA. Константы протокола приведены в разделе 9.

5.4. Обработка анонсов RA

Обработка RA происходит как [RFC4861] с добавлением обработки 6CO и регистрацией адреса, когда задан новый адрес. Кроме того, в RA должна включаться опция SLLAO. В отличие от [RFC4861], максимальное значение поля Router Lifetime в RA может иметь значение до 0xFFFF (приблизительно 18 часов).

При ошибочном получении хостом опции PIO с флагом L (on-link) эта опция PIO должна игнорироваться.

5.4.1. Настройка адреса

Настройка адреса соответствует [RFC4862]. Для адресов, не выведенных из EUI-64, флаг M в RA определяет способ настройки адреса. При установленном флаге M в RA должен использоваться протокол DHCPv6, при сброшенном флаге адрес можно настроить иным способом (определение дубликатов выполняется как часть регистрации). После настройки адреса он регистрируется отправкой индивидуального NS с ARO одному или нескольким маршрутизаторам.

5.4.2. Сохранение контекста

Хост поддерживает концептуальную структуру данных для контекста, получаемого от маршрутизаторов. Эту структуру называют таблицей контекста и она включает CID, префикс (из поля Context Prefix в 6CO), бит Compression и срок действия Valid Lifetime. Записи таблицы контекста со сброшенным битом Compression применяются для декомпрессии полученных пакетов, но их недопустимо использовать для сжатия передаваемых пакетов.

При получении опции 6CO в RA она применяется для добавления или обновления данных в таблице контекста. Если поле CID в 6CO совпадает со значением в записи таблицы, эта запись обновляется сведениями из 6CO. Если поле Valid Lifetime в 6CO имеет значение 0, запись сразу же удаляется. Если в таблице нет соответствующей записи и поле Valid Lifetime отлично от нуля, в таблицу добавляется новая запись и опция 6CO задаёт её содержимое.

Когда 6LBR меняет данные контекста, хост может не сразу заметить это и в худшем случае у хоста может быть устаревшая информация. По этой причине 6LBR используют рекомендации параграфа 7.2 для поддержки жизненного цикла контекста. Узлам следует соблюдать осторожность при сжатии заголовков в сообщениях RA с опциями 6CO.

5.4.3. Поддержка сведений о префиксах и контексте

Тайм-аут для префикса задан в [RFC4861]. Когда срок Valid Lifetime в таблице контекста истекает, запись помещается в режим «только приём» (receive-only), эквивалентный получению для этого контекста опции 6CO с C=0. Запись сохраняется в режиме receive-only в течение удвоенного времени Router Lifetime, после чего удаляется.

Хосту следует проверять различные сроки действия для определения момента передачи следующего запроса RS с целью обновления информации. Важными сроками для проверки являются принятое по умолчанию значение Router Lifetime, значения Valid Lifetime в опциях PIO, и Valid Lifetime в опции 6CO. Хосту следует передать одно или несколько индивидуальных сообщений RS маршрутизатору до завершения первого из оставшихся сроков (среди всех префиксов и контекстов), а затем переключиться на отправку групповых RS, если отклика на индивидуальные не было. Повторная передача сообщений RS описана в параграфе 5.3.

5.5. Регистрация и NUD

Хосты передают индивидуальные сообщения NS для регистрации своих адресов IPv6, а также выполняют процедуру NUD для проверки доступности заданных по умолчанию маршрутизаторов. Хост выполняет регистрацию путём включения опции ARO в запросы NS. Даже при отсутствии данных хост, ожидающий пакетов от других, должен поддерживать свои записи NCE в маршрутизаторах. Это делается путём отправки NS с опцией ARO маршрутизатору до истечения срока Registration Lifetime. Сообщения NS повторяются до MAX_UNICAST_SOLICIT раз с минимальным интервалом RETRANS_TIMER, пока в ответ не будет получен анонс NA с опцией ARO.

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

Отметим, что отправка зондов NUD может сдерживаться приёмом подтверждений доступности от транспортных протоколов или приложений, как указано в [RFC4861].

Когда хост знает, что больше не будет использовать маршрутизатор, на котором он зарегистрирован, хосту следует отменить регистрацию передачей сообщения NS с опцией ARO, указывающей срок действия 0. Для обработки потери связности с принятым по умолчанию маршрутизатором хосту следует применять достаточно малое значение Registration Lifetime.

5.5.1. Передача NS

Хост запускает отправку NS с опцией ARO при настройке нового адреса, обнаружении нового маршрутизатора, используемого по умолчанию, или перед завершением Registration Lifetime. Такие сообщения NS должны включать опцию SLLAO, поскольку маршрутизатору нужно записать адрес хоста на канальном уровне. Незаданный адреса отправителя недопустимо использовать в сообщениях NS.

5.5.2. Обработка NA

Хост обрабатывает анонсы NA в соответствии с [RFC4861], добавляя описанную здесь логику обработки ARO. В дополнение к обычной проверке анонса NA и его опций проверяется опция ARO (при наличии), как описано ниже. Если поле Length отличается от 2 или поле EUI-64 не соответствует адресу EUI-64 на этом интерфейсе, опция просто игнорируется.

Поле Status = 0 означает успешную регистрацию. Хост сохраняет Registration Lifetime из ARO для использования в качестве триггера отправки нового NS до завершения срока действия. Отличное от 0 поле Status говорит об отказе регистрации.

5.5.3. Восстановление после отказа

Процедура сохранения информации о доступности соседа совпадает с описанной в параграфе 7.3 [RFC4861], за исключением того, что распознавания адреса не производится.

Отказ процедуры регистрации может быть выражен двояко – отсутствием отклика на запросы NS (отказ NUD) или получением опции ARO со статусом отказа (Status > 0). В случае отказа NUD запись для маршрутизатора удаляется и регистрация адреса уже не имеет значения. Получение ARO с отличным от 0 полем Status говорит об отказе при регистрации адреса. Status = 1 указывает обнаружение дубликата адреса, после чего запускается процедура, описанная в параграфе 5.4.5 [RFC4862]. Хосту недопустимо применять адрес, который он пытался зарегистрировать. Если у хоста имеются действительные регистрации этого адреса на других маршрутизаторах, они должны быть отозваны регистрацией адреса с нулевым сроком действия в опции ARO. Status = 2 указывает переполнение Neighbor Cache в маршрутизаторе. В этом случае хосту следует удалить этот маршрутизатор из числа используемых по умолчанию и попытаться зарегистрироваться на другом маршрутизаторе. Если список принятых по умолчанию маршрутизаторов на хосте становится пустым, нужно вернуться к передаче запросов RS, как указано в параграфе 5.3.

В будущих документах могут быть определены дополнительные коды отказов.

5.6. Определение следующего интервала

Определение IP-адреса следующего узла пересылки (next hop) к адресату описано ниже. Получателям из префикса локального канала (link-local, fe80::) пакеты всегда передаются в канал. Предполагается, что адреса link-local формируются в соответствии с параграфом 5.2 по адресам EUI-64 и распознавания адресов не происходит. Пакеты передаются адресатам на локальном канале путём обращения процедуры из Приложения A к [RFC4291].

Групповые адреса считаются подключёнными (on-link) и распознаются в соответствии с [RFC4944] или подходящим документом IP-over-foo. Отметим, что [RFC4944] определяет лишь представление группового адреса получателя в заголовке LoWPAN. Поддержка групповых адресов за пределами локального канала требует механизма групповой маршрутизации.

Все прочие префиксы считаются находящимися вне канала (off-link) [RFC5889]. Универсальные (anycast) адреса всегда считаются находящимися вне канала и поэтому пакеты для них передаются одному из принятых по умолчанию маршрутизаторов.

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

5.7. Распознавание адреса

Механизм регистрации адреса и SLLAO в сообщениях RA обеспечивают возможность распознавания по адресу IPv6 связанного адреса канального уровня на хостах и маршрутизаторах. Поскольку все префиксы, за исключением link-local и групповых адресов считаются находящимися вне канала, распознавание адресов на основе групповой адресации не требуется между соседями.

Адреса соседей на канальном уровне хранятся в записях NCE [RFC4861]. Для сжатия LoWPAN большинство глобальных адресов формируется с использованием адресов канального уровня. За счёт этого хост может сэкономить локальную память и сохранять информацию канального уровня лишь в том случае, когда она отличается от соответствующего Interface ID для адреса IPv6 (т. е. различия не ограничиваются инверсией бита on-link/global).

5.8. Спящие хосты

Для хостов LoWPAN с батарейным питанием зачастую нужно снижать потребление энергии. Описанная в этом документе оптимизация позволяет хостам «засыпать». Маршрутизаторам может потребоваться кэшировать трафик уснувших хостов, но этот вопрос выходит за рамки описанной в документе функциональности.

5.8.1. Выбор подходящего срока регистрации

Поскольку все сообщения ND инициируются хостами, это позволяет хосту заснуть или иным способом утратить доступность между обменами NS/NA. Опция ARO в NS указывает маршрутизатору, что NCE для этого адреса следует сохранять в течение Registration Lifetime. Хосту следует выбирать время сна в соответствии со своими параметрами энергосбережения и устанавливать Registration Lifetime больше времени сна, чтобы вовремя обновить регистрацию (с учётом расхождения часов и возможного повтора передачи при перерегистрации). Во внешней конфигурации хоста также следует учитывать стабильность сети (частоту смены топологии) при выборе времени сна (и Registration Lifetime). Для динамичных сетей требуется короткая продолжительность сна, чтобы маршрутизаторы не сохраняли недействительные NCE в течение долгого времени.

5.8.2. Поведение при пробуждении

При выходе из режима сна хосту следует обновить регистрации адресов, которые завершатся до следующего пробуждения. Для этого передаются сообщения NS с опцией ARO, как описано в 5.5.1. Хосту может также потребоваться обновление сведений о префиксах и контексте путём передачи нового индивидуального RS (максимальное значение Router Lifetime составляет около 18 часов, тогда как максимум Registration Lifetime – около 45,5 дней). Если после пробуждения хост с помощью NUD обнаруживает недоступность некоторых маршрутизаторов, заданных по умолчанию, он будет передавать групповые запросы RS для обнаружения новых маршрутизаторов и повторно запускать процесс регистрации адресов.

6. Поведение маршрутизаторов 6LR и 6LBR

Маршрутизаторы 6LR и 6LBR поддерживают кэш соседей [RFC4861] на основе опций ARO, полученных в сообщениях NA от хостов, пакетов ND от других узлов и, возможно, протоколов маршрутизации, используемых в 6LoWPAN, как отмечено в параграфе 3.5.

Маршрутизаторам не следует выполнять сборку мусора для Registered NCE (см. параграф 3.4), поскольку эти записи нужно сохранять до завершения Registration Lifetime. Если NUD на маршрутизаторе определяет недоступность (UNREACHABLE) хоста (на основе логики [RFC4861]), NCE не следует удалять, сохраняя запись до завершения Registration Lifetime. Обновлённой опции ARO пометить запись кэша как STALE (устаревшая). Таким образом в маршрутизаторах 6LoWPAN поведение Neighbor Cache отличается от поведения кэша. Это скорее реестр адресов всех хостов, подключённых к маршрутизатору.

Маршрутизаторы могут реализовать расширение Prf (Default Router Preference) [RFC4191] и использовать его для указания хосту своей роли 6LBR или 6LR. Если это реализовано, маршрутизаторы 6LR без пути к граничному маршрутизатору должны установить Prf = 11 для низкого предпочтения, другие 6LR должны установить Prf = 00 для нормального предпочтения, а 6LBR должны установить высокое предпочтение Prf = 01.

6.1. Запрещённые действия

Даже если в топологии с маршрутизацией маршрутизатор может достичь хоста и другой цели, он обычно не может знать о прямой достижимости другой цели из-за распространения радиосвязи. Поэтому нельзя считать, что Redirect будет реально перенаправлять от одного хоста к другому и сообщения Redirect передавать не следует. Единственным возможным исключением (для не следует) является развёртывание или реализация, где есть способ узнать, как хост может достичь намеченной цели. Поэтому реализациям рекомендуется но умолчанию не передавать сообщений Redirect, но поддерживать возможность изменить это в настройках. Для «плоской» топологии (mesh-under) к сообщениям Redirect применимы соображения из [RFC4861].

Маршрутизатору недопустимо устанавливать флаг L (on-link) в опциях PIO, поскольку это может заставить хосты передавать групповые сообщения NS.

6.2. Инициализация интерфейса

Поведение интерфейса маршрутизатора 6LBR при инициализации соответствует [RFC4861]. Однако при динамической настройке (см. параграф 8.1) 6LR не выглядит маршрутизатором и ждёт получения анонса для настройки адреса на своём интерфейсе до настройки интерфейсов для анонсирования и превращения в маршрутизатор.

6.3. Обработка RS

Маршрутизатор обрабатывает запросы RS в соответствии с [RFC4861]. Отличие связано со включением в них опции ABRO и применением лишь индивидуальных RA. Если 6LR получает опцию ABRO от 6LBR, он будет включать её без изменения в передаваемые сообщения RA. Если 6LR получает RA (с теми же или иными сведениями о префиксах и контексте) от другого 6LBR, ему необходимо сохранить эти сведения отдельно, чтобы передаваемые им RA поддерживали связь между ABRO и сведениями о префиксах и контексте. Маршрутизатор может определить 6LBR, являющийся источником данных о префиксах и контексте, из поля 6LBR Address в опции ABRO. Когда у маршрутизатора есть сведения, привязанные к разным ABRO, один запрос RS будет вызывать анонсы RA для каждой опции ABRO.

По завершении срока ABRO Valid Lifetime, связанного с 6LBR, все относящаяся к 6LBR информация должна удаляться. Реализациям рекомендуется передавать RA достаточно часто по сравнению со сроком ABRO Valid Lifetime, чтобы отсутствие RA не вызывало удаления всех сведений, относящихся к 6LBR.

RS может прийти от хоста, ещё не зарегистрировавшего свой адрес в маршрутизаторе. Поэтому маршрутизатору недопустимо менять имеющуюся NCE на основе опции SLLAO из RS. Однако маршрутизатор может создать Tentative NCE на основе SLLAO. Для таких Tentative NCE следует устанавливать тайм-аут в TENTATIVE_NCE_LIFETIME секунд, если регистрация не поменяет статус записи на Registered.

6LR и 6LBR должны включать SLLAO в передаваемые анонсы RA, чтобы хосты знали адрес маршрутизатора на канальном уровне. В отличие от [RFC4861], максимальное значение поля RA Router Lifetime может достигать 0xFFFF (приблизительно 18 часов).

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

6.4. Периодические анонсы RA

Маршрутизатору не нужно периодически передавать RA, поскольку хосты запрашивают обновления, передавая RS до завершения срока действия. Однако при использовании маршрутизаторами анонсов RA для распространения сведений о префиксах или контексте в сети с маршрутизацией может потребоваться периодическая отправка RA на основе настраиваемых значений MinRtrAdvInterval и MaxRtrAdvInterval как в [RFC4861].

6.5. Обработка NS

Маршрутизатор обрабатывает запросы NS в соответствии с [RFC4861], with добавляя описанную здесь логику обработки ARO. В дополнение к обычной проверке NS и его опций проверяется опция ARO (при наличии), как описано ниже. Если поле Length отличается от 2 или поле Status отличается от 0, опция просто игнорируется. Если сообщение NS отправлено с неуказанного адреса или не включает опцию SLLAO, включённые в него опции ARO игнорируются и NS обрабатывается как обычно (без учёта ARO).

6.5.1. Проверка дубликатов

Если NS содержит действительную опцию ARO, маршрутизатор проверяет кэш соседей на приёмном интерфейсе для обнаружения дубликата. Дубликата нет, если (1) отсутствует NCE для адреса отправителя IPv6 в NS или (2) имеется NCE с тем же значением EUI-64. Остальные случаи говорят о возникновении дубликата. Отметим, что при использовании multihop DAD (параграф 8.2) проверка слегка отличается для учёта Tentative NCE. В случае дубликата маршрутизатор отвечает индивидуальным сообщением NA с полем ARO Status = 1 (индикация дубликата), как указано в параграфе 6.5.2. Кэш соседей в этом случае не изменяется.

6.5.2. Возврат ошибок при регистрации адреса

Сообщения об ошибках при регистрации адреса не возвращаются по адресу отправителя NS по причине возможного конфликта адресов L2. Взамен передаётся сообщение NA по адресу link-local IPv6 с Interface ID, выведенным из поля EUI-64 в опции ARO, как указано в [RFC4944]. Это означает, в частности, необходимость инвертировать бит universal/local. В NA включается копия опции ARO из NS, а поле Status указывает код ошибки.

Сообщение передаётся по адресу на локальном канале с Interface ID, выведенным из EUI-64. Таким образом, если в ARO был указан короткий адрес, адресом получателя L2 для NA с ошибкой ARO будет уникальный 64-битовый адрес.

6.5.3. Обновление кэша соседей

Если опция ARO не ведёт к обнаружению дубликата адреса, как указано выше, то при ненулевом значении поля Registration Lifetime маршрутизатор создаёт (при отсутствии) или обновляет NCE для адреса отправителя IPv6 в NS. Если требуется создать новую запись, а кэш соседей полон, маршрутизатор отвечает индивидуальным анонсом NA с ARO Status = 2 (переполнение Neighbor Cache), как описано в параграфе 6.5.2.

Значения Registration Lifetime и EUI-64 записываются в NCE, после чего передаётся индивидуальный отклик NA на сообщение NS. В этот анонс NA следует включать копию ARO с Status = 0. Опция TLLAO (Target Link-Layer Address Option) [RFC4861] не требуется в NA, поскольку хост уже знает адрес маршрутизатора на канальном уровне из RA.

Если в ARO указано Registration Lifetime = 0, имеющаяся NCE для адреса отправителя IPv6 в NS должна удаляться с передачей NA, как указано выше. По истечении Registration Lifetime в NCE маршрутизатор должен удалить запись. Добавление и удаление Registered NCE ведёт к уведомлению протокола маршрутизации.

Примечание. При замене multihop DAD (см. параграф 8.2) обновление кэша соседей несколько отличается из-за Tentative NCE.

6.5.4. Определение Next-Hop

При доставке пакета 6LN, зарегистрированному в маршрутизаторе, определение следующего узла пересылки (next-hop) несколько различается для хостов и маршрутизаторов (см. параграф 5.6). Для определения next-hop IP проверяется таблица маршрутизации. Запись Registered NCE определяет наличие next-hop IP на канале. За поддержку информации о зарегистрированных на канале соседях отвечает протокол маршрутизации. Записи Tentative NCE недопустимо использовать для определения присутствия зарегистрированных узлов на канале (on-link).

6.5.5. Распознавание адресов между маршрутизаторами

Нужен механизм, позволяющий маршрутизаторам определять адреса друг друга на канальном уровне. При использовании между маршрутизаторами протокола маршрутизации, обеспечивающего такие сведения маршрутизаторам не требуется обмен опциями ARO, а в иных случаях им следует применять ARO. При использовании маршрутизаторами ARO для регистрации друг у друга и multihop DAD (параграф 8.2) нужно следить, чтобы не было лавины сообщений с опцией ARO, передаваемых 6LBR, когда каждый маршрутизатор слышит ARO от соседних маршрутизаторов. Детали этого выходят за рамки документа.

Маршрутизаторы могут использовать групповые NS как в [RFC4861] для определения адресов канального уровня друг у друга. Таким образом, маршрутизаторы могут передавать групповые NS для других маршрутизаторов, например, в результате получения маршрутных обновлений. Маршрутизаторы должны отвечать на групповые NS, поэтому они должны присоединяться к группе solicited-node, как указано в [RFC4861].

7. Поведение граничного маршрутизатора

6LBR передаёт RA и обрабатывает NS, как указано в разделе 6. Маршрутизатору 6LBR всегда следует включать опцию ABRO в передаваемые RA, указывая себя как адрес 6LBR. Этот требует от 6LBR поддержки номера версии в стабильном хранилище и увеличения этого номера при некоторых изменениях информации в его анонсах RA. Эта информация находится в опциях PIO (префиксы и срок их действия) и 6CO (префиксы, CID, сроки действия).

Кроме того, в 6LBR как-то настраивается префикс(ы), выделенный LoWPAN и анонсируемый в RA как в [RFC4861]. В сети с маршрутизацией префиксы могут распространяться всем 6LR с использованием метода, описанного в параграфе 8.1. Однако могут применяться выходящие за рамки этого документа механизмы вместо описанного здесь распространения префиксов в топологии с маршрутизацией (параграф 1.4).

Если в 6LoWPAN применяется сжатие заголовков [RFC6282] с контекстом, маршрутизатор 6LBR должен поддерживать CID и анонсировать их в RA путём включения опций 6CO, чтобы подключённые напрямую хосты знали CID. Ниже сказано, что следует учитывать, когда 6LBR требуется добавлять, удалять или изменять данные контекста. В топологии с маршрутизацией данные контекста распространяются всем 6LR с помощью метода, описанного в разделе 8, если взамен не применяется другой механизм.

7.1. Определение префикса

Используемые в LoWPAN префиксы можно настраивать вручную или получать с помощью DHCPv6 Prefix Delegation [RFC3633]. Для LoWPAN временно или постоянно изолированной от сети 6LBR может выделять префикс ULA с помощью [RFC4193]. Префикс ULA следует записывать в стабильное хранилище, чтобы он не менялся в результате аварии 6LBR. Если в LoWPAN имеется множество 6LBR, для них следует настраивать один набор префиксов. Префиксы включаются в сообщения RA, как указано в [RFC4861].

7.2. Настройка и поддержка контекста

Если в LoWPAN применяется сжатие заголовков [RFC6282] с контекстом, на 6LBR требуется настроить контекст и связанные с ним CID. Если в LoWPAN имеется множество 6LBR, они должны иметь общий контекст и CID. Как отмечено в [RFC6282], поддержка согласованности данных контекста имеет решающее значение для корректной декомпрессии пакетов.

Данные контекста передаются в анонсах RA, создаваемых 6LBR, и должны распространяться на все маршрутизаторы и хосты LoWPAN. Анонсы RA включают опцию 6CO для каждого контекста. Для распространения данных контекста с использованием 6CO следует применять строгий жизненный цикл, гарантирующий синхронизацию данных контекста в рамках LoWPAN. Новые данные контекста следует вводить в LoWPAN с C=0 для гарантированной известности всем узлам, которые могут выполнять декомпрессию заголовков на основе этих данных. Только при наличии оснований считать, что информация успешно распространена, следует передавать опцию с C=1, позволяющую фактически применять данные контекста для декомпрессии.

И наоборот, для предотвращения отправки пакетов, использующих прежнюю версию контекста (это может приводить к неоднозначности при получении пакета, использующего недавно изменённый контекст), старые значения контекста следует на некоторое время вывести из употребления, пока конкретному контексту не будет назначено новое значение. Т. е. при подготовке к смене данных контекста его распространение следует продолжать не менее MIN_CONTEXT_CHANGE_DELAY с C=0. Лишь когда разумно считать, что сведения о недействительном контексте были успешно распространены, CID изымается из распространения или используется снова в другим полем Context Prefix. В последнем случае повторное распространение значение следует начинать с C=0, как указано выше.

8. Поведение при замене функции

Обычно в сети 6LoWPAN с множеством узлов пересылки сообщения RA служат для распространения сведений о префиксах и контексте всем маршрутизаторам 6LR в топологии route-over. Если на всех маршрутизаторах применяется замена механизма распространения такой информации, использование механизмов 6LoWPAN-ND регулируется спецификацией замены.

Для 6LR существует также возможность выполнять multihop DAD (для адресов IPv6, не выводимых из EUI-64) с 6LBR в топологии с маршрутизацией, используя сообщения DAR и DAC. Это заменяемая функция, поскольку могут быть иные способы назначения уникальных адресов, такие как DHCPv6 [RFC3315], или будущие механизмы DAD через несколько узлов пересылки. В этом случае поведение механизмов 6LoWPAN-ND также определяется спецификацией замены.

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

8.1. Распространение префиксов и контекста через узлы пересылки

Распространение через узлы пересылки основано на запросах RS и анонсах RA, передаваемых между маршрутизаторами, а также номерах версии ABRO для контроля распространения данных (префиксы и контекст) в RA.

Механизм распространения через маршрутизаторы может обрабатывать произвольные сведения от любого числа 6LBR. Однако семантика данных контекста требует, чтобы все 6LN использовали одну информацию, независимо от того работают ли они со сжатыми пакетами (передача, приём или пересылка). Поэтому менеджер 6LBR должен гарантировать синхронизацию сведений о контексте между 6LBR, что можно сделать разными способами. Одним из вариантов является гарантированная трактовка сведений о префиксах и контексте как исходящих от некого логического или виртуального источника, что по сути похоже на распространение данных из одного источника. Если набор 6LBR ведёт себя как один маршрутизатор (на основе механизмов, выходящих за рамки документа) так, что сведения о префиксах и контексте, а также номер версии ABRO одинаковы от всех 6LBR, эти 6LBR могут указывать в ABRO один адрес IP.

8.1.1. 6LBR, передающие RA

6LBR, поддерживающие распространение префиксов и контекста через узлы пересылки, должны включать ABRO в каждый анонс RA. Поле ABRO Version Number служит для согласованности данных о префиксах и контексте в рамках LoWPAN наряду с рекомендациями параграфа 7.2. При каждом изменении данных в наборе PIO или 6CO номер версии ABRO увеличивается на 1. Это требует от 6LBR записи PIO, 6CO и ABRO Version Number в стабильное хранилище, поскольку старый номер версии будет игнорироваться маршрутизаторами 6LR.

8.1.2. Маршрутизаторы, передающие RS

В 6LoWPAN распространение через узлы пересылки выполняется с использованием сообщений RA, если не применяется замены. Таким образом, при инициализации интерфейса маршрутизатор (6LR) должен передавать RS в соответствии с правилами для хостов [RFC4861]. Это заставляет маршрутизаторы отвечать анонсами RA, которые могут служить для начальной установки префиксов и данных контекста.

8.1.3. Маршрутизаторы, обрабатывающие RA

Если при распространении через маршрутизаторы сообщения RA не применяются, маршрутизаторы следуют [RFC4861], где сказано, что выполняется лишь некоторая проверка согласованности и в этом случае параграф 8.1 не применяется. В ином случае маршрутизаторы проверяют и записывают сведения о префиксах и контексте из RA, используя их должным образом. Анонсы RA без опции ABRO должны игнорироваться.

Маршрутизатор использует поле 6LBR Address в ABRO для проверки предшествующего получения информации от 6LBR. Если такой информации не найдено, маршрутизатор просто записывает адрес 6LBR, Version, Valid Lifetime и связанные с ними данные о префиксах и контексте. Если 6LBR уже известен, значение поля Version Number должно сравниваться с записанным номером версии для этого 6LBR. Если полученный номер версии меньше записанного, сведения из RA просто игнорируются, в противном случае обновляется сохранённая информация и номер версии.

8.1.4. Хранение информации

Маршрутизатор сохраняет видимое в ABRO состояние для каждого 6LBR, включая номер версии, Valid Lifetime и полный набор опций PIO и 6CO. Срок действия префиксов задаёт Valid Lifetime в PIO, срок Context Prefix – Valid Lifetime в 6CO.

Данные о префиксах и контексте хранятся в маршрутизаторе, при этом действительные и предпочтительные сроки действия уменьшаются с течением времени. Это гарантирует, что маршрутизатор позднее анонсирует эти сведения в передаваемых RA и завершение срока действия случайно не переместится в будущее. Например, если опция 6CO с Valid Lifetime в 10 минут получена в момент T и маршрутизатор включит его в анонс RA, переданный в момент T+5 минут, значение Valid Lifetime в переданной опции 6CO составит уже 5 минут.

8.1.5. Отправка RA

При распространении через узлы пересылки с использованием анонсов RA маршрутизаторы должны гарантировать, что опция ABRO всегда остаётся с данными о префиксах и контексте, полученными в этой ABRO. Если маршрутизатор получил префикс P1 с опцией ABRO от одного 6LBR, а P2 – от другого 6LBR, ему недопустимо включать эти два префикса в один анонс RA. Префикс P1 должен быть в RA, включающем ABRO от первого 6LBR и т. д. Отметим, что несколько 6LBR могут анонсировать одни сведения о префиксах и контексте, но эти данные все равно должны быть связаны с анонсирующим их маршрутизатором 6LBR.

Маршрутизаторы периодически передают RA как в [RFC4861], это помогает другим маршрутизаторам получать сведения о префиксах и контексте. Маршрутизаторы также отвечают на запросы RS индивидуальными анонсами RA. В обоих случаях применяется указанное выше требование хранить опцию ABRO вместе с «её» сведениями о префиксах и контексте.

При получении маршрутизатором новой информации от 6LBR, т. е. при появлении нового 6LBR (с новым адресом 6LBR в ABRO) или увеличении номера версии ABRO для имеющегося 6LBR маршрутизатору полезно отправить несколько триггерных обновлений. Рекомендуется поведение как при переходе интерфейса в состояние анонсирующего, описанном в [RFC4861], т. е. отправка до 3 анонсов RA. Это гарантирует быстрое распространение сведений всем 6LR.

8.2. DAD через узлы пересылки

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

Данная спецификация предлагает для 6LR и 6LBR простой заменяемый метод DAD, использующий сведения из опций ARO в сообщениях DAR и DAC. Этот метод не нужен, когда Interface ID в адресе основан на EUI-64, поскольку эти адреса предполагаются уникальными в глобальном масштабе. Метод предполагает, что маршрутизаторы 6LR регистрируются на всех 6LBR или в сети применяется некий внешний механизм синхронизации таблиц DAD в 6LBR.

Механизм multihop DAD применяется синхронно при первой регистрации адреса на конкретном 6LR, т. е. опция ARO не возвращается хосту, пока не будут завершены процедуры DAD со всеми 6LBR. Для имеющихся регистраций в 6LR механизм DAD через узлы пересылки повторяется периодически с 6LBR, чтобы гарантировать продление срока действия адреса в 6LBR, но это не требует синхронизации с откликами хостам. Одним из способов реализации этого является отслеживание срока действия 6LR, зарегистрированного в 6LBR, и повторная регистрация в 6LBR до завершения срока действия.

Для синхронного выполнения DAD через маршрутизаторы 6LR предпринимает дополнительные проверки, чтобы убедиться в наличии NCE, которую можно использовать для отклика хосту при получении отклика от 6LBR. Это включает проверку имеющейся NCE (Tentative или Registered) для Registered Address с другим EUI-64. Если имеется такая Registered NCE, маршрутизатору 6LR следует указать в отклике этот адрес как дубликат. Если же имеется Tentative NCE, маршрутизатору 6LR следует просто игнорировать ARO, полагаясь на хост, повторяющий ARO. Это нужно для случаев, когда несколько хостов одновременно пытаются зарегистрировать 1 адрес IPv6. Если NCE нет, 6LR должен создать Tentative NCE с EUI-64 и SLLAO. Эта запись будет применяться для отправки отклика хосту при положительном ответе 6LBR.

При получении маршрутизатором 6LR запроса NS с опцией ARO, содержащей отличное от 0 поле Registration Lifetime, и отсутствии Registered NCE, этот механизм не приведёт 6LR к вызову синхронной процедуры multihop DAD.

6LR передаёт одному или нескольким 6LBR индивидуальное сообщение DAR, с адресом хоста в поле Registered Address. Сообщения DAR пересылаются маршрутизаторами 6LR, пока не достигнут 6LBR, поэтому поле IPv6 Hop Limit не будет иметь значение 255 при получении. 6LBR отвечает сообщением DAC, которое будет иметь Hop Limit меньше 255 по прибытии в 6LR. Маршрутизатор 6LR, получивший DAC от 6LBR, будет искать совпадение (IP-адрес и EUI-64) в NCE (Tentative или Registered). При отсутствии записи сообщение DAC игнорируется. Если запись найдена и в DAC указано Status=0, маршрутизатор 6LR будет помечать Tentative NCE как Registered. Во всех случаях наличия записи 6LR будет отвечать хосту анонсом NA, копирую поля Status и EUI-64 из DAC в опцию ARO сообщения NA. Если статус указывает ошибку, IP-адрес получателя NA выводится из EUI-64 в DAC.

Записям Tentative NCE следует истекать в течение TENTATIVE_NCE_LIFETIME секунд после создания, чтобы другой хост мог попытаться зарегистрировать адрес IPv6.

8.2.1. Проверка сообщений DAR и DAC

Узел должен отбрасывать без уведомления любые принятые сообщения DAR и DAC при отказе любой из проверок:

  • при наличии заголовка IP AH аутентификация завершилась корректно;

  • контрольная сумма ICMP корректна;

  • ICMP Code = 0;

  • размер ICMP (выводится из размера IP) не менее 32 байтов;

  • Registered Address не является групповым адресом;

  • все включённые опции имеют отличный от 0 размер;

  • IP-адрес отправителя не является неуказанным или групповым.

Содержимое поля Reserved и нераспознанных опций должно игнорироваться. Будущие изменения протокола, совместимые с имеющимися версиями, могут использовать поле Reserved или добавлять опции, а также использовать иные значения Code. Отметим, что в результате пересылки сообщений DAR и DAC между 6LR и 6LBR проверка поля Hop Limit для этих сообщений ICMPv6 не выполняется.

8.2.2. Концептуальные структуры данных

6LBR с реализацией DAD через узлы пересылки требуется поддерживать состояние, отдельное от Neighbor Cache. Здесь такая концептуальная структура данных названа таблицей DAD. Таблица индексируется по адресу IPv6 (Registered Address в DAR) и содержит значения EUI-64 и Registration Lifetime для хоста, использующего этот адрес.

8.2.3. 6LR, передающий DAR

Когда 6LR, реализующий multihop DAD, получает NS от хоста и выполняет указанные выше проверки, по результатам он формирует и передаёт сообщение DAR хотя бы одному 6LBR. DAR включает:

  • глобальный адрес 6LR в поле отправителя IPv6;

  • адрес 6LBR в поле получателя IPv6;

  • MULTIHOP_HOPLIMIT в поле IPv6 Hop Limit4

  • поле Status должно иметь значение 0;

  • поля EUI-64 и Registration Lifetime копируются из полученной от хоста опции ARO;

  • в Registered Address помещается адрес хоста IPv6, вызвавшего отправку NS.

Когда 6LR получает от хоста NS с Registration Lifetime = 0, он удаляет NCE для хоста в соответствии с разделом 6, а также передаёт DAR маршрутизаторам 6LBR, как указано выше.

Маршрутизатору недопустимо изменять Neighbor Cache в результате получения DAR.

8.2.4. 6LBR, принимающий DAR

Когда 6LBR, реализующий заменяемый механизм DAD, получает DAR от 6LR, он выполняет проверку сообщения в соответствии с параграфом 8.2.1. Если сообщение DAR действительно, 6LBR выполняет поиск Registration Address в таблице DAD. Если запись найдена и записанный адрес EUI-64 отличается от EUI-64 в DAR, маршрутизатор возвращает DAC NA с полем Status = 1 (дубликат адреса). Если адреса совпадают, возвращается DAC с полем Status = 0 и обновляется срок действия записи. Если записи не найдено в таблице DAD и Registration Lifetime отличается от 0, создаётся запись с полями EUI-64 и Registered Address из DAR. Если запись имеется в таблице DAD, значения EUI-64 совпадают, а Registration Lifetime = 0, запись удаляется из таблицы. В двух последних случаях 6LBR создаёт DAC с информацией из DAR и Status = 0. Сообщение DAC возвращается 6LR, т. е. отправителю DAR. В поле IPv6 Hop Limit устанавливается значение MULTIHOP_HOPLIMIT.

8.2.5. Обработка DAC

Когда 6LR, реализующий механизм DAD через узлы пересылки, получает сообщение DAC, он проверяет его в соответствии с параграфом 8.2.1. Если для действительного DAC нет Tentative NCE, соответствующей Registered Address и EUI-64, сообщение DAC игнорируется. В иных случаях сведения из DAC и Tentative NCE служат для формирования анонса NA, передаваемого хосту. Поле Status копируется из DAC в опцию ARO, передаваемую хосту. Если DAC указывает ошибку (Status ≠ 0), анонс NA возвращается хосту в соответствии с параграфом 6.5.2, а Tentative NCE для Registered Address удаляется. В ином случае она преобразуется в NCE.

Маршрутизатору недопустимо изменять Neighbor Cache в результате получения DAC, если нет Tentative NCE, соответствующей адресу IPv6 и EUI-64.

8.2.6. Восстановление после отказа

Если от 6LBR нет отклика в течение RETRANS_TIMER [RFC4861], 6LR повторяет отправку DAR маршрутизатору 6LBR до MAX_UNICAST_SOLICIT раз [RFC4861]. После этого маршрутизатору 6LR следует ответить хосту опцией ARO с полем Status = 0.

9. Протокольные константы

В этом разделе определены используемые в документе константы протокола на основе подмножества констант [RFC4861]. Символ * указывает константы, изменённые по сравнению с [RFC4861], + указывает новые константы. Дополнительные константы протокола определены в разделе 4.

Константа 6LBR

MIN_CONTEXT_CHANGE_DELAY+

300 секунд

Константы 6LR

MAX_RTR_ADVERTISEMENTS

3 передачи

MIN_DELAY_BETWEEN_RAS*

10 секунд

MAX_RA_DELAY_TIME*

2 секунды

TENTATIVE_NCE_LIFETIME+

20 секунд

Константы маршрутизатора

MULTIHOP_HOPLIMIT+

64

Константы хоста

RTR_SOLICITATION_INTERVAL*

10 секунд

MAX_RTR_SOLICITATIONS

3 передачи

MAX_RTR_SOLICITATION_INTERVAL+

60 секунд

10. Примеры

10.1. Сообщения

   6LN                                                        6LR
    |                                                          |
1.  |       ---------- Router Solicitation -------->           |
    |                       [SLLAO]                            |
    |                                                          |
2.  |       <-------- Router Advertisement ---------           |
    |              [PIO + 6CO + ABRO + SLLAO]                  |

Рисунок 2. Базовый обмен RS/RA между узлом и 6LR или 6LBR.

   6LN                                                        6LR
    |                                                          |
1.  |       --------- NS с Address Registration ------->       |
    |                     [ARO + SLLAO]                        |
    |                                                          |
2.  |       <------- NA с Address Registration ---------       |
    |                     [ARO со Status]                      |

Рисунок 3. Регистрация адреса в ND.

   6LN                           6LR                          6LBR
    |                             |                             |
1.  | ---- NS с Address Reg ----> |                             |
    |      [ARO + SLLAO]          |                             |
    |                             |                             |
2.  |                             | ----------- DAR ----------> |
    |                             |                             |
3.  |                             | <---------- DAC ----------- |
    |                             |                             |
4.  | <---- NA с Address Reg ---- |                             |
    |       [ARO со Status]       |

Рисунок 4. Регистрация адреса с Multihop DAD.

10.2. Пример загрузки хоста

Ниже описываются варианты начальной загрузки адреса с использованием улучшенных механизмов ND, заданных этим документом. Предполагается, что 6LN сначала выполняет последовательность операций для получения защищённого доступа на канальном уровне LoWPAN и ключа защиты на этом уровне. Методы организации защиты на канальном уровне выходят за рамки этого документа. В примере IEEE 802.15.4 6LN формирует короткий 16-битовый адрес IPv6 с использованием DHCPv6 (т. е. флаг M не установлен в анонсах RA).

  1. После организации зашиты на канальном уровне 6LN назначает себе адрес link-local IPv6 на основе адреса канального уровня EUI-64 в соответствии с [RFC4944].

  2. Затем 6LN определяет 1 или несколько применяемых по умолчанию маршрутизаторов в сети путём отправки запроса RS по групповому адресу all-routers с опцией SLLAO, содержащей его адрес EUI-64 на канале. Если 6LN способен получить адрес маршрутизатора на канальном уровне за счёт операций этого уровня, он может сформировать адрес получателя link-local IPv6 для маршрутизатора и передать индивидуальный запрос RS. Маршрутизатор 6LR отвечает индивидуальным анонсом RA по IP-адресу отправителя, используя SLLAO из RS (он может создать Tentative NCE). См. рисунок 2.

  3. Для взаимодействия через несколько узлов пересылки 6LN настраивает глобальный адрес IPv6. Для минимизации издержек 6LN желает настроить свой адрес IPv6 на основе короткого 16-битового адреса в соответствии с [RFC4944]. Поскольку сеть является неуправляемой (флаг M сброшен в RA), 6LN случайно выбирает 16-битовый адрес на канальном уровне и формирует из него временный (Tentative) адрес IPv6.

  4. Затем 6LN регистрирует этот адрес на одном или нескольких принятых по умолчанию маршрутизаторах, передавая индивидуальное сообщение NS с опцией ARO содержащий его временный (Tentative) глобальный адрес IPv6 для регистрации, Registration Lifetime и EUI-64. Включается также опция SLLAO с адресом канального уровня, соответствующим регистрируемому адресу. При сообщении NA об успехе (Status — 0) адрес можно использовать и 6LN считает, что проверка на дубликат завершилась успешно. Если получено сообщение NA о дубликате (Status = 1), 6LN удаляет временный адрес IPv6 и 16-битовый адрес на канальном уровне, после чего возвращается к этапу 3. При получении сообщение о переполнении кэша соседей (Status = 2) 6LN пытается зарегистрироваться на другом маршрутизаторе, принятом по умолчанию, а при отсутствии такового возвращается к этапу 2 (см. рисунок 3). Отметим, что сообщение NA с ошибкой передаётся по адресу link-local IPv6, основанному на EUI-64, а не по 16-битовому адресу (дубликат).

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

Если применяется DAD и распространение данных о префиксах и контексте через узлы пересылки, влияние 6LR и хостов, следующих описанному выше процессу загрузки, представляет собой «волну» настройки 6LR и хостов, перемещающийся от 6LBR. Сначала хосты и 6LR, подключённые напрямую к 6LBR, получат один или несколько анонсов RA, затем они настроят и зарегистрируют свои адреса IPv6. После этого они включат протокол маршрутизации и начнут передачу анонсов с RA. Это приведёт к получению новым набором 6LR и хостов откликов на их RS, формированию и регистрации адресов и т. д. Процедура повторяется, пока все 6LR и хосты не будут настроены.

10.2.1. Сообщения при загрузке хоста

В этом параграфе представлены примеры сообщений, относящиеся к описанному выше процессу загрузки. При обсуждении применяется показанная ниже нотация.

LL64

Адрес на канальном уровне, основанный на EUI-64, который служит также длинным адресом 802.15.4.

GP16

Глобальный адрес на основе короткого адреса 802.15.4. Этот адрес может быть неуникальным.

GP64

Глобальный адрес, выведенный на основе EUI-64 в соответствии с [RFC4944].

MAC64

Адрес EUI-64, используемый на канальном уровне.

MAC16

Короткий 16-битовый адрес IEEE 802.15.4.

Отметим, что в некоторых реализациях могут применяться адреса LL64 и GP16 вместо LL64 и GP64. Далее показан пример потока сообщений при регистрации адреса GP16 узлом, использующим LL64, для проверки DAD через узлы пересылки.

6LN-----RS-------->6LR
 Src= LL64 (6LN)
 Dst= all-router-link-scope-multicast
 SLLAO= MAC64 (6LN)

6LR------RA--------->6LN
 Src= LL64 (6LR)
 Dst= LL64 (6LN)
Примечание. Адресом отправителя RA должен быть link-local (4.2 в RFC 4861).
6LN-------NS Reg------>6LR
 Src= GP16 (6LN)
 Dst= LL64 (6LR)
 ARO
 SLLAO= MAC16 (6LN)

6LR---------DAR----->6LBR
 Src= GP64 или GP16 (6LR)
 Dst= GP64 или GP16 (6LBR)
 Registered Address= GP16 (6LN) и EUI-64 (6LN)

6LBR-------DAC--------->6LR
 Src= GP64 или GP16 (6LBR)
 Dst= GP64 или GP16 (6LR)
 Копирование информации из DAR
Если Status = 0:
6LR ---------NA-Reg------->6LN
 Src= LL64 (6LR)
 Dst= GP16 (6LN)
 ARO со Status = 0
Если Status ≠ 0:
6LR ---------NA-Reg-------->6LN
 Src= LL64 (6LR)
 Dst= LL64 (6LN) --> Выводится из EUI-64 в ARO
 ARO со Status > 0

Рисунок 5. Примеры адресов сообщений.


10.3. Пример взаимодействия маршрутизаторов

В топологии route-over, когда 6LR используют протокол маршрутизации, загрузка и поддержка кэша соседей несколько отличаются. Приведённые в этом параграфе сведения служат лишь рекомендациями для разработчиков. При инициализации 6LR тот может выбрать загрузку как хост с использованием родительского 6LR, если multihop DAD выполняется с 6LBR. Управление кэшем соседей в маршрутизаторе и распознавание адресов соседних маршрутизаторов описаны в параграфах 6.5.3 и 6.5.5. В примере канал в соседнюю 6LoWPAN считается защищённым.

10.3.1. Загрузка маршрутизатора

В этом примере загружающийся 6LR R1 находится в нескольких этапах пересылки от 6LBR и окружен другими 6LR. Изначально R1 ведёт себя как хост, передавая групповой запрос RS и получая RA от одного или нескольких соседних 6LR. R1 выбирает один 6LR в качестве временно принятого по умолчанию и выполняет через него распознавание адресов. Отметим, что если multihop DAD не требуется (например, в управляемой сети или при использовании адресов на основе EUI-64), выбирать временный маршрутизатор для использования по умолчанию не требуется. Однако отправка изначального RS может быть нужна для автоматической настройки адреса с использованием глобального префикса, распространяемого 6LBR. На основе данных из анонсов RA маршрутизатор R1 обновляет свой кэш записями для всех соседних 6LR. По завершении регистрации адресов загружающийся маршрутизатор удаляет временную запись для маршрутизатора по умолчанию и запускает протокол маршрутизации. Отметим также, что R1 может обновить свою регистрацию multihop DAD в 6LBR (используя next-hop 6LR, определённый протоколом маршрутизации для связи с 6LBR).

10.3.2. Обновление кэша соседей

В этом примере имеется три 6LR – R1, R2, R3. При исходной загрузке R2 он видит лишь R1 и создаёт NCE для R1. Предположим, что R2 получает действительное обновление маршрутизации от R3, для которого у него нет NCE. Если реализация R2 поддерживает определение адресов канального уровня из пакетов протокола маршрутизации, Neighbor Cache обновляется напрямую с использованием данных канального уровня. Если же это невозможно, R2 следует использовать групповое сообщение NS с установкой в поле отправителя своего глобального или link-local адреса в зависимости от области действия IP-адреса отправителя в полученном пакете протокола маршрутизации. Получателем NS является адрес отправителя IPv6 из полученного пакета обновления маршрутизации. Формат сообщения NS описан в параграфе 4.3 [RFC4861].

В более общем смысле любой 6LR, получающий действительное обновление маршрутизации от соседа, для которого у него нет NCE, должен обновить Neighbor Cache, как описано выше. IP-адрес маршрутизатора (6LR и 6LBR), определённый с помощью ND, не распространяется в протокол маршрутизации.

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

Применимо рассмотрение вопросов безопасности IPv6 ND [RFC4861] и автоматической настройки адресов [RFC4862]. Дополнительное рассмотрение вопросов безопасности приведено в [RFC3756].

Упомянутые выше соображения несколько изменены в результате того, что в этой спецификации флаг M в анонсах RA отключает использование автоматической настройки адресов без учёта состояния для адресов, не выведенных из EUI-64. Таким образом, мошеннический маршрутизатор на канале может принудительно применять для коротких адресов лишь DHCP, тогда как в [RFC4861] и [RFC4862] он может лишь вызвать добавление DHCP, но не отключить автоматическую настройку без учёта состояния для коротких адресов.

Эта спецификация предполагает достаточную защищенность канального уровня, например, с помощью криптографии на подуровне MAC. Таким образом, модель угроз не отличается от IPv6 ND [RFC4861]. Здесь применяется первая модель доверия из раздела 3 в [RFC3756]. Однако будущие протоколы защиты 6LoWPAN, применяемые к ND для 6LoWPAN, выходят за рамки документа.

Механизмы DAD через маршрутизаторы полагаются на сообщения DAR и DAC, пересылаемые 6LR, и в результате проверка hop_limit=255 не применима у получателя. Это означает возможность отправки таких сообщений любым узлом Internet. Для предотвращения проблем, связанных с этим, от маршрутизаторов требуется предотвращение изменения NCE на основе таких сообщений и их отбрасывание в случае приёма через интерфейс, не настроенный явно на использование такой оптимизации.

В будущих развёртываниях может применяться механизм SEcure Neighbor Discovery (SEND) [RFC3971] [RFC3972]. Он возможен с ARO, передаваемыми между хостами и маршрутизаторами, поскольку регистрируемый адрес является адресом отправителя IPv6 в NS и SEND проверяет адрес отправителя (IPv6) пакета. Применение SEND для взаимодействия между маршрутизаторами выходит за рамки документа.

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

Этот документ регистрирует 3 новых типа опций ND в субреестре IPv6 Neighbor Discovery Option Formats:

  • Address Registration Option (33);

  • 6LoWPAN Context Option (34);

  • Authoritative Border Router Option (35).

Документ регистрирует 2 новых «типа» ICMPv6 в субреестре ICMPv6 “type” Numbers:

  • Duplicate Address Request (157);

  • Duplicate Address Confirmation (158).

Агентство IANA создало новый субреестр для значений Status опции ARO в реестре параметров ICMPv6:

  • параметры являются 8-битовыми целыми числами без знака (0-255);

  • регистрация происходит по процедуре Standards Action [RFC5226];

  • исходные значение приведены в таблице 2.

Таблица 2. Значения поля Status.

Статус

Описание

0

Успех

1

Дубликат адреса

2

Переполнение кэша соседей

3-255

Выделяются по процедуре Standards Action [RFC5226]

13. Взаимодействие с другими расширениями ND

Имеется два класса расширений ND, взаимодействующих с этой спецификацией разными способами.

Один класс включает расширения механизмов DAD из [RFC4861] и [RFC4862]. Примером является Optimistic DAD [RFC4429]. Такие расширения не применяются при использовании этой спецификации, поскольку они основаны на опции ARO для DAD (это всегда 1 круговой обход к маршрутизатору для проверки DAD).

Все прочие (не DAD) расширения ND, будь то тип выбора пути, такой как предпочтения принятого по умолчанию маршрутизатора [RFC4191], типы настройки, такие как конфигурация DNS [RFC6106], или иные типы вроде обнаружения подключения в сети (Detecting Network Attachment) [RFC6059] ортогональны этой спецификации и будут работать как есть.

14. Рекомендации для новых функций

В этом разделе приведены рекомендации по новым функциям протокола, определенным в этом документе. Указаны также ожидания в части реализации и развёртывания функций. Раздел является информационным и не меняет заданных выше требований, а лишь содержит их сводку в компактной форме. Сводка служит руководством, указывающим важность развёртывания функции на основе доступной во время создания документа информации. В некоторых случаях для развёртывания указано требование «следует», а для реализации – «должно». Это обусловлено наличием заменяемых функций, вместо которых при развёртывании могут быть выбраны другие методы. Поэтому для заменяемых функций рекомендуется обеспечивать возможность отключения. При составлении сводки предпочтение было отдано лаконичности, а не полноте.

Таблица 3. Функции 6LoWPAN-ND для хоста.

Параграф

Описание

Развёртывание

Реализация

3.1

RA по инициативе хоста

должно

должно

3.2

Адрес IPv6 на основе EUI-64

должно

должно

16-битовый адрес на основе MAC

может

следует

Иные неуникальные адреса

может

может

3.3

RS по инициативе хоста

должно

должно

Обработка ABRO

следует

должно

4.1

Регистрация с опцией ARO

должно

должно

4.2, 5.4

6CO

следует

следует

5.2

Присоединение к группе solicited-node

–

–

Присоединение к группе all-nodes

должно

должно

Использование данных канального уровня для NUD

может

может

5.5

6LoWPAN-ND NUD

должно

должно

5.8.2

Поведение при пробуждении

следует

следует

Таблица 4. Функции 6LoWPAN-ND для 6LR.

Параграф

Описание

Развёртывание

Реализация

3.1

Периодические RA

не следует

не следует

3.2

Назначение адреса при старте

следует

должно

3.3

Поддержка MAC хостов на основе EUI-64

должно

должно

Поддержка 16-битовых MAC хостов

может

следует

3.4, 4.3, 8.1.3, 8.1.4

Передача и обработка ABRO

следует

должно

8.1

Сохранение и распространение префиксов через узлы пересылки

следует

должно

3.5

Tentative NCE

должно

должно

8.2

Multihop DAD

следует

должно

4.1, 6.5, 6.5.1 – 6.5.5

Поддержка ARO

должно

должно

4.2

6CO

следует

следует

6.3

Обработка RS/ABRO

должно

должно

Таблица 5. Функции 6LoWPAN-ND для 6LBR.

Параграф

Описание

Развёртывание

Реализация

3.1

Периодические RA

не следует

не следует

3.2

Автоматическая настройка адреса на интерфейсе маршрутизатора

недопустимо

недопустимо

3.3

Поддержка EUI-64 MAC на интерфейсе 6LoWPAN

должно

должно

8.1 – 8.1.1, 8.1.5

Распространение префиксов через узлы пересылки

следует

должно

8.2

DAD через узлы пересылки

следует

должно

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

Спасибо Pascal Thubert, Jonathan Hui, Richard Kelsey, Geoff Mulligan, Julien Abeille, Alexandru Petrescu, Peter Siklosi, Pieter De Mil, Fred Baker, Anthony Schoofs, Phil Roberts, Daniel Gavelle, Joseph Reddy, Robert Cragie, Mathilde Durvy, Colin O’Flynn, Dario Tedeschi, Esko Dijk, Joakim Eriksson за полезные дискуссии и комментарии, улучшившие документ.

Отдельная благодарность Pascal Thubert за исходную идею регистрации и большой вклад в ранние версии документа, Jonathan Hui за идеи распространения префиксов и контекста, а также большой вклад в ранние версии, Colin O’Flynn за полезные предложения по обработке ошибок (параграф 6.5.2) и вклад в раздел 10, Geoff Mulligan за предложение реализовать регистрацию адреса как часть сообщений IPv6 ND, Mathilde Durvy за помощь в разъяснении взаимодействия с маршрутизаторами.

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

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

[ETHERNET] “IEEE Standard for Information technology – Telecommunications and information exchange between systems – Local and metropolitan area networks — Specific requirements – Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications”, IEEE Std 802.3-2008, December 2008, <http://standards.ieee.org/getieee802/download/802.3-2008_section1.pdf>.

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

[RFC2460] Deering, S. and R. Hinden, “Internet Protocol, Version 6 (IPv6) Specification”, RFC 24604, December 1998.

[RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, “IPv6 over Non-Broadcast Multiple Access (NBMA) networks”, RFC 2491, January 1999.

[RFC4191] Draves, R. and D. Thaler, “Default Router Preferences and More-Specific Routes”, RFC 4191, November 2005.

[RFC4193] Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses”, RFC 4193, October 2005.

[RFC4291] Hinden, R. and S. Deering, “IP Version 6 Addressing Architecture”, RFC 4291, February 2006.

[RFC4443] Conta, A., Deering, S., and M. Gupta, “Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification”, RFC 4443, March 2006.

[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, “Neighbor Discovery for IP version 6 (IPv6)”, RFC 4861, September 2007.

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, “IPv6 Stateless Address Autoconfiguration”, RFC 4862, September 2007.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, “Transmission of IPv6 Packets over IEEE 802.15.4 Networks”, RFC 4944, September 2007.

[RFC5226] Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs”, BCP 26, RFC 5226, May 2008.

[RFC6282] Hui, J. and P. Thubert, “Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks”, RFC 6282, September 2011.

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

[EUI64] IEEE, “Guidelines for 64-bit Global Identifier (EUI-64(TM)) Registration Authority”, <http://standards.ieee.org/regauth/oui/tutorials/EUI64.html>.

[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, RFC 3315, July 2003.

[RFC3633] Troan, O. and R. Droms, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6”, RFC 3633, December 2003.

[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, “IPv6 Neighbor Discovery (ND) Trust Models and Threats”, RFC 3756, May 2004.

[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, “Secure Neighbor Discovery (SEND)”, RFC 3971, March 2005.

[RFC3972] Aura, T., “Cryptographically Generated Addresses (CGA)”, RFC 3972, March 2005.

[RFC4429] Moore, N., “Optimistic Duplicate Address Detection (DAD) for IPv6”, RFC 4429, April 2006.

[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, August 2007.

[RFC4941] Narten, T., Draves, R., and S. Krishnan, “Privacy Extensions for Stateless Address Autoconfiguration in IPv6”, RFC 4941, September 2007.

[RFC5889] Baccelli, E. and M. Townsley, “IP Addressing Model in Ad Hoc Networks”, RFC 5889, September 2010.

[RFC6059] Krishnan, S. and G. Daley, “Simple Procedures for Detecting Network Attachment in IPv6”, RFC 6059, November 2010.

[RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, “IPv6 Router Advertisement Options for DNS Configuration”, RFC 6106, November 2010.



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


Zach Shelby (editor)


Sensinode


Konekuja 2


Oulu 90620


Finland


Phone: +358407796297


EMail: zach@sensinode.com


Samita Chakrabarti


Ericsson


EMail: samita.chakrabarti@ericsson.com


Erik Nordmark


Cisco Systems


EMail: nordmark@cisco.com


Carsten Bormann


Universitaet Bremen TZI


Postfach 330440


Bremen D-28359


Germany


Phone: +49-421-218-63921


EMail: cabo@tzi.org




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


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


nmalykh@protokols.ru 




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






2Internet Engineering Task Force.






3Internet Engineering Steering Group.






4Документ заменен RFC 8200. Прим. перев.



 											


		
						

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

					


					

					
			




	

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