Энциклопедия сетевых протоколов

Internet Engineering Task Force (IETF)                        D. Crocker
Request for Comments: 8553                   Brandenburg InternetWorking
BCP: 222                                                      March 2019
Updates: 2782, 3263, 3529, 3620, 3832,
         3887, 3958, 4120, 4227, 4386,
         4387, 4976, 5026, 5328, 5389,
         5415, 5518, 5555, 5617, 5679,
         5766, 5780, 5804, 5864, 5928,
         6120, 6186, 6376, 6733, 6763,
         7208, 7489, 8145
Category: Best Current Practice
ISSN: 2070-1721

DNS AttrLeaf Changes: Fixing Specifications That Use Underscored Node Names

Изменения DNS AttrLeaf в спецификациях с именами узлов с подчёркиванием

PDF

Аннотация

Использование символа подчёркивания для префикса создаёт пространство ограниченной интерпретации записей о ресурсах. Исходно применение символа подчёркивания в качестве префикса доменного имени было определено без реестра IANA. Это привело к несогласованным действиям по созданию имён, выведенных из одного пространства имён. Реестр для имён с подчёркиванием определён в RFC 8552 и имеющиеся спецификации с использованием имён с символом подчёркивания требуется изменить в соответствии с новым реестром. Этот документ задаёт такие изменения. Эти изменения позволяют сохранить имеющиеся программы и эксплуатационную практику, адаптируя спецификации к новой модели с реестром имён с символом подчёркивания.

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

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

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

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

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

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

Исходно применение символа подчёркивания в качестве префикса доменного имени [RFC1035], создающего пространство ограниченной интерпретации записей о ресурсах было определено без реестра IANA [IANA-reg]. Это привело к несогласованным действиям по созданию имён, выведенных из одного пространства имён. Реестр таких имён сейчас определён (раздел 4 в [RFC8552]) и рассмотрены основы применения имён с символом подчёркивания [RFC8552].

Базовая модель регистрации имён с символом подчёркивания, как указано в [RFC8552], состоит в том, что каждая запись уникальна как комбинация типа записи и «глобального» (верхнего уровня) имени узла с символом подчёркивания, т. е. ближайшего в корню DNS имени с символом подчеркивания.

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

Кроме того, документы, определяющие записи о ресурсах DNS SRV [RFC2782] и URI [RFC7553] DNS, содержат меташаблоны для назначения имён с подчёркиванием, частично основанные на отдельных реестрах [RFC6335]. Для той части, которая определяет глобальное (верхнего уровня) имя узла с подчёркиванием, это закрепляет несогласованное именование с символом подчёркивания отдельными спецификациями из того же пространства имён. Данный документ устраняет это, предоставляя детальный пересмотр спецификация SRV и URI для приведения их в соответствие с единым интегрированным реестром Underscored and Globally Scoped DNS Node Names.

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

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

2. Использование RRset с подчёркиванием в спецификациях

Использование имён с символом подчёркивания специфично для каждого RR TYPE с определённой областью действия. Каждое имя задаёт место, но не определяет правил для присутствия под этой точкой в виде дополнительного именования с подчёркиванием или узла-листа с записями о ресурсах. Детали таких правил задают спецификации отдельных RR TYPE. В последующих параграфах описано, как имена с символом подчёркивания используются с типами RR, которые они именуют.

2.1. TXT RRset

Примечание. Документы этой категории включают [RFC5518], [RFC5617], [RFC6120], [RFC6376], [RFC6763], [RFC7208], [RFC7489].

В этом параграфе представлен базовый подход к внесению изменений в имеющиеся спецификации, определяющие прямое использование имён с символом подчёркивания при определении области действия TXT RRset. Представлены сведения, требуемые для приспособления таких спецификаций в использованию реестра IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Таким образом, этот подход означает как обновление имеющихся спецификаций, так и рекомендации по внесению изменений при пересмотре документов.

Для любого документа, задающего использование TXT RRset под одним или несколькими именами с подчёркиванием, глобальное имя узла предполагается зарегистрированным в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Предпринята попытка найти имеющиеся документы, в которых это сделано, зарегистрировать глобальные имена с символом подчёркивания и указать их в исходном списке имён, включённых в реестр.

Для публичных спецификаций, определяющих применение TXT RRset и использующих имя с символом подчёркивания, ниже приведён шаблон текста, который может быть включён в раздел «Взаимодействие с IANA (IANA Considerations).

В соответствии с [RFC8552], пожалуйста добавьте приведённую ниже запись в реестр Underscored and Globally Scoped DNS Node Names.

Таблица . Запись реестра Underscored and Globally Scoped DNS Node Names для TXT RR.

2.2. SRV RRset

Примечание. Документы этой категории включают [RFC3263], [RFC3529], [RFC3620], [RFC3832], [RFC3887], [RFC3958], [RFC4120], [RFC4227], [RFC4386], [RFC4387], [RFC4976], [RFC5026], [RFC5328], [RFC5389], [RFC5415], [RFC5555], [RFC5679], [RFC5766], [RFC5780], [RFC5804], [RFC5864], [RFC5928], [RFC6186].

В спецификации записи SRV [RFC2782] задан шаблон для использования имён с символом подчёркивания. Глобальное имя характеризуется как ссылка на protocol, связанный с использованием SRV RRset.

В этом параграфе представлен базовый подход к внесению изменений в имеющиеся спецификации, определяющие использование SRV RRset. Представлены сведения, требуемые для приспособления таких спецификаций в использованию реестра IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Таким образом, этот подход означает как обновление имеющихся спецификаций, так и рекомендации по внесению изменений при пересмотре документов.

Для любого документа, задающего использование SRV RRset, глобальное (protocol) имя узла с символом подчёркивания предполагается зарегистрированным в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Предпринята попытка найти имеющиеся документы, в которых это сделано, зарегистрировать глобальные имена с символом подчёркивания и указать их в исходном списке имён, включённых в реестр.

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

В соответствии с [RFC8552], пожалуйста добавьте приведённую ниже запись в реестр Underscored and Globally Scoped DNS Node Names.

Таблица . Запись реестра Underscored and Globally Scoped DNS Node Names для SRV RR.

2.3. URI RRset

В спецификации записи URI [RFC7553] задан шаблон для использования имён с символом подчёркивания. Глобальное имя характеризуется как именование протокола (protocol), связанного с применением URI RR, или обращение последовательности Enumservice [RFC6117].

В этом параграфе представлен базовый подход к внесению изменений в имеющиеся спецификации, определяющие использование URI RRset. Представлены сведения, требуемые для приспособления таких спецификаций в использованию реестра IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Таким образом, этот подход означает как обновление имеющихся спецификаций, так и рекомендации по внесению изменений при пересмотре документов.

Для любого документа, задающего использование URI RRset, глобальное (protocol или Enumservice верхнего уровня) имя узла с символом подчёркивания предполагается зарегистрированным в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552]. Предпринята попытка найти имеющиеся документы, в которых это сделано, зарегистрировать глобальные имена с символом подчёркивания и указать их в исходном списке имён, включённых в реестр.

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

В соответствии с [RFC8552], пожалуйста добавьте приведённую ниже запись в реестр Underscored and Globally Scoped DNS Node Names.

Таблица . Запись реестра Underscored and Globally Scoped DNS Node Names для URI RR.

3. Спецификации шаблонов с символом подчёркивания

3.1. Изменение спецификации SRV

Спецификация доменного имени, под которым появляется запись SRV [RFC2782], включает шаблон использования имён с символом подчёркивания. Глобальное имя с подчёркиванием характеризуется как указывающее протокол, связанный с использованием SRV RR.

В текст [RFC2782] внесены показанные ниже обновления. Следует также отметить, что добавлена нормативная ссылка на RFC 8552 в раздел «Литература» RFC 2782.

Прежнее

Формат SRV RR.

Ниже представлен формат SRV RR, имеющей код типа DNS 33.

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

…

Proto

Новое

Формат SRV RR.

Ниже представлен формат SRV RR, имеющей код типа DNS 33.

«_Service._Proto.Name TTL Class SRV Priority Weight Port Target»

_…_

Proto

3.2. Изменение спецификации URI

Спецификация доменного имени ( под которым появляется запись URI [RFC7553]) похожа на спецификацию SRV [RFC2782], хотя в тексте упоминается лишь имя service, а не отличие service от protocol. Кроме того, спецификация URI RR допускает варианты схемы именования с символом подчёркивания:

одна схема соответствует применяемой для SRV с глобальным именем узла с подчёркиванием protocol;

другая схема основана на обращении последовательности Enumservice [RFC6117].

Текст [RFC7553] изменён, как показано ниже. Кроме того, добавлена нормативная ссылка на RFC 8552 в раздел «Литература» RFC 7553.

Прежнее

4.1. Имя, класс и тип владельца

Имя владельца URI подчиняется специальным соглашениям. Подобно SRV RR [RFC2782], в URI RR имеются сведения о службе, указанные в имени владельца. Для кодирования службы в конкретном имени владельца применяются параметры службы. Допускаются параметры, зарегистрированные в реестре IANA Service Name and Transport Protocol Port Number Registry [RFC6335] или в качестве Enumservice [RFC6117]. Порядок параметров Enumservice Registration меняется на обратный (субтипы перед типом) с добавлением в начало символа подчёркивания (_) и размещением перед именем владельца в отдельных метках. Символ подчёркивания добавляется перед параметрами службы для предотвращения конфликтов с встречающимися на практике метками DNS и порядок меняется на обратный, чтобы при необходимости можно было передавать полномочия различным зонам (и, следовательно, провайдерам DNS).

Предположим, например, что выполняется поиск URI службы с ENUM Service Parameter «A:B:C» для хоста example.com. Запрос будет иметь вид (QNAME,QTYPE)=(«_C._B._A.example.com»,»URI»). В качестве другого примера рассмотрим поиск URI службы с Service Name «A» и Transport Protocol «B» для хоста example.com. Запрос будет иметь вид (QNAME,QTYPE)=(«_A._B.example.com»,»URI»).

Новое

4.1. Имя, класс и тип владельца

Имя владельца URI подчиняется специальным соглашениям. Подобно SRV RRset [RFC2782], глобальное (верхнего уровня) имя URI RRset с символом подчёркивания следует регистрировать в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552].

Подобно SRV RRset, в URI RRset имеются сведения о службе, указанные в имени владельца. Допустимые параметры служб указаны ниже.

• Параметры, зарегистрированные в реестре IANA Service Name and Transport Protocol Port Number Registry [RFC6335]. Символ подчёркивания добавляется перед параметрами службы для предотвращения конфликтов с встречающимися на практике метками DNS и порядок меняется на обратный, чтобы при необходимости можно было передавать полномочия различным зонам (и, следовательно, провайдерам DNS).

• Параметры, зарегистрированные в Enumservice Registrations [RFC6117]. Порядок параметров Enumservice Registration меняется на обратный (субтипы перед типом) с добавлением в начало символа подчёркивания (_) и размещением перед именем владельца в отдельных метках. Имя Enumservice верхнего уровня (глобальное) становится глобальным именем для регистрации в соответствии с RFC 8552.

Предположим, например, что выполняется поиск URI службы с ENUM Service Parameter «A:B:C» для хоста example.com. Запрос будет иметь вид (QNAME,QTYPE)=(«_C._B._A.example.com»,»URI»). В качестве другого примера рассмотрим поиск URI службы с Service Name «A» и Transport Protocol «B» для хоста example.com. Запрос будет иметь вид (QNAME,QTYPE)=(«_A._B.example.com»,»URI»).

3.3. Изменение спецификации DNSSEC Signaling

В Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC) [RFC8145] определено использование имён узлов DNS, фактически разрешающее все имена, начинающиеся с _ta-, при использовании в запросе NULL RR.

Текст параграфа 5.1 (Формат запроса) в RFC 8145 изменяется, как указано ниже. Кроме того, добавлена нормативная ссылка на RFC 8552 в раздел «Литература» RFC 8145.

Прежнее

Например, проверяющий распознаватель DNS …

                              QNAME=_ta-4444.

Новое

Например, проверяющий распознаватель DNS … «QNAME=_ta-4444».

Для NULL RR в реестре IANA Underscored and Globally Scoped DNS Node Names [RFC8552] зарегистрирована запись для всех узлов, имена которых начинаются с _ta-.

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

Хотя этот документ упоминает реестры IANA, он не задаёт новых реестров и процедур.

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

Этот документ не создаёт проблем безопасности.

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

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

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

[RFC6117] Hoeneisen, B., Mayrhofer, A., and J. Livingood, «IANA Registration of Enumservices: Guide, Template, and IANA Considerations», RFC 6117, DOI 10.17487/RFC6117, March 2011, <https://www.rfc-editor.org/info/rfc6117>.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, «Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry», BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.

[RFC7553] Faltstrom, P. and O. Kolkman, «The Uniform Resource Identifier (URI) DNS Resource Record», RFC 7553, DOI 10.17487/RFC7553, June 2015, <https://www.rfc-editor.org/info/rfc7553>.

[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, «Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)», RFC 8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc-editor.org/info/rfc8145>.

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

[RFC8552] Crocker, D., «Scoped Interpretation of DNS Resource Records through «Underscored» Naming of Attribute Leaves», RFC 8552, DOI 10.17487/RFC8552, March 2019, <https://www.rfc-editor.org/info/rfc8552>.

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

[IANA-reg] IANA, «Protocol Registries», <https://www.iana.org/protocols>.

[RFC1035] Mockapetris, P., «Domain names — implementation and specification», STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.

[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, «A DNS RR for specifying the location of services (DNS SRV)», RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.

[RFC3263] Rosenberg, J. and H. Schulzrinne, «Session Initiation Protocol (SIP): Locating SIP Servers», RFC 3263, DOI 10.17487/RFC3263, June 2002, <https://www.rfc-editor.org/info/rfc3263>.

[RFC3529] Harold, W., «Using Extensible Markup Language-Remote Procedure Calling (XML-RPC) in Blocks Extensible Exchange Protocol (BEEP)», RFC 3529, DOI 10.17487/RFC3529, April 2003, <https://www.rfc-editor.org/info/rfc3529>.

[RFC3620] New, D., «The TUNNEL Profile», RFC 3620, DOI 10.17487/RFC3620, October 2003, <https://www.rfc-editor.org/info/rfc3620>.

[RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, «Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV», RFC 3832, DOI 10.17487/RFC3832, July 2004, <https://www.rfc-editor.org/info/rfc3832>.

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

[RFC3958] Daigle, L. and A. Newton, «Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)», RFC 3958, DOI 10.17487/RFC3958, January 2005, <https://www.rfc-editor.org/info/rfc3958>.

[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, «The Kerberos Network Authentication Service (V5)», RFC 4120, DOI 10.17487/RFC4120, July 2005, <https://www.rfc-editor.org/info/rfc4120>.

[RFC4227] O’Tuathail, E. and M. Rose, «Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)», RFC 4227, DOI 10.17487/RFC4227, January 2006, <https://www.rfc-editor.org/info/rfc4227>.

[RFC4386] Boeyen, S. and P. Hallam-Baker, «Internet X.509 Public Key Infrastructure Repository Locator Service», RFC 4386, DOI 10.17487/RFC4386, February 2006, <https://www.rfc-editor.org/info/rfc4386>.

[RFC4387] Gutmann, P., Ed., «Internet X.509 Public Key Infrastructure Operational Protocols: Certificate Store Access via HTTP», RFC 4387, DOI 10.17487/RFC4387, February 2006, <https://www.rfc-editor.org/info/rfc4387>.

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

[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., «Mobile IPv6 Bootstrapping in Split Scenario», RFC 5026, DOI 10.17487/RFC5026, October 2007, <https://www.rfc-editor.org/info/rfc5026>.

[RFC5328] Adolf, A. and P. MacAvock, «A Uniform Resource Name (URN) Namespace for the Digital Video Broadcasting Project (DVB)», RFC 5328, DOI 10.17487/RFC5328, September 2008, <https://www.rfc-editor.org/info/rfc5328>.

[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, «Session Traversal Utilities for NAT (STUN)», RFC 5389, DOI 10.17487/RFC5389, October 2008, <https://www.rfc-editor.org/info/rfc5389>.

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

[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, «Vouch By Reference», RFC 5518, DOI 10.17487/RFC5518, April 2009, <https://www.rfc-editor.org/info/rfc5518>.

[RFC5555] Soliman, H., Ed., «Mobile IPv6 Support for Dual Stack Hosts and Routers», RFC 5555, DOI 10.17487/RFC5555, June 2009, <https://www.rfc-editor.org/info/rfc5555>.

[RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, «DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)», RFC 5617, DOI 10.17487/RFC5617, August 2009, <https://www.rfc-editor.org/info/rfc5617>.

[RFC5679] Bajko, G., «Locating IEEE 802.21 Mobility Services ping DNS», RFC 5679, DOI 10.17487/RFC5679, December 2009, <https://www.rfc-editor.org/info/rfc5679>.

[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, «Traversal ping Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)», RFC 5766, DOI 10.17487/RFC5766, April 2010, <https://www.rfc-editor.org/info/rfc5766>.

[RFC5780] MacDonald, D. and B. Lowekamp, «NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)», RFC 5780, DOI 10.17487/RFC5780, May 2010, <https://www.rfc-editor.org/info/rfc5780>.

[RFC5804] Melnikov, A., Ed. and T. Martin, «A Protocol for Remotely Managing Sieve Scripts», RFC 5804, DOI 10.17487/RFC5804, July 2010, <https://www.rfc-editor.org/info/rfc5804>.

[RFC5864] Allbery, R., «DNS SRV Resource Records for AFS», RFC 5864, DOI 10.17487/RFC5864, April 2010, <https://www.rfc-editor.org/info/rfc5864>.

[RFC5928] Petit-Huguenin, M., «Traversal Using Relays around NAT (TURN) Resolution Mechanism», RFC 5928, DOI 10.17487/RFC5928, August 2010, <https://www.rfc-editor.org/info/rfc5928>.

[RFC6120] Saint-Andre, P., «Extensible Messaging and Presence Protocol (XMPP): Core», RFC 6120, DOI 10.17487/RFC6120, March 2011, <https://www.rfc-editor.org/info/rfc6120>.

[RFC6186] Daboo, C., «Use of SRV Records for Locating Email Submission/Access Services», RFC 6186, DOI 10.17487/RFC6186, March 2011, <https://www.rfc-editor.org/info/rfc6186>.

[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., «DomainKeys Identified Mail (DKIM) Signatures», STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.

[RFC6763] Cheshire, S. and M. Krochmal, «DNS-Based Service Discovery», RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.

[RFC7208] Kitterman, S., «Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1», RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.

[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., «Domain-based Message Authentication, Reporting, and Conformance (DMARC)», RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.

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

Спасибо Bill Fenner, Dick Franks, Tony Hansen, Peter Koch, Olaf Kolkman, Andrew Sullivan за тщательное рецензирование (первоначальных) черновых версий. За последующие улучшения спасибо Tim Wicinski, John Levine, Bob Harold, Joel Jaeggli, Ondrej Sury, Paul Wouters.

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

Адрес автора

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                        A. Bierman
Request for Comments: 8525                                     YumaWorks
Obsoletes: 7895                                             M. Bjorklund
Category: Standards Track                                 Tail-f Systems
ISSN: 2070-1721                                         J. Schoenwaelder
                                                       Jacobs University
                                                               K. Watsen
                                                         Watsen Networks
                                                               R. Wilton
                                                           Cisco Systems
                                                              March 2019

YANG Library

Библиотека YANG

PDF

Аннотация

Этот документ описывает библиотеку YANG, которая обеспечивает информацию обо всех модулях YANG, хранилищах данных и их схемах, применяемых сервером сетевого управления. Обеспечиваемые простые механизмы кэширования позволяют клиентам минимизировать усилия при поиске информации. Данная версия библиотеки YANG поддерживает архитектуру NMDA¹ путем перечисления всех хранилищ, поддерживаемых сервером управления и схем, применяемых в каждом из этих хранилищ.

Данный документ отменяет RFC 7895.

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

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

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

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

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

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

Нужны стандартные механизмы для идентификации модулей YANG [RFC7950], хранилищ данных [RFC8342] и схем хранилищ [RFC8342] применяемых сервером сетевого управления. Данный документ описывает модуль YANG ietf-yang-library, который обеспечивает эту информацию. Эта версия библиотеки YANG совместима с архитектурой хранилищ NMDA [RFC8342]. Предыдущая версия библиотеки YANG, определённая в [RFC7895], не совместима с NMDA, поскольку предполагает применение во всех хранилищах одной схемы. Это может не соблюдаться в NMDA, где динамические хранилища конфигурации могут применять свои схемы. Кроме того, хранилище рабочего состояния может поддерживать ненастраиваемые модули YANG в дополнение к модулям, поддерживаемым традиционными хранилищами конфигурации.

Определения старой библиотеки YANG сохранены (для совместимости), но отмечены как deprecated (устаревшие). Для совместимости с прежними версиями серверам с поддержкой NMDA следует заполнять устаревшее дерево /modules-state в соответствии со старой версией. Новое дерево /yang-library будет игнорироваться старыми клиентами, но обеспечит все данные, требуемые поддерживающим NMDA клиентам (они будут игнорировать дерево /modules-state). При заполнении /modules-state рекомендуется указывать модули YANG с узлами данных config true, которые могут настраиваться через традиционные хранилища конфигурации, и модули YANG с узлами config false, которые возвращаются операцией NETCONF⁴ <get> или ее эквивалентом.

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

Если сервер использует множество модулей YANG, библиотека YANG может быть достаточно велика. Поскольку содержимое библиотеки YANG меняется очень редко, важна возможность клиентов кэшировать это содержимое и определять устаревшие данные кэша.

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

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

Перечисленные ниже термины определены в [RFC7950]:

• module — модуль;

• submodule — субмодуль;

• data node — узел данных.

В документе фраза «реализует модуль» (implement a module) применяется в трактовке параграфа 5.6.5 [RFC7950].

Перечисленные ниже термины определены в [RFC8342]:

• datastore — хранилище данных;

• datastore schema — схема хранилища данных;

• configuration — конфигурация;

• conventional configuration datastore — традиционное хранилище данных;

• operational state — рабочее состояние;

• operational state datastore — хранилище рабочего состояния;

• dynamic configuration datastore — динамическое хранилище конфигурации;

• client — клиент;

• server — сервер.

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

YANG library — библиотека YANG

Набор модулей и субмодулей YANG, хранилищ и схем хранилищ, применяемых сервером.

YANG library content identifier – идентификатор содержимого библиотеки YANG

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

В диаграммах деревьев данный документ использует обозначения, определённые в [RFC8340].

2. Постановка задачи

Приведённая ниже информация нужна клиентскому приложению (для каждого модуля YANG в библиотеке) для полного использования языка моделирования данных YANG:

• name — имя модуля YANG;

• revision — при наличии этой информации в модуле или субмодуле YANG номер выпуска берётся из наиболее свежего оператора revision в модуле или субмодуле;

• submodule list — имя и (при наличии) выпуск каждого субмодуля, используемого модулем;

• feature list — имя каждой функции (возможности) YANG, поддерживаемой сервером;

• deviation list — имя каждого модуля YANG с оператором deviation, влияющим на данный модуль YANG.

В дополнение к этому для каждого поддерживаемого сервером хранилища данных клиентскому приложению нужно:

• identity — отождествление YANG для хранилища данных;

• schema — схема (т. е. набор модулей), реализованная в хранилище.

Для выбора одного из вариантов модели данных библиотеки YANG использованы приведённые ниже критерии.

1. Информация должна быть удобна для потребителя. Поскольку библиотека YANG может быть велика, следует позволять клиентам кэшировать содержимое библиотеки YANG.

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

3. Можно не реализовать функцию или модуль в <operational>, даже если это реализовано в другом хранилище. Это требуется для переходного процесса — сервер, желающий реализовать <operational>, не обязан поддерживать все модули сразу.

4. Для данного модуля во всех хранилищах может быть реализован лишь один выпуск. Если модуль реализован в нескольких хранилищах, все они должны использовать один выпуск.

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

6. Должна обеспечиваться возможность использования библиотеки YANG при монтировании схемы [RFC8528].

3. Модель данных библиотеки YANG

Модуль ietf-yang-library предоставляет информацию о модулях, субмодулях, хранилищах и схемах хранилищ, поддерживаемых сервером. Все узлы данных модуля ietf-yang-library имеют тип config false и поэтому доступны лишь в хранилище рабочего состояния.

+-----------+
| хранилище |
+-----------+
     |
     | имеет
     V
+-----------+            +--------+                +------------+
|   схема   |объединение | набор  |  состоит из    | модули +   |
| хранилища |----------->| модулей|--------------->| субмодули  |
+-----------+            +--------+                +------------+

Рисунок 1.

Концептуальная модель библиотеки YANG показана на рисунке 1. В соответствии с NMDA каждое хранилище имеет связанную с ним схему, являющуюся объединением наборов модулей, а каждый набор — это коллекция модулей и субмодулей, включая модули и субмодули, служащие для импорта. Отметим, что одна схема может применяться несколькими хранилищами. Кроме того, отдельные схемы хранилищ могут совместно использовать наборы модулей. Общим примером служит хранилище рабочего состояния, которое является надмножеством схемы, применяемой традиционными хранилищами конфигурации.

Ниже приведена диаграмма дерева YANG для модуля ietf-yang-library без устаревшего дерева /modules-state.

   module: ietf-yang-library
     +--ro yang-library
        +--ro module-set* [name]
        |  +--ro name                  string
        |  +--ro module* [name]
        |  |  +--ro name         yang:yang-identifier
        |  |  +--ro revision?    revision-identifier
        |  |  +--ro namespace    inet:uri
        |  |  +--ro location*    inet:uri
        |  |  +--ro submodule* [name]
        |  |  |  +--ro name        yang:yang-identifier
        |  |  |  +--ro revision?   revision-identifier
        |  |  |  +--ro location*   inet:uri
        |  |  +--ro feature*     yang:yang-identifier
        |  |  +--ro deviation*   -> ../../module/name
        |  +--ro import-only-module* [name revision]
        |     +--ro name         yang:yang-identifier
        |     +--ro revision     union
        |     +--ro namespace    inet:uri
        |     +--ro location*    inet:uri
        |     +--ro submodule* [name]
        |        +--ro name        yang:yang-identifier
        |        +--ro revision?   revision-identifier
        |        +--ro location*   inet:uri
        +--ro schema* [name]
        |  +--ro name          string
        |  +--ro module-set*   -> ../../module-set/name
        +--ro datastore* [name]
        |  +--ro name      ds:datastore-ref
        |  +--ro schema    -> ../../schema/name
        +--ro content-id    string
     notifications:
       +---n yang-library-update
          +--ro content-id    -> /yang-library/content-id

Контейнер /yang-library содержит всю библиотеку YANG и имеет перечисленные ниже дочерние узлы.

• /yang-library/module-set содержит записи, представляющие наборы модулей. Список /yang-library/module-set/module перечисляет все модули, относящиеся к набору. Модуль указывается вместе с субмодулями (если они имеются), набором функций и всеми отклонениями. Список /yang-library/module-set/import-only-module содержит все модули (и их субмодули), используемые лишь для импорта. Назначение модуля в набор определяется сервером. Данный выпуск библиотеки YANG не задаёт семантики включения модуля в список набора.

• Список /yang-library/schema содержит записи для каждой схемы хранилища, поддерживаемой сервером. Все традиционные хранилища данных используют общую запись списка schema. Динамическое хранилище конфигурации может использовать другую схему и для него может потребоваться отдельная запись в списке schema. Запись имеет лист-список (leaf-list) ссылок на записи в списке module-set. Схема является объединением всех модулей во всех указанных наборах.

• Список /yang-library/datastore содержит одну запись для каждого хранилища, поддерживаемого сервером, и указывает связанную с хранилищем схему путём ссылки на запись списка schema. Каждое поддерживаемое традиционное хранилище имеет свою запись, указывающую на общий элемент списка schema.

• Лист /yang-library/content-id содержит идентификатор содержимого библиотеки YANG, зависящий от реализации, который представляет текущие данные в библиотеке YANG на конкретном сервере. Значение этого листа должно меняться при любом изменении информации в библиотеке YANG. Не требуется совпадение content-id для одной и той же информации. Этот лист позволяет клиентам извлекать сразу всю информацию схемы, кэшировать ее и запрашивать снова лишь при изменении листа. Если этот лист меняется, сервер также генерирует уведомление yang-library-update.

Отметим, что для серверов NETCONF, реализующих расширения NETCONF для поддержки NMDA [RFC8526], изменение идентификатора содержимого библиотеки YANG приводит к новому значению возможности :yang-library:1.1, определённой в [RFC8526]. Если такой сервер реализует уведомления NETCONF [RFC5277] и генерируются уведомления netconf-capability-change [RFC6470], такие уведомления будут создаваться при каждой смене идентификатора содержимого библиотеки YANG.

4. Модуль библиотеки YANG

Модуль YANG ietf-yang-library импортирует определения из модулей ietf-yang-types и ietf-inet-types, определённых в [RFC6991], а также из модуля ietf-datastores, определённого в [RFC8342]. Хотя модуль YANG определён с использованием YANG версии 1.1, библиотека YANG поддерживает модули YANG для любой версии языка YANG.

   <CODE BEGINS> file "ietf-yang-library@2019-01-04.yang"

   module ietf-yang-library {
     yang-version 1.1;
     namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library";
     prefix yanglib;

     import ietf-yang-types {
       prefix yang;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-inet-types {
       prefix inet;
       reference
         "RFC 6991: Common YANG Data Types";
     }
     import ietf-datastores {
       prefix ds;
       reference
         "RFC 8342: Network Management Datastore Architecture
                    (NMDA)";
     }

     organization
       "IETF NETCONF (Network Configuration) Working Group";
     contact
       "WG Web:   <https://datatracker.ietf.org/wg/netconf/> 
        WG List:  <mailto:netconf@ietf.org> 

        Author:   Andy Bierman
                  <mailto:andy@yumaworks.com> 

        Author:   Martin Bjorklund
                  <mailto:mbj@tail-f.com> 

        Author:   Juergen Schoenwaelder
                  <mailto:j.schoenwaelder@jacobs-university.de> 

        Author:   Kent Watsen
                  <mailto:kent+ietf@watsen.net> 

        Author:   Robert Wilton
                  <mailto:rwilton@cisco.com>"; 
     description
       "Этот модуль содержит информацию о модулях YANG, хранилищах и
        схемах хранилищ, используемых сервером сетевого управления.

        Ключевые слова ДОЛЖНО, НЕДОПУСТИМО, ТРЕБУЕТСЯ, НУЖНО, НЕ СЛЕДУЕТ, 
        СЛЕДУЕТ, НЕ НУЖНО, РЕКОМЕНДУЕТСЯ, НЕ РЕКОМЕНДУЕТСЯ, МОЖНО и
        НЕОБЯЗАТЕЛЬНО в этом документе интерпретируются в соответствии с
        BCP 14 (RFC 2119) (RFC 8174) тогда и только тогда, когда они
        указаны заглавными буквами, как показано здесь.

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

        Распространение и использование в исходной или двоичной форме
        с изменениями или без таковых разрешено в соответствии с 
        упрощённой лицензией BSD, как указано в параграфе 4.c
        документа IETF Trust Legal Provisions применительно к 
        документам IETF (https://trustee.ietf.org/license-info). 

        Данная версия модуля YANG является частью RFC 8525, где
        правовые аспекты изложены более полно.";

     revision 2019-01-04 {
       description
         "Добавлена поддержка хранилищ данных с архитектурой NMDA.";
       reference
         "RFC 8525: YANG Library";
     }
     revision 2016-04-09 {
       description
         "Исходный выпуск.";
       reference
         "RFC 7895: YANG Module Library";
     }

     /*
      * Определения типов
      */

     typedef revision-identifier {
       type string {
         pattern '\d{4}-\d{2}-\d{2}';
       }
       description
         "Представляет дату в формате ГГГГ-ММ-ЧЧ format.";
     }

     /*
      * Группировки
      */

     grouping module-identification-leafs {
       description
         "Параметры для идентификации модулей и субмодулей YANG.";
       leaf name {
         type yang:yang-identifier;
         mandatory true;
         description
           "Имя модуля или субмодуля YANG.";
       }
       leaf revision {
         type revision-identifier;
         description
           "Дата выпуска модуля или субмодуля YANG. Если оператора revision
            нет в модуле или субмодуле YANG, этот лист не создаётся.";
       }
     }

     grouping location-leaf-list {
       description
         "Общий параметр leaf-list для местоположения модулей и субмодулей.";
       leaf-list location {
         type inet:uri;
         description
           "Содержит идентификатор URL, представляющий ресурс схемы YANG 
            для модуля или субмодуля.

            Этот лист присутствует лишь при наличии URL для извлечения
            схемы для данной записи.";
       }
     }

     grouping module-implementation-parameters {
       description
         "Параметры для описания реализации модуля.";
       leaf-list feature {
         type yang:yang-identifier;
         description
           "Список имён всех возможностей YANG из данного модуля, 
            поддерживаемых сервером, независимо от их определения
            в модуле или включённом в него субмодуле.";
       }
       leaf-list deviation {
         type leafref {
           path "../../module/name";
         }
         description
           "Список всем модулей отклонения YANG, используемых сервером,
            для изменения соответствия модуля, связанного с этой записью.
            Отметим, что один и тот же модуль может служить для отклонений
            разных модулей, поэтому одна запись МОЖЕТ присутствовать в 
            нескольких записях module.

            Этой ссылке НЕДОПУСТИМО указывать (напрямую или косвенно)
            модуль без отклонений (deviation).

            Отказоустойчивые клиенты могут захотеть проверить обработку
            ситуаций, где модуль имеет отклонения (напрямую или косвенно).";
       }
     }

     grouping module-set-parameters {
       description
         "Набор параметров, описывающих набор модулей.";
       leaf name {
         type string;
         description
           "Произвольное имя набора модулей.";
       }
       list module {
         key "name";
         description
           "Запись этого списка представляет модуль, реализованный сервером,
            как описано в параграфе 5.6.5 RFC 7950, с конкретным набором
            поддерживаемых возможностей и отклонений.";
         reference
           "RFC 7950: The YANG 1.1 Data Modeling Language";
         uses module-identification-leafs;
         leaf namespace {
           type inet:uri;
           mandatory true;
           description
             "Идентификатор пространства имён XML для этого модуля.";
         }
         uses location-leaf-list;
         list submodule {
           key "name";
           description
             "Каждая запись представляет один субмодуль в родительском
              модуле.";
           uses module-identification-leafs;
           uses location-leaf-list;
         }
         uses module-implementation-parameters;
       }
       list import-only-module {
         key "name revision";
         description
           "Запись этого списка указывает, что сервер импортирует 
            многократно используемые определения из указанного выпуска
            модуля, но не реализует из этого выпуска каких-либо
            доступных протоколу объектов.

            Для одного модуля МОЖЕТ присутствовать множество записей. 
            Это может быть обусловлено импортом множеством модулей одного
            модуля с указанием разных дат выпуска в операторах revision.";
         leaf name {
           type yang:yang-identifier;
           description
             "Имя модуля YANG.";
         }
         leaf revision {
           type union {
             type revision-identifier;
             type string {
               length "0";
             }
           }
           description
             "Дата выпуска модуля YANG. При отсутствии оператора
              revision в модуле YANG указывается пустая строка.";
         }
         leaf namespace {
           type inet:uri;
           mandatory true;
           description
             "Пространство имён XML для этого модуля.";
         }
         uses location-leaf-list;
         list submodule {
           key "name";
           description
             "Каждая запись представляет один субмодуль в родительском
              модуле.";
           uses module-identification-leafs;
           uses location-leaf-list;
         }
       }
     }
     grouping yang-library-parameters {
       description
         "Структура данных библиотеки YANG представлена как группировка,
          поэтому её можно повторно применять в конфигурации или иных 
          структурах данных мониторинга.";
       list module-set {
         key "name";
         description
           "Набор модулей, который может применяться в одной или 
            нескольких схемах.

            Набор модулей не обязан быть ссылочно полным, т. е он может
            определять модули, содержащие операторы import для модулей
            не включённых в этот набор.";
         uses module-set-parameters;
       }
       list schema {
         key "name";
         description
           "Схема хранилища, которая может применяться одним или
            несколькими хранилищами.

            Схема должна быть действительной и ссылочно полное, т. е.
            она должна включать модули для выполнения всех операторов 
            import во всех модулях, указанных в схеме.";
         leaf name {
           type string;
           description
             "Произвольное имя схемы.";
         }
         leaf-list module-set {
           type leafref {
             path "../../module-set/name";
           }
           description
             "Набор module-set, включённых в схему. Если неимпортируемый
              модуль присутствует в нескольких наборах модулей, выпуск
              модуля и связанные с ним возможности (функции) и 
              отклонения должны быть идентичны.";
         }
       }
       list datastore {
         key "name";
         description
           "Хранилище, поддерживаемое сервером.

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

            Сервер ДОЛЖЕН создавать в этом списке одну запись для 
            каждого поддерживаемого хранилища. Всем хранилищам с
            одной схемой СЛЕДУЕТ ссылаться на эту схему.";
         leaf name {
           type ds:datastore-ref;
           description
             "Отождествление хранилища данных.";
         }
         leaf schema {
           type leafref {
             path "../../schema/name";
           }
           mandatory true;
           description
             "Ссылка на схему, поддерживаемую хранилищем. Все 
              не импортируемые модули схемы реализуются со связанными
              возможностями и отклонениями.";
         }
       }
     }

     /*
      * Контейнер верхнего уровня
      */

     container yang-library {
       config false;
       description
         "Контейнер, содержащий всю библиотеку YANG данного сервера.";
       uses yang-library-parameters;
       leaf content-id {
         type string;
         mandatory true;
         description
           "Созданный сервером идентификатор содержимого дерева
            /yang-library. Сервер ДОЛЖЕН менять значение этого листа, 
            если представленная в дереве /yang-library информация
            меняется (за исключением смены /yang-library/content-id).";
       }
     }

     /*
      * Уведомления
      */

     notification yang-library-update {
       description
         "Генерируется при любом изменении информации в библиотеке YANG
          на сервере.";
       leaf content-id {
         type leafref {
           path "/yanglib:yang-library/yanglib:content-id";
         }
         mandatory true;
         description
           "Включает идентификатор содержимого библиотеки YANG для
            обновлённого варианта на момент создания уведомления.";
       }
     }

     /*
      * Унаследованные группировки
      */

     grouping module-list {
       status deprecated;
       description
         "Структура данных модуля представлена в форме группировки и
          может многократно применяться в конфигурации или другой
          структуре данных мониторинга.";

       grouping common-leafs {
         status deprecated;
         description
           "Общие параметры модулей и субмодулей YANG.";
         leaf name {
           type yang:yang-identifier;
           status deprecated;
           description
             "Имя модуля или субмодуля YANG.";
         }
         leaf revision {
           type union {
             type revision-identifier;
             type string {
               length "0";
             }
           }
           status deprecated;
           description
             "Дата выпуска модуля или субмодуля YANG. Если оператора
              revision нет в модулей или субмодуле, строка будет пустой.";
         }
       }

       grouping schema-leaf {
         status deprecated;
         description
           "Базовый параметр листа схему для модулей и субмодулей.";
         leaf schema {
           type inet:uri;
           description
             "Содержит идентификатор URL, представляющий ресурс схемы YANG
              для модуля или субмодуля.

              Этот лист присутствует лишь при наличии URL, доступного для
              извлечения схемы для данной записи.";
         }
       }
       list module {
         key "name revision";
         status deprecated;
         description
           "Каждая запись представляет один выпуск модуля, поддерживаемый
            в данный момент сервером.";
         uses common-leafs {
           status deprecated;
         }
         uses schema-leaf {
           status deprecated;
         }
         leaf namespace {
           type inet:uri;
           mandatory true;
           status deprecated;
           description
             "Идентификатор пространства имён XML для этого модуля.";
         }
         leaf-list feature {
           type yang:yang-identifier;
           status deprecated;
           description
             "Список имён свойств YANG из данного модуля, которые 
              поддерживаются сервером, независимо от их определения
              в модуле или любом из включённых субмодулей.";
         }
         list deviation {
           key "name revision";
           status deprecated;
           description
             "Список имён отклонений модулей YANG и выпусков, 
              используемых этим сервером для изменения соответствия
              модуля, связанного с этой записью. Отметим, что один
              и тот же модуль может использоваться для указания 
              отклонений множества модулей, поэтому запись МОЖЕТ
              появляться во множестве записей module.

              Модуль отклонений ДОЛЖЕН присутствовать в списке
              module с тем же именем и выпуском. Значением 
              conformance-type для модуля deviation будет implement.";
           uses common-leafs {
             status deprecated;
           }
         }
         leaf conformance-type {
           type enumeration {
             enum implement {
               description
                 "Показывает, что сервер реализует один или множество 
                  доступных протоколу объектов, определённых в модуле 
                  YANG, указанном этой записью. Это включает операторы 
                  deviation, определённые в модуле.

                  Для модулей YANG версии 1.1 имеется не более одной
                  записи с типом соответствия implement для конкретного
                  имени модуля, поскольку YANG 1.1 требует реализации
                  не более одного выпуска модуля.

                  Для модулей YANG версии 1 НЕ СЛЕДУЕТ включать более
                  одной записи module для конкретного имени модуля.";
             }
             enum import {
               description
                 "Показывает, что сервер импортирует повторно используемые
                  определения из указанного выпуска модуля, но не реализует
                  каких-либо доступных протоколу объектов из этого выпуска.

                  МОЖЕТ существовать множество записей module для одного 
                  имени модуля. Это может возникать в случаях импорта одного
                  модуля множеством других модулей с разными датами выпуска 
                  в операторах import.";
             }
           }
           mandatory true;
           status deprecated;
           description
             "Указывает тип соответствия, заявленного сервером для модуля 
              YANG, указанного этой записью.";
         }
         list submodule {
           key "name revision";
           status deprecated;
           description
             "Каждая запись представляет 1 субмодуль в родительском модуле.";
           uses common-leafs {
             status deprecated;
           }
           uses schema-leaf {
             status deprecated;
           }
         }
       }
     }

     /*
      * Унаследованные узлы данных рабочего состояния
      */

     container modules-state {
       config false;
       status deprecated;
       description
         "Содержит информацию мониторинга модуля YANG.";
       leaf module-set-id {
         type string;
         mandatory true;
         status deprecated;
         description
           "Содержит специфический для сервера идентификатор, который
            представляет текущий набор модулей и субмодулей. Сервер
            ДОЛЖЕН менять значение этого листа при изменении данных,
            представленных экземплярами списков module.";
       }
       uses module-list {
         status deprecated;
       }
     }

     /*
      * Унаследованные уведомления
      */

     notification yang-library-change {
       status deprecated;
       description
         "Генерируется при изменении набора модулей и субмодулей,
          поддерживаемых сервером.";
       leaf module-set-id {
         type leafref {
           path "/yanglib:modules-state/yanglib:module-set-id";
         }
         mandatory true;
         status deprecated;
         description
           "Содержит значение module-set-id, которое представляет
            набор модулей и субмодулей, которые сервер поддерживал в
            момент генерации уведомления.";
       }
     }
   }
   <CODE ENDS>

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

RFC 7895 ранее зарегистрировал один идентификатор URI в реестре IETF XML Registry [RFC3688]. Данный документ перенимает эту запись RFC 7895 и меняет значение Registrant Contact на IESG в соответствии с разделом 4 [RFC3688].

     URI: urn:ietf:params:xml:ns:yang:ietf-yang-library
     Registrant Contact: The IESG.
     XML: N/A, запрошенный URI является пространством имён XML.

Данный документ регистрирует модуль YANG в реестре YANG Module Names [RFC6020]

     name:         ietf-yang-library
     namespace:    urn:ietf:params:xml:ns:yang:ietf-yang-library
     prefix:       yanglib
     reference:    RFC 8525

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

Модуль YANG, заданный в этом документе, определяет схему данных, предназначенных для доступа с использованием протоколов сетевого управления, таких как NETCONF [RFC6241] или RESTCONF [RFC8040]. Нижним уровнем NETCONF является защищённый транспорт с обязательной реализацией протокола SSH⁵ [RFC6242]. Нижним уровнем RESTCONF является HTTPS с обязательной реализацией защищённого транспорта TLS [RFC8446].

Модель NACM⁶ [RFC8341] обеспечивает способы ограничения доступа для конкретных пользователей NETCONF или RESTCONF предопределенным подмножеством протокольных операций NETCONF или RESTCONF и содержимого .

Некоторые из доступных для чтения узлов данных этого модуля YANG могут оказаться чувствительными или уязвимыми в отдельных сетевых средах. Поэтому важно ограничить возможность чтения (например, с помощью get, get-config или notification) таких данных. Ниже указаны деликатные/уязвимые субдеревья и узлы данных.

Ветвь /yang-library библиотеки YANG может помочь атакующему при определении возможностей сервера и известных ошибок реализации. Хотя часть этих сведений доступна всем пользователям через сообщения NETCONF <hello> (или похожие сообщения других протоколов управления), этот модуль YANG может раскрывать дополнительные детали, способные помочь атакующему. Уязвимости сервера могут относиться к конкретным модулям, версиям возможностям или отклонениям. Эта информация включается в каждую запись module. Например, если конкретная операция с определенным узлом данных может приводить к аварии на сервере или значительно снижать его производительность, информация из списка модулей будет помогать атакующему обнаружить серверы с таким дефектом для организации атаки на службы.

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

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

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

[RFC3688] Mealling, M., «The IETF XML Registry», BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.

[RFC6020] Bjorklund, M., Ed., «YANG — A Data Modeling Language for the Network Configuration Protocol (NETCONF)», RFC 6020, DOI 10.17487/RFC6020, October 2010, <https://www.rfc-editor.org/info/rfc6020>.

[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., «Network Configuration Protocol (NETCONF)», RFC 6241, DOI 10.17487/RFC6241, June 2011, <https://www.rfc-editor.org/info/rfc6241>.

[RFC6242] Wasserman, M., «Using the NETCONF Protocol over Secure Shell (SSH)», RFC 6242, DOI 10.17487/RFC6242, June 2011, <https://www.rfc-editor.org/info/rfc6242>.

[RFC6991] Schoenwaelder, J., Ed., «Common YANG Data Types», RFC 6991, DOI 10.17487/RFC6991, July 2013, <https://www.rfc-editor.org/info/rfc6991>.

[RFC7950] Bjorklund, M., Ed., «The YANG 1.1 Data Modeling Language», RFC 7950, DOI 10.17487/RFC7950, August 2016, <https://www.rfc-editor.org/info/rfc7950>.

[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, «RESTCONF Protocol», RFC 8040, DOI 10.17487/RFC8040, January 2017, <https://www.rfc-editor.org/info/rfc8040>.

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

[RFC8341] Bierman, A. and M. Bjorklund, «Network Configuration Access Control Model», STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, <https://www.rfc-editor.org/info/rfc8341>.

[RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «Network Management Datastore Architecture (NMDA)», RFC 8342, DOI 10.17487/RFC8342, March 2018, <https://www.rfc-editor.org/info/rfc8342>.

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

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

[RFC5277] Chisholm, S. and H. Trevino, «NETCONF Event Notifications», RFC 5277, DOI 10.17487/RFC5277, July 2008, <https://www.rfc-editor.org/info/rfc5277>.

[RFC6470] Bierman, A., «Network Configuration Protocol (NETCONF) Base Notifications», RFC 6470, DOI 10.17487/RFC6470, February 2012, <https://www.rfc-editor.org/info/rfc6470>.

[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, «YANG Module Library», RFC 7895, DOI 10.17487/RFC7895, June 2016, <https://www.rfc-editor.org/info/rfc7895>.

[RFC8340] Bjorklund, M. and L. Berger, Ed., «YANG Tree Diagrams», BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, <https://www.rfc-editor.org/info/rfc8340>.

[RFC8343] Bjorklund, M., «A YANG Data Model for Interface Management», RFC 8343, DOI 10.17487/RFC8343, March 2018, <https://www.rfc-editor.org/info/rfc8343>.

[RFC8344] Bjorklund, M., «A YANG Data Model for IP Management», RFC 8344, DOI 10.17487/RFC8344, March 2018, <https://www.rfc-editor.org/info/rfc8344>.

[RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, «A YANG Data Model for Network Topologies», RFC 8345, DOI 10.17487/RFC8345, March 2018, <https://www.rfc-editor.org/info/rfc8345>.

[RFC8348] Bierman, A., Bjorklund, M., Dong, J., and D. Romascanu, «A YANG Data Model for Hardware Management», RFC 8348, DOI 10.17487/RFC8348, March 2018, <https://www.rfc-editor.org/info/rfc8348>.

[RFC8349] Lhotka, L., Lindem, A., and Y. Qu, «A YANG Data Model for Routing Management (NMDA Version)», RFC 8349, DOI 10.17487/RFC8349, March 2018, <https://www.rfc-editor.org/info/rfc8349>.

[RFC8526] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, «NETCONF Extensions to Support the Network Management Datastore Architecture», RFC 8526, DOI 10.17487/RFC8526, March 2019, <https://www.rfc-editor.org/info/rfc8526>.

[RFC8528] Bjorklund, M. and L. Lhotka, «YANG Schema Mount», RFC 8528, DOI 10.17487/RFC8528, March 2019, <https://www.rfc-editor.org/info/rfc8528>.

Приложение A. Отличия от RFC 7895

Ниже перечислены изменения [RFC7895] внесённые этим документом.

• Название YANG Module Library заменено на YANG Library.

• Добавлен контейнер верхнего уровня /yang-library, включающий всю библиотеку YANG и обеспечивающий информацию о наборах модулей, схемах и хранилищах данных.

• Контейнер /modules-state переработан в список /yang-library/module-set.

• Добавлены списки /yang-library/schema и /yang-library/datastore.

• Добавлены новые группировки взамен признанных устаревшими.

• Добавлено уведомление yang-library-update взамен устаревшего yang-library-change.

• Отменено дерево /modules-state.

• Отменена группировка /module-list.

• Отменено уведомление /yang-library-change.

Приложение B. Экземпляр библиотеки YANG для базового сервера

Приведённый ниже пример показывает библиотеку YANG базового сервера, реализующего модули ietf-interfaces [RFC8343] и ietf-ip [RFC8344] в хранилищах <running>, <startup> и <operational>, а также модуль ietf-hardware [RFC8348] в хранилище <operational>.

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

   <yang-library
       xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
       xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">

     <module-set>
       <name>config-modules</name>
       <module>
         <name>ietf-interfaces</name>
         <revision>2018-02-20</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-interfaces
         </namespace>
       </module>
       <module>
         <name>ietf-ip</name>
         <revision>2018-02-22</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-ip
         </namespace>
       </module>
       <import-only-module>
         <name>ietf-yang-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-yang-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>ietf-inet-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-inet-types
         </namespace>
       </import-only-module>
     </module-set>

     <module-set>
       <name>state-modules</name>
       <module>
         <name>ietf-hardware</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-hardware
         </namespace>
       </module>
       <import-only-module>
         <name>ietf-inet-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-inet-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>ietf-yang-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-yang-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>iana-hardware</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:iana-hardware
         </namespace>
       </import-only-module>
     </module-set>

     <schema>
       <name>config-schema</name>
       <module-set>config-modules</module-set>
     </schema>
     <schema>
       <name>state-schema</name>
       <module-set>config-modules</module-set>
       <module-set>state-modules</module-set>
     </schema>

     <datastore>
       <name>ds:startup</name>
       <schema>config-schema</schema>
     </datastore>
     <datastore>
       <name>ds:running</name>
       <schema>config-schema</schema>
     </datastore>
     <datastore>
       <name>ds:operational</name>
       <schema>state-schema</schema>
     </datastore>

     <content-id>75a43df9bd56b92aacc156a2958fbe12312fb285</content-id>
   </yang-library>

Приложение C. Экземпляр библиотеки YANG для расширенного сервера

Приведенный ниже пример расширяет библиотеку из приложения B за счёт использования модулей из [RFC8345] и [RFC8349] для иллюстрации сервера с перечисленными ниже дополнительными возможностями.

• Имеется модуль с возможностями, поддерживаемыми лишь в хранилище <operational>. Модуль ietf-routing поддерживается в <running>, <startup> и <operational>, а модули multiple-ribs и router-id разрешены лишь в <operational>. Поэтому лист router-id доступен для чтения, но не может быть изменён.

• Поддерживается динамическое хранилище конфигурации example-ds-ephemeral с модулями ietf-network и ietf-network-topology, настраиваемыми с помощью условного протокола динамического управления конфигурацией.

• Показан пример связанных с хранилищем отклонений. Модуль example-vendor-hardware-deviations включен в схему для хранилища <operational> с целью удаления узлов данных, которые сервер не может поддерживать.

• Показано применение наборов модулей (module-set) для совместной организации связанных модулей.

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

   <yang-library
       xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-library"
       xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores"
       xmlns:ex-ds-eph="urn:example:ds-ephemeral">

     <module-set>
       <name>config-state-modules</name>
       <module>
         <name>ietf-interfaces</name>
         <revision>2018-02-20</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-interfaces
         </namespace>
       </module>
       <module>
         <name>ietf-ip</name>
         <revision>2018-02-22</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-ip
         </namespace>
       </module>
       <module>
         <name>ietf-routing</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-routing
         </namespace>
       </module>
       <import-only-module>
         <name>ietf-yang-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-yang-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>ietf-inet-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-inet-types
         </namespace>
       </import-only-module>
     </module-set>

     <module-set>
       <name>config-only-modules</name>
       <module>
         <name>ietf-routing</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-routing
         </namespace>
       </module>
     </module-set>

     <module-set>
       <name>dynamic-config-state-modules</name>
       <module>
         <name>ietf-network</name>
         <revision>2018-02-26</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-network
         </namespace>
       </module>
       <module>
         <name>ietf-network-topology</name>
         <revision>2018-02-26</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-network-topology
         </namespace>
       </module>
       <import-only-module>
         <name>ietf-inet-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-inet-types
         </namespace>
       </import-only-module>
     </module-set>

     <module-set>
       <name>state-only-modules</name>
       <module>
         <name>ietf-hardware</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-hardware
         </namespace>
         <deviation>example-vendor-hardware-deviations</deviation>
       </module>
       <module>
         <name>ietf-routing</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-routing
         </namespace>
         <feature>multiple-ribs</feature>
         <feature>router-id</feature>
       </module>
       <module>
         <name>example-vendor-hardware-deviations</name>
         <revision>2018-01-31</revision>
         <namespace>
           urn:example:example-vendor-hardware-deviations
         </namespace>
       </module>
       <import-only-module>
         <name>ietf-inet-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-inet-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>ietf-yang-types</name>
         <revision>2013-07-15</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:ietf-yang-types
         </namespace>
       </import-only-module>
       <import-only-module>
         <name>iana-hardware</name>
         <revision>2018-03-13</revision>
         <namespace>
           urn:ietf:params:xml:ns:yang:iana-hardware
         </namespace>
       </import-only-module>
     </module-set>

     <schema>
       <name>config-schema</name>
       <module-set>config-state-modules</module-set>
       <module-set>config-only-modules</module-set>
     </schema>
     <schema>
       <name>dynamic-config-schema</name>
       <module-set>dynamic-config-state-modules</module-set>
     </schema>
     <schema>
       <name>state-schema</name>
       <module-set>config-state-modules</module-set>
       <module-set>dynamic-config-state-modules</module-set>
       <module-set>state-only-modules</module-set>
     </schema>

     <datastore>
       <name>ds:startup</name>
       <schema>config-schema</schema>
     </datastore>
     <datastore>
       <name>ds:running</name>
       <schema>config-schema</schema>
     </datastore>
     <datastore>
       <name>ex-ds-eph:ds-ephemeral</name>
       <schema>dynamic-config-schema</schema>
     </datastore>
     <datastore>
       <name>ds:operational</name>
       <schema>state-schema</schema>
     </datastore>

     <content-id>14782ab9bd56b92aacc156a2958fbe12312fb285</content-id>
   </yang-library>

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

Andy Bierman

YumaWorks

Email: andy@yumaworks.com

Martin Bjorklund

Tail-f Systems

Email: mbj@tail-f.com

Juergen Schoenwaelder

Jacobs University

Email: j.schoenwaelder@jacobs-university.de

Kent Watsen

Watsen Networks

Email: kent+ietf@watsen.net

Robert Wilton

Cisco Systems

Email: rwilton@cisco.com

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

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

nmalykh@protokols.ru

Отменен RFC 9499.

Internet Engineering Task Force (IETF)                        N. Khademi
Request for Comments: 8511                                      M. Welzl
Category: Experimental                                University of Oslo
ISSN: 2070-1721                                              G. Armitage
                                                                 Netflix
                                                            G. Fairhurst
                                                  University of Aberdeen
                                                           December 2018

TCP Alternative Backoff with ECN (ABE)

PDF

Аннотация

Механизмы активного управления очередями (Active Queue Management или AQM) обеспечивают устойчивость к всплескам (пикам) трафика при одновременном сохранении коротких очередей для минимизации времени пребывания пакетов в очередях узких мест сети. Проходящие через узкие места соединения TCP могут терять значительную часть производительности, особенно при наличии небольшого числа потоков или большом значении произведения пропускной способности и задержки (bandwidth-delay product или BDP). Получение маркера перегрузки (Congestion Experienced или CE) явного уведомления о перегрузке (Explicit Congestion Notification или ECN) указывает, что в узком месте применяется механизм AQM и сетевая очередь в этом месте вероятно будет короткой. Эти сигналы позволяют передающей стороне соединения TCP реагировать на ECN и для предотвращения перегрузки сокращать окно перегрузки (Congestion Window или cwnd) на меньшую величину, чем требует механизм контроля перегрузок для предполагаемой потери пакета. Данная спецификация задаёт экспериментальное изменение реакции TCP, заданной в RFC 3168, как это разрешает RFC 8311.

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

Документ не относится к категории Internet Standards Track и публикуется для проверки, экспериментальной реализации и оценки.

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

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

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

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

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

1. Введение

Явные уведомления о перегрузке (ECN) [RFC3168] позволяют механизму (AQM) информировать о начинающейся перегрузке без необходимости потери пакетов. Это позволяет сети доставлять приложению некоторые пакеты, которые были бы отброшены, если бы приложение или транспорт не поддерживали ECN. Это сокращение потерь пакетов является наиболее очевидным преимуществом ECN, но зачастую оно сравнительно мало. Другие преимущества от внедрения ECN документированы в [RFC8087].

Правила для ECN исходно были заданы как очень консервативные и требовали, чтобы алгоритмы контроля перегрузки транспорта с поддержкой ECN (ECN-Capable Transport или ECT) считали индикацию перегрузки через ECN эквивалентом потери пакета [RFC3168]. Исследования показали сокращение сетевых задержек, вызванных контролем перегрузки в TCP на основе потерь и избыточной буферизацией [BUFFERBLOAT]. Это привело к созданию механизмов AQM, таких как улучшенный пропорциональный интегральный контроллер (Proportional Integral Controller Enhanced или PIE) [RFC8033] и контроль задержки в очередях (Controlling Queue Delay или CoDel) [RFC8289], которые предотвращают раздувание очередей, характерное для неуправляемых и слишком больших буферов, развёрнутых в сети Internet [BUFFERBLOAT].

Отмеченные выше механизмы AQM нацелены на поддержку неизменно короткой очереди с допущением кратковременных всплесков пакетов. Однако применяемые в настоящее время механизмы контроля перегрузок на основе потерь не всегда обеспечивают эффективное использование узкого канала (bottleneck) при коротких очередях. Например, отправителю TCP с контролем перегрузок Reno требуется возможность сохранять данные по меньшей мере в объёме BDP в буфере узкого места для обеспечения полной загрузки пути в условиях вызванного потерями сокращения окна перегрузки (cwnd) [RFC5681]. Такой объём буферизации фактически удваивает размер находящихся в сети (in flight) данных и максимальное время кругового обхода (round-trip time или RTT) для отправителя TCP.

Современные механизмы AQM могут использовать ECN для сигнализации о первых признаках надвигающегося заполнения очереди задолго до вынужденного отбрасывания пакетов. Поэтому для алгоритма контроля перегрузок в транспортном протоколе разумно применять более взвешенный отклик на ранние предупреждения о перегрузке после получения удалённой точкой пакета с маркером ECN CE. С учётом этих изменений в современной практике AQM строгое требование обработки сигналов ECN CE как предполагаемой потери пакетов было смягчено в [RFC8311]. Этот документ задаёт новый механизм отклика на сигналы контроля перегрузки передающей стороной, названный ABE (Alternative Backoff with ECN). ABE повышает среднюю пропускную способность TCP при использовании в маршрутизаторах буферов с AQM, которые разрешают лишь короткие очереди.

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

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

3. Спецификация

Эта спецификация меняет алгоритм контроля перегрузки поддерживающего ECN транспортного протокола TCP путём смены отклика отправителя TCP обратной связью от получателя TCP, указывающей приём им пакета с маркером CE, т. е. с установленным флагом ECN-Echo (задан в [RFC3168]) в соответствии с процессом, заданным в [RFC8311].

Отклик отправителя TCP в настоящее время задан в параграфе 6.1.2 спецификации ECN [RFC3168] и слегка обновлён в параграфе 4.1 [RFC8311].

Индикацию насыщения следует трактовать просто, как потерю в результате насыщения для TCP без поддержки ECN. Т. е. отправитель TCP снижает вдвое размер окна насыщения cwnd и уменьшает порог замедленного старта ssthresh, если не указано иное в Experimental RFC потока документов IETF.

В соответствии с RFC 8311 этот документ задаёт изменение для передающей стороны TCP, где при получении пакета с флагом ECN-Echo следует инициировать у источника TCP установку для порога замедленного старта (slow start threshold или ssthresh) значения 0,8 * FlightSize с нижней границей 2 * SMSS³, применяемой к результату. Как и в [RFC5681], отправитель TCP также снижает значение cwnd не более чем до нового значения ssthresh. В параграфе 6.1.2 RFC 3168 даны рекомендации по установке cwnd меньше 2 * SMSS.

3.1. Выбор коэффициента ABE Multiplier

ABE отвязывает реакцию отправителя TCP на предполагаемую потерю пакетов от индикации перегрузки сигналом ECN в фазе предотвращения перегрузки. Для этого ABE использует иной коэффициент масштабирования в уравнении 4 из параграфа 3.1 в [RFC5681]. В описании соответственно используются beta_{loss} и beta_{ecn} для указания факторов мультипликативного снижения, применяемого в ответ на предполагаемую потерю пакета и в ответ на указание получателем перегрузки с помощью ECN. Для соединений TCP без поддержки ECN применяется только beta_{loss}. Иными словами, отклик на предполагаемую потерю пакетов имеет вид

      ssthresh = max (FlightSize * beta_{loss}, 2 * SMSS)

а отклик на индикацию перегрузки сигналом ECN —

      ssthresh = max (FlightSize * beta_{ecn}, 2 * SMSS)

и

      cwnd = ssthresh

(для ssthresh == 2 * SMSS в параграфе 6.1.2 RFC 3168 даны рекомендации по установке cwnd меньше 2 * SMSS)

FlightSize — размер остающихся в сети данных, ограниченный сверху меньшим из значений cwnd отправителя и анонсированным получателем окном (rwnd) [RFC5681]. Большие значения beta_{loss} и beta_{ecn} означают менее энергичный отклик на любое отдельное событие отката (backoff).

Подходящий выбор значений beta_{loss} и beta_{ecn} обеспечивает баланс между загрузкой пути и опустошением очереди в узком месте. Более энергичное поведение (меньшие beta_*) ведёт к риску недогрузки пути, тогда как менее энергичный откат (большие beta_*) может приводить к более медленному опустошению очереди в узком месте.

В Internet уже несколько лет применяется по меньшей мере два разных значения beta_{loss} — стандартное 0,5 [RFC5681] и принятое в реализации Linux CUBIC [RFC8312] значение 0,7, начиная с ядра 2.6.25, выпущенного в 2008 г. ABE не меняет значений beta_{loss}, используемых текущими реализациями TCP.

Этот документ рекомендует значение beta_{ecn}=0,8, применяемое только для стандартного контроля перегрузок TCP [RFC5681]. Выбор beta_{ecn} позволяет настраивать отклик соединения TCP для снижения порогов маркировки AQM. Значение beta_{loss} характеризует отклик алгоритма контроля перегрузки на потерю пакетов, т. е. заполнение буфера (неизвестного размера). Для алгоритмов контроля перегрузок в TCP предлагаются различные значения beta_{loss}. Поэтому beta_{ecn}, скорей всего, является параметром, связанным с алгоритмом, а не постоянной, кратной значению beta_{loss} имеющегося алгоритма. Выбор параметра был изучен в ряде тестов (раздел IV в [ABE2017]) с NewReno и CUBIC через CoDel и PIE в вариантах с незначительным мультиплексированием. Результаты этих тестов показывают, что для соединений CUBIC подходит значение beta_{ecn} = 0.85 (сравн. с beta_{loss} = 0.7), а соединения NewReno показывают улучшения при beta_{ecn} от 0,7 до 0,85 (сравн. с beta_{loss} = 0.5).

4. Обсуждение

Большая часть технического обоснования ABE приведена в [ABE2017], где сочетаются эксперименты, теория и моделирование с NewReno [RFC5681] и CUBIC [RFC8312] для оценки производительности. Показано, что ABE обеспечивает значительный рост производительности в сценариях с незначительным мультиплексирования несколько одновременных потоков) без потери преимуществ сокращения задержки в результате внедрения CoDel или PIE. Повышения производительности достигается при реагировании на ECN-Echo для предотвращения перегрузки (когда ssthresh > cwnd) путём умножения cwnd и ssthresh на значение из диапазона [0,7, 0,85]. Применение ABE при cwnd не более ssthresh в настоящее время не рекомендуется, но его использование в этом сценарии может выиграть в результате дополнительного внимания, экспериментов и спецификации.

4.1. Обоснования применения ECN для изменения уровня отката

Механизмы AQM, такие как CoDel [RFC8289] и PIE [RFC8033], устанавливают целевую задержку в маршрутизаторах и применяют уведомления о перегрузке для ограничения задержки в очередях, с которыми сталкиваются пакеты, а не в ответ на надвигающееся или фактическое исчерпание буфера в узком месте. С текущими принятыми по умолчанию значениями целевой задержки CoDel и PIE эффективно эмулируют узкое место с короткой очередью (раздел II в [ABE2017]), одновременно допуская в очереди короткие всплески (пики) трафика. Это обеспечивает приемлемую производительность соединений TCP на путях с низким BDP или в сценариях с сильным мультиплексированием (много одновременных потоков). Однако при незначительном мультиплексировании на пути с большим BDP обычный откат (backoff) TCP ведёт к пропускам передачи пакетов и недогрузке пути.

Вместо отбрасывания пакетов механизму AQM разрешено помечать пакеты ECN-Capable маркером ECN CE. Получение отклика с маркером CE не только указывает перегрузку на сетевом пути, но и говорит о наличии в узком месте на пути механизма AQM. Таким образом, появление маркера CE скорей всего объясняется наличием узкого места с контролируемой короткой очередью. Реагирование на сигналы ECN о перегрузке, отличающееся от реакции на предполагаемую потерю пакетов, может обеспечить сокращение отката при коротких очередях. Использование ECN может обеспечивать и другие преимущества [RFC8087]. Идея разного реагирования на предполагаемую потерю пакетов и сигналы о перегрузке от ECN была высказана до этой спецификации, например, в предыдущем исследовании предлагалось использовать отклики ECN CE для смены поведения контроля перегрузок TCP путём увеличения коэффициента сокращения (окна) с сочетании с уменьшением коэффициента расширения [ICC2002]. Целью этой работы была организация AQM через узкие места (с использованием RED⁴) без обязательной настройки для эмуляции короткой очереди (текущее применение RED в качестве Internet AQM ограничено [RFC7567]).

4.2. Основанный на RTT отклик на указанную перегрузку

Эта спецификация применяется к использованию откликов ECN, как задано в [RFC3168], где определён отклик на индикацию перегрузки не чаше 1 раза за интервал кругового обхода. Поскольку ABE реагирует на указанную перегрузку 1 раз за RTT, механизм не реагирует на дополнительные потери в том же интервале RTT, так как отправитель ABE уже сократил окно перегрузки. Если перегрузка продолжается после такого сокращения, ABE продолжает уменьшать окно перегрузки в каждом следующем интервале RTT. Такое последовательное сокращение окна может защитить сеть от продолжительного отсутствия беспристрастности, когда алгоритмы AQM не поддерживают малое значение среднего размера очереди. Механизм не полагается на Accurate ECN [ACC-ECN-FEEDBACK].

Механизмы транспортного протокола, напротив, могут быть созданы для использования более частых и детальных откликов ECN (например, Accurate ECN [ACC-ECN-FEEDBACK]), что позволяет более часто корректировать скорость передачи. Примером такого подхода является Data Center TCP (DCTCP) [RFC8257].

5. Требования к внедрению ABE

Это обновление относится лишь к передающей стороне. Подобно другим изменениям в алгоритмах контроля перегрузки, оно не требует менять что-либо на приёмной стороне TCP или в сетевых устройствах. Обновление не требует вносить связанные с ABE изменения в маршрутизаторы или использовать отклики Accurate ECN [ACC-ECN-FEEDBACK] на приёмной стороне.

Если метод внедряется лишь у части отправителей, те могут получить некоторые преимущества, возможно, за счёт других потоков, не внедривших этот обновленный метод. Поскольку преимущества относятся лишь к пакетам с маркировкой ECN, а не индикаторам потери пакетов, узкое место с поддержкой ECN все равно будет отбрасывать пакеты, если отправитель TCP, применяющий ABE, будет слишком энергичным. Результат не будет отличаться от использования отправителем TCP лишь традиционного контроля перегрузок не основе потери пакетов.

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

6. Цели экспериментов с ABE

В [RFC3168] сказано, что отклик контроля перегрузки, следующий за индикацией ECN, совпадает с откликом на отбрасывание пакета. [RFC8311] обновляет эту спецификацию, разрешая системам поддерживать разное поведение в случаях индикации ECN и потери пакетов. Данная спецификация определяет такой эксперимент и имеет статус Experimental RFC. Авторы ожидают, что в будущем статус сменится на Standards-Track.

Целью эксперимента в Internet является получение опыта внедрения ABE и подтверждение приемлемой безопасности в сетях, использующих такой обновленный контроль перегрузок в TCP. Для оценки ABE в этом эксперименте нужна поддержка в маршрутизаторах AQM маркировки ECN для пакетов, содержащих код поддерживающего ECN транспорта (ECN-Capable Transport) — ECT(0) [RFC3168].

Результат эксперимента должен включать исследование влияния установки маркера ECN-CE и последующей потери в том же интервале RTT. В конце эксперимента результат будет сообщён рабочей группе TCPM или IESG.

Механизм ABE реализован как исправление (patch) для Linux и FreeBSD, предназначенное для исследований и экспериментов и доступное по ссылке <https://heim.ifi.uio.no/michawe/research/abe/>. Код будет применяться для получения результатов теста, представляемых в [ABE2017]. Код FreeBSD был внесён (commit) в основную ветвь ядра (mainline kernel) 9 марта 2018 г. [ABE-REVISION].

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

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

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

Описанный метод вносит изменение в транспорт лишь на стороне отправителя и не меняет обмен протокольными сообщениями, поэтому соображения безопасности для ECN [RFC3168] остаются применимыми.

Это изменение контроля перегрузок в TCP с помощью ECN обычно будет менять доступную производительность для потоков, проходящих через узкое место в сети (bottleneck). Это может приводить к получению некоторыми потоками большей доли пропускной способности. Похожая несправедливость распределения пропускной способности наблюдается и в других механизмах контроля перегрузок, применяемых в Internet долгие годы (например, CUBIC [RFC8312]). Несправедливость может возникать и в результате других факторов, включая интервал кругового обхода для потока. ABE применяется только при получении пакетов с маркировкой ECN, а не в результате потери пакетов. Поэтому использование ABE не может вызывать перегрузочный коллапс (congestion collapse).

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

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

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

[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, «The Addition of Explicit Congestion Notification (ECN) to IP», RFC 3168, DOI 10.17487/RFC3168, September 2001, <https://www.rfc-editor.org/info/rfc3168>.

[RFC5681] Allman, M., Paxson, V., and E. Blanton, «TCP Congestion Control», RFC 5681, DOI 10.17487/RFC5681, September 2009, <https://www.rfc-editor.org/info/rfc5681>.

[RFC7567] Baker, F., Ed. and G. Fairhurst, Ed., «IETF Recommendations Regarding Active Queue Management», BCP 197, RFC 7567, DOI 10.17487/RFC7567, July 2015, <https://www.rfc-editor.org/info/rfc7567>.

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

[RFC8257] Bensley, S., Thaler, D., Balasubramanian, P., Eggert, L., and G. Judd, «Data Center TCP (DCTCP): TCP Congestion Control for Data Centers», RFC 8257, DOI 10.17487/RFC8257, October 2017, <https://www.rfc-editor.org/info/rfc8257>.

[RFC8311] Black, D., «Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation», RFC 8311, DOI 10.17487/RFC8311, January 2018, <https://www.rfc-editor.org/info/rfc8311>.

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

[ABE-REVISION] Stewart, L., «ABE patch review in FreeBSD», Revision 331214, March 2018, <https://svnweb.freebsd.org/base?view=revision&revision=331214>.

[ABE2017] Khademi, N., Armitage, G., Welzl, M., Zander, S., Fairhurst, G., and D. Ros, «Alternative backoff: Achieving low latency and high throughput with ECN and AQM», IFIP Networking Conference and Workshops Stockholm, Sweden, DOI 10.23919/IFIPNetworking.2017.8264863, June 2017.

[ACC-ECN-FEEDBACK] Briscoe, B., Kuehlewind, M., and R. Scheffenegger, «More Accurate ECN Feedback in TCP», Work in Progress, draft-ietf-tcpm-accurate-ecn-07, July 2018.

[BUFFERBLOAT] Gettys, J. and K. Nichols, «Bufferbloat: Dark Buffers in the Internet», ACM Queue, Volume 9, Issue 11, DOI 10.1145/2063166.2071893, November 2011, <https://queue.acm.org/detail.cfm?id=2071893>.

[ICC2002] Kwon, M. and S. Fahmy, «TCP increase/decrease behavior with explicit congestion notification (ECN)», 2002 IEEE International Conference on Communications Conference Proceedings, ICC 2002, Cat. No.02CH37333, DOI 10.1109/ICC.2002.997262, May 2002, <http://dx.doi.org/10.1109/ICC.2002.997262>.

[RFC8033] Pan, R., Natarajan, P., Baker, F., and G. White, «Proportional Integral Controller Enhanced (PIE): A Lightweight Control Scheme to Address the Bufferbloat Problem», RFC 8033, DOI 10.17487/RFC8033, February 2017, <https://www.rfc-editor.org/info/rfc8033>.

[RFC8087] Fairhurst, G. and M. Welzl, «The Benefits of ping Explicit Congestion Notification (ECN)», RFC 8087, DOI 10.17487/RFC8087, March 2017, <https://www.rfc-editor.org/info/rfc8087>.

[RFC8289] Nichols, K., Jacobson, V., McGregor, A., Ed., and J. Iyengar, Ed., «Controlled Delay Active Queue Management», RFC 8289, DOI 10.17487/RFC8289, January 2018, <https://www.rfc-editor.org/info/rfc8289>.

[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, «CUBIC for Fast Long-Distance Networks», RFC 8312, DOI 10.17487/RFC8312, February 2018, <https://www.rfc-editor.org/info/rfc8312>.

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

Работа N. Khademi, M. Welzl и G. Fairhurst частично финансировалась European Community в рамках Seventh Framework Programme по проекту Reducing Internet Transport Latency (RITE) (ICT-317700). Представленные здесь мнения принадлежат исключительно авторам.

G. Armitage выполнил большую часть работы над этим документом, будучи сотрудником Swinburne University of Technology, Melbourne, Australia.

Авторы благодарны Stuart Cheshire за многочисленные предложения при работе над документом. Спасибо за вклад в [ABE2017] Chamil Kulatunga, David Ros, Stein Gjessing, Sebastian Zander. Спасибо за отклики на документ David Black, Roland Bless, Bob Briscoe, Markku Kojo, John Leslie, Lawrence Stewart (в алфавитном порядке) и рабочей группе TCPM.

Авторы признательны всем членам исследовательской группы IRTF Internet Congestion Control (ICCRG), кто предоставил свои отклики на описанный в этом документе контроль перегрузок.

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

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

nmalykh@protokols.ru

Internet Engineering Task Force (IETF)                   P. Thubert, Ed.
Request for Comments: 8505                                         Cisco
Updates: 6775                                                E. Nordmark
Category: Standards Track                                         Zededa
ISSN: 2070-1721                                           S. Chakrabarti
                                                                 Verizon
                                                              C. Perkins
                                                               Futurewei
                                                           November 2018

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

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

PDF

Аннотация

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

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

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

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

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

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

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

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

1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

• IPv6 Stateless Address Autoconfiguration [RFC4862];

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

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

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

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

6BBR

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

6CIO

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

6LBR

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

6LN

6LoWPAN Node — узел 6LoWPAN.

6LoWPAN

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

6LR

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

ARO

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

DAC

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

DAD

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

DAR

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

DODAG

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

EARO

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

EDA

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

EDAC

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

EDAR

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

LLN

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

NA

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

NCE

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

ND

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

NS

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

RA

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

ROVR

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

RPL

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

RS

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

TID

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

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

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

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

Binding — привязка

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Поле EUI-64 переопределено и названо ROVR для включения разных типов информации, например, криптографических данных переменного размера (см. 5.3. Поле ROVR). Можно использовать ROVR большего размера, если совместимость с прежними версиями не требуется в сети LLN. Значение поля Length за вычетом 1 указывает размер поля ROVR в 8-байтовых словах. Более подробно это рассмотрено в параграфе 5.1. Расширение ARO. Формат опции EARO показан на рисунке 1.

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

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

Type

33

Length

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

Status

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

Opaque

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

Rsvd

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

I

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

R

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

T

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

TID

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

Registration Lifetime

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

Registration Ownership Verifier (ROVR)

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

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

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

Сообщения DAR и DAC используют общий базовый формат, определённый в параграфе 4.4 [RFC6775], и позволяют доставлять сведения из ARO через несколько интервалов пересылки. Расширенный формат DAR и DAC показан на рисунке 2.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |CodePfx|CodeSfx|          Checksum             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Status     |     TID       |     Registration Lifetime     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
...          Registration Ownership Verifier (ROVR)           ...
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
+                                                               +
|                                                               |
+                       Registered Address                      +
|                                                               |
+                                                               +
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

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

Code

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

TID

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

Registration Ownership Verifier (ROVR)

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

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

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

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

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

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

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

Рисунок 3. Новые биты возможностей в 6CIO.

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

Type

36

D

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

L

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

B

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

P

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

E

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.3. Поле ROVR

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.2. Поле ARO I

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

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

9.3. Коды ICMP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[IPv6-Backbone-Router] Thubert, P., Ed. and C. Perkins, «IPv6 Backbone Router», Work in Progress, draft-ietf-6lo-backbone-router-08⁸, October 2018.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Req-1.1

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

Req-1.2

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

Req-1.3

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

Req-1.4

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

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

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

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

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

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

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

Req-2.1

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

Req-2.2

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

Req-2.3

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

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

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

Req-3.1

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

Req-3.2

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

Req-3.3

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

Req-3.4

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

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

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

Req-4.1

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

Req-4.2

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

Req-4.3

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

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

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

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

Req-5.1

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

Req-5.2

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

Req-5.3

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

Req-5.4

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

Req-5.5

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

Req-5.6

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

Req-5.7

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

Req-5.8

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

Req-5.9

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

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

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

Req-6.1

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

Req-6.2

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

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

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

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

Req-7.1

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

Req-7.2

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

Req-7.3

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

Req-7.4

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

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

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

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

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

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

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

Cisco Systems, Inc.

Building D (Regus) 45 Allee des Ormes

Mougins — Sophia Antipolis

France

Phone: +33 4 97 23 26 34

Email: pthubert@cisco.com

Erik Nordmark

Zededa

Santa Clara, CA

United States of America

Email: nordmark@sonic.net

Samita Chakrabarti

Verizon

San Jose, CA

United States of America

Email: samitac.ietf@gmail.com

Charles E. Perkins

Futurewei

2330 Central Expressway

Santa Clara, CA 95050

United States of America

Email: charliep@computer.org

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

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

nmalykh@protokols.ru