RFC 8190 Updates to the Special-Purpose IP Address Registries

Internet Engineering Task Force (IETF)                         R. Bonica
Request for Comments: 8190                              Juniper Networks
BCP: 153                                                       M. Cotton
Updates: 6890                                                        PTI
Category: Best Current Practice                              B. Haberman
ISSN: 2070-1721                                 Johns Hopkins University
                                                               L. Vegoda
                                                                   ICANN
                                                               June 2017

Updates to the Special-Purpose IP Address Registries

Обновление реестров адресов IP специального назначения

PDF

Аннтация

Этот документ обновляет реестры IANA для адресов специального назначения IPv4 и IPv6 путем введения определения «глобального» префикса. Документ также исправляет некоторые ошибки в записях реестрой для обеспечения целостности реестрой IANA для адресов специального назначения.

Документ обновляет RFC 6890.

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

Этот документ относится к категории «Обмен опытом» (Internet Best Current Practice).

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

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

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

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

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

Оглавление

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

1. Введение

Для поддержки новых протоколов и практики IETF иногда резервирует блоки адресов специального назначения. Например, [RFC1122] резервирует блок адресов IPv4 (0.0.0.0/8) для представления местной (т. е. «данной») сети. Аналогично в [RFC4291] зарезервирован блок адресов IPv6 (fe80::/10) для представления индивидуальных адресов на канале.

Возникли некоторые вопросы с документированием отдельных блоков адресов специального назначения в [RFC6890]. В частности, определение global в [RFC6890] вводит в заблуждение, поскольку несколько отличается от общепринятого определения глобальной области действия (т. е. возможности пересылки за пределы административного домена, описанной как global unicast в архитектуре адресации [RFC4291]). Этот документ обновляет определение global, данное в [RFC6890] для реестров адресов специального назначения IPv4 и IPv6, дополняет поля реестров для устранения путацицы, связанной с определением global и исправляет некоторые ошибки в записях реестров адресов.

Документ обновляет [RFC6890].

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

2.1. Определение глобальной доступности

[RFC6890] определяет термин global без учета его применения в разных сферах. В частности, адрес IP может быть глобальным в смысле области действия, а также в смысле доступности и маршрутизации. Для устранения этой неоднозначности термин global, определенный в [RFC6890], заменен на globally reachable (глобально доступный). Ниже приведено определение, которое заменяет global в реестрах IANA для адресов специального назначения.

Globally Reachable — глобально доступный

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

В связи Destination с Forwardable и Global, описанной в [RFC6890], также указывается Globally Reachable. Если Destination = FALSE, значения Forwardable и Globally Reachable также должны быть FALSE.

Столбец Global в реестрах IPv4 Special-Purpose Address Registry (https://www.iana.org/assignments/iana-ipv4-special-registry) и IPv6 Special-Purpose Address Registry (https://www.iana.org/assignments/iana-ipv6-special-registry) переименован в Globally Reachable.

2.2. Обновление реестра IPv4 Special-Purpose Address Registry

  • Для Limited Broadcast prefix (255.255.255.255/32) значение Reserved-by-Protocol сменено на True. Это было сделано для согласования реестра с выделением адреса ограниченного широковещания в разделе 7 [RFC919].

2.3. Обновления реестра IPv6 Special-Purpose Address Registry

Указанные ниже изменения реестра IPv6 Special-Purpose Address Registry включают добавление двух примечаний, ведущее к изменению нумерации имеющихся примечаний.

  • Для префикса TEREDO (2001::/32) значение Globally Reachable было сменено с False на N/A [2]. Примечание [2] сейчас имеет вид:

    * See Section 5 of [RFC4380] for details3.

  • Для EID Space for LISP (2001:5::/32) номера всех примечаний увеличились на 1.

  • Для 6to4 (2002::/16) номера всех примечаний увеличились на 1.

  • Для Unique-Local (fc00::/7) значение Globally Reachable (False) было сменено на False [7]. Примечание [7] имеет вид:

    * See [RFC4193] for more details on the routability of Unique-Local addresses. The Unique-Local prefix is drawn from the IPv6 Global Unicast Address range but is specified as not globally routed.4

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

Этот документ не создает вопросов безопасности в дополнение к отмеченным в [RFC6890].

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

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

[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, «Special-Purpose IP Address Registries», BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.

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

[RFC919] Mogul, J., «Broadcasting Internet Datagrams«, STD 5, RFC 919, DOI 10.17487/RFC0919, October 1984, <http://www.rfc-editor.org/info/rfc919>.

[RFC1122] Braden, R., Ed., «Requirements for Internet Hosts — Communication Layers», STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <http://www.rfc-editor.org/info/rfc1122>.

[RFC4193] Hinden, R. and B. Haberman, «Unique Local IPv6 Unicast Addresses», RFC 4193, DOI 10.17487/RFC4193, October 2005, <http://www.rfc-editor.org/info/rfc4193>.

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

[RFC4380] Huitema, C., «Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)», RFC 4380, DOI 10.17487/RFC4380, February 2006, <http://www.rfc-editor.org/info/rfc4380>.

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

Brian Carpenter и C. M. Heard представили полезные замечания к черновому варианту документа. Daniel Migault провел углубленный обзор, который помог улучшить текст документа. Amanda Baber и Sabrina Tanamal задавали вопросы, которые помогли авторам упростить документ.

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

Ronald Bonica

Juniper Networks

Email: rbonica@juniper.net

Michelle Cotton

PTI, an affiliate of ICANN

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536

United States of America

Phone: +1-424-254-5300

Email: michelle.cotton@iana.org

Brian Haberman

Johns Hopkins University

Email: brian@innovationslab.net

Leo Vegoda

ICANN

Email: leo.vegoda@icann.org


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

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

nmalykh@protocols.ru

1Internet Engineering Task Force.

2Internet Engineering Steering Group.

3См. раздел 5 в [RFC4380].

4См. [RFC4193] для описания маршрутизируемости адресов Unique-Local. Префикс Unique-Local берется из диапазона IPv6 Global Unicast Address, но указан как не маршрутизируемый глобально.




RFC 8175 Dynamic Link Exchange Protocol (DLEP)

Internet Engineering Task Force (IETF)                        S. Ratliff
Request for Comments: 8175                                    VT iDirect
Category: Standards Track                                        S. Jury
ISSN: 2070-1721                                            Cisco Systems
                                                          D. Satterwhite
                                                                Broadcom
                                                               R. Taylor
                                                  Airbus Defence & Space
                                                                B. Berry
                                                               June 2017

Dynamic Link Exchange Protocol (DLEP)

Протокол DLEP

PDF

Аннотация

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

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

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

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

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

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

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

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

Оглавление

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

1. Введение

В настоящее время имеется множество модемных устройств, управляющих каналами с переменной скоростью и качеством. Примерами таких устройств являются наземные станции радиоканалов прямой видимости (LOS4), спутниковые терминалы и широкополосные модемы. Флуктуации скорости икачества этих каналов могут меняться из-за настроек или изменения физических условий, таких как интерференция отраженных сигналов, препятствия, затухание при дожде и т. п. Вполне возможна зависимость скорости и качества канала от конечной точки и типа передаваемого трафика. В качестве примера рассмотрим точку доступа IEEE 802.11, обслужива.щую два связанных переносных компьютера. В этой среде ответом скорость соединения 802.11 будет зависеть от используемых компьютеров и типа передаваемого трафика. Один из компьютеров, расположенный ближе к точке доступа, может иметь, например, скорость 54 Мбит/с для индивидуального (unicast) трафика, а расположенный дальше другой компьютре — всего лишь 32 Мбит/с для такого же трафика. Однако групповой трафик от точки доступа будет передаваться с базовой скоростью, которая настраивается, но обычно не превышает 24 Мбит/с.

Кроме каналов с переменной скоростью мобильные сети сталкиваются с проблемой подключения и отключения устройств, не влияющего на состояние интерфейса маршрутизатора (Up или Down). Эффективное использование сравнительно краткосрочного соединения является проблематичным в сетях с маршрутизацией IP, поскольку протоколы маршрутизации IP опираются на состояния интерфейсов и независимые таймеры для поддержки сходимости сети (например, сообщения HELLO и/или распознавание маршрутной смежности DEAD). Такие динамические соединения могут использоваться лучше в парадигме управления по событиям, где обретение нового соседа или потеря имеющегося ведет к сигналу, нежели в парадигме управления по таймерам и/или состоянию интерфейса. Протокол DLEP не только реализует парадигму управления по событиям, но и делает это на уровне локальной (1 интервал — hop) сессии TCP, что гарантирует доставку сообщений.

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

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

|-----Локальный узел-----|          |------Удаленный узел----|
|                        |          |                        |
+--------+       +-------+          +-------+       +--------+
|Маршрути|=======| Модем |{~~~~~~~~}| Модем |=======|Маршрути|
|  затор |       |       |          |       |       |  затор |
+--------+       +-------+          +-------+       +--------+
         |       |       | Канальный|       |       |
         |-DLEP--|       | протокол |       |-DLEP--|
         |       |       |(например,|       |       |
         |       |       | 802.11)  |       |       |

Рисунок 1. Сеть DLEP.

На рисунке 1 локальный модем при обнаружении наличия удаленного узла передает сообщение своему маршрутизатору по протоколу DLEP. Это сообщение содержит указание произошеждшего на канале изменения (например, появление или исчезновение узла) вместе с набором определенных DLEP эдементов данных (Data Item) с дополнительным описанием изменения. При получении этого сообщения локальный маршрутизатор может предпринять действие, которое он считает целесообразным, такое как запуск протоколов обнаружения и/или выдачу сообщений HELLO для схождения сети. Далее по мере необходимости модемы используют DLEP для информирования об изменении характеристик (скорость, задержка и т. п.) канала. Протокол DLEP не зависит от типа канала и поддерживаемой модемом топологии. Протокол предназначен для использования лишь на локальном канале между маршрутизатором и модемом. Может потребоваться та или иная сигнализация (over-the-air) между локальным и удаленным модемом для обеспечения некоторых параметров сообщений DLEP между локальным модемом и локальным маршрутизатором, но DLEP не задает способ такой сигнализации (определяется производителем модема).

На рисунке 2 показано, как DLEP может поддерживать конфигурацию при подключении маршрутизаторов по разнотипным каналам. В этом примере модемы типа A организуют соединение «точка-точка», а модемы типа B соединяются через общую среду. В обоих случаях используется протокол DLEP для информирования маршрутизаторов о характеристиках канала (скорость, задержка и т. п.). Модем также может использовать сессию DLEP для уведомления маршрутизатора о потере удаленного узла для сокращения времени схождения сети.

         +--------+                     +--------+
    +----+ Модем  |                     | Модем  +---+
    |    |  типа  |                     |  типа  |   |
    |    |    A   |  <===== // ======>  |    A   |   |
    |    +--------+ Канал «точка-точка» +--------+   |
+---+----+                                       +---+----+
|Маршрути|                                       |Маршрути|
|  затор |                                       |  затор |
+---+----+                                       +---+----+
    |     +--------+                     +--------+  |
    +-----+ Модем  |                     | Модем  |  |
          |  типа  |   o o o o o o o o   |  типа  +--+
          |    B   |    o   Общая   o    |    B   |
          +--------+     o  среда  o     +--------+
                          o       o
                           o     o
                            o   o
                              o
                         +--------+
                         | Модем  |
                         |  типа  |
                         |    B   |
                         +---+----+
                             |
                         +---+----+
                         |Маршрути|
                         |  затор |
                         +--------+

Рисунок 2. Сеть DLEP с несколькими модемами.

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

Протокол DLEP определяет набор сообщений, используемых модемами и подключенными к ним маршрутизаторами для обмена событиями, которые происходят на физических каналах, поддерживаемых модемом (например, подключение или отключение узла сети, изменение канала). С этими сообщениями связан набор элементом данных (Data Item), описывающих удаленный узел (например, информация об адресе) и/или характеристики канала к удаленному узлу. В этом документе модемы и маршрутизаторы, участвующие в сессии DLEP, называются участниками (DLEP Participant), если не требуется более конкретное указание (например, модем или маршрутизатор).

DLEP работает на основе сессий между модемом и связанным с ним маршрутизатором. При подключении к одному маршрутизатору множества модемов (Рисунок 2) или поддержке модемом множества соединений (через логические или физические интерфейсы) организуется сессия DLEP для каждого модема или соединения. Маршрутизатор и модем формируют сессию с помощью процесса обнаружения и инициализации. Сессия между модемом и маршрутизатором сохраняется, пока (1) не завершится время ожидания (таймаут) при отсутствии трафика DLEP (включая сообщения heartbeat) или (2) сессия не будет явно разорвана отдним из участников DLEP.

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

2.1. Получатели

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

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

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

Примером логического получателя является групповая адресация (Multicast). Групповой трафик для сети с изменяющимся качеством соединения (доступ через модем) обрабатывается в IP-сети путем выведения адресов L2 (MAC) из адресов L3. В такой схеме групповой трафик поддерживается протоколом DLEP просто трактовкой выведенных MAC-адресов, как любых других получателей в сети.

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

Во всех случаях использования термина destination (получатель, адресат) в данной спецификации это означает адресуемое место (логическое или физическое), доступное по радиоканалу (каналам).

2.2. Соглашения и терминология

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

3. Требования

Протокол DLEP должен разворачиваться в одном домене L2. Протокол указывает получателей следующего интервала (next-hop), используя MAC-адрес для доставки трафика данных. Каких-либо подстановок или манипуляций не происходит и MAC-адрес из сообщений DLEP используется в качестве Destination MAC в кадрах, передаваемых участвующим в протоколе маршрутизатором. MAC-адреса должны быть уникальными в контексте сессии модем-маршрутизатор.

Для ограничения работы одним доменом L2 реализации должны поддерживать механизм Generalized TTL Security Mechanism [RFC5082], а также должны следовать этой спецификации для всех сообщений DLEP.

DLEP задает групповой трафик UDP для сигнализации обнаружения в одном интервале (single-hop discovery) и TCP — для доставки сообщений. Модемы и маршрутизаторы, участвующие в сессии DLEP, должны иметь топологически согласованные адреса IP. Рекомендациям DLEP рекомендуется использовать адреса IPv6 link-local для снижения административных издержек, связанных с назначением адресов.

DLEP полагается на гарантированную доставку сообщений между модемом и маршрутизатором после завершений процесса обнаружения (1-hop discovery), поэтому для доставки сообщений выбран протокол TCP. Можно применять и другие протоколы с гарантией доставки, но это выходит за рамки данного документа.

4. Варианты развертывания

В процессе разработки спецификации рассматривались два типа развертывания.

Первый можно считать «выделенным развертыванием» В этом режиме маршрутизаторы и модемы DLEP соединены напрямую (например, кросс-кабелями) или подключены к выделенному коммутатору. Примером может служить маршрутизатор со подключенной к одному интерфейсу станцией LOS и спутниковым модемом на другом интерфейсе. В мобильной среде маршрутизатор и подключенные модемы размещаются на мобильной платформк (автомобиль, корабль, самолет). В этом режиме при использовании коммутатора к нему может также подключаться небольшое число вспомогательный устройств (например, переносной компьютер). Однако в любом случае сегмент сети ограничен малым числом устройств и, как правило, не доступен извне.

Другой вариант можно считать «сетевым развертыванием». В этом случае маршрутизатор и модемы DLEP размещаются в доступном извне сегменте сети. Здесь между маршрутизатором и конкретным модемом DLEP может быть несколько физических узлов пересылки. В этом варианте требуется использовать туннель L2 для выполнения требования DLEP в части 1 этапа пересылки (single-hop).

5. Допущения

DLEP предполагает наличие протокола сигнализации между модемами, участвующими в работе. Данная спецификация не задает поведение этой беспроводной (over-the-air) сигнализации, но предполагает передачу (возможность вывода) некой информации, такой как подключение и отключение модемов, а также вариации харакетристик канала между модемами. Предполагается, что эти данные модем использует для реализации DLEP.

Спецификация предполагает, что соединение между модемом и маршрутизатором является статическим в плане скоорости и задержки, а также не вносит задержки, способной создавать «пробку». В системах, где между модемом и маршрутизатором имеется множество физических интервалов пересылки и применяется туннель L2, статистики DLEP для радио-каналов (RF) может оказаться недостаточно для принятия корректного решения о маршрутизации. Это особенно важно в тех случаях, когда туннель L2 между модемом и маршрутизатором включает беспроводные каналы.

6. Параметры метрики

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

DLEP позволяет передавать метрику в двух контекстах — для конкретного получателя в сети (например, определенного маршрутизатора) и «на уровне сессии» (применительно ко всем адресатам, доступным через модем). Большинство показателей можно разделить на параметры передачи и приема. Когда метрика предоставляется на уровне сессии, маршрутизатор распространяет параметры на все записи в базе данных для получателей, доступных через модем.

Модем DLEP анонсирует все метрические элементы данных, о которых он будет сообщать в сессии, и указывает для параметров принятые по умолчанию значения в сообщенииSession Initialization Response (12.6. Отклик Session Initialization Response). Для использования типа метрики, не включенного в такое сообщение, модем прерывает сеанс с маршрутизатором сообщением Session Termination (12.9. Сообщение Session Termination) и начинает новую сессию.

Модем DLEP может в любое время передать метрику (1) в контексте сессии через сообщение Session Update (12.7. Сообщение Session Update) и (2) в контексте конкретного адресата — через Destination Update (12.17. Сообщение Destination Update). Более новые данные метрики имеют преимущество независимо от контекста передачи.

  1. Если метрика получена в контексте адресата (Destination Update), обновляются данные для получателя.

  2. Если метрика получена в контексте сессии (Session Update), обновляются параметры для всех получателей, подключенных через этот модем.

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

В дополнение к обмену метрическими данными каналов в DLEP поддерживаются сообщения, позволяющие маршрутизатору запросить у модема другую скорость или задержку. Это сообщения Link Characteristics Request (12.18. Запрос характеристик канала), которые дают маршрутизатору возможность более детерминированно справляться с ростом (снижением) запросов на выделение полосы и задержку.

7. Состояния сессии DLEP

Все участники сессии DLEP проходят через множество состояний в течение срока действия сессии DLEP:

  • обнаружения партнера (Peer Discovery);

  • инициализация сессии (Session Initialization);

  • работа сессии (In-Session);

  • прерывание сессии (Session Termination);

  • сброс сессии (Session Reset).

Модемы и маршрутизаторы, поддерживающие обнаружение DLEP, проходят через все перечисленные состояния. Маршрутизаторы, полагающиеся на заранее настроенные адрес и порт TCP, начинают с состояния Session Initialization.

Модемы должны поддерживать состояние Peer Discovery.

7.1. Состояние Peer Discovery

Модемы должны поддерживать состояние Peer Discovery, маршрутизаторы могут поддерживать сигналы обнаружения или полагаться на конфигурацию для нахождения модемов. Если маршрутизатор выбирает поддержку детектирования DLEP, он должен поддерживать все сигналы.

В состоянии Peer Discovery маршрутизатор, поддерживающие обнаружение DLEP, должен передавать Peer Discovery Signal (12.3. Сигнал Peer Discovery ) для инициирования процесса обнаружения модема.

После этого маршрутизатор ждет отклика Peer Offer (12.4. Сигнал Peer Offer ) от модема DLEP. В состоянии Peer Discovery сигналы Peer Discovery должны передаваться маршрутизатором DLEP периодически. Рекомендуется интервал 60 секунд. Интервал должен быть не меньше 1 секунды и следует делать его настраиваемым. Отметим, что эта операция (передача Peer Discovery и ожидание Peer Offer) не входит в модель транзакций DLEP (8. Модель транзакций), поскольку эта модель описывает лишь сообщения в сессии TCP.

Маршрутизатор, получивший сигнал Peer Offer, должен использовать одну из комбинаций адрес-порт в Peer Offer для организации соединения TCP с модемом даже при наличии заданной ранее конфигурации. При наличии нескольких Connection Point в полученной Peer Offer маршрутизатору следует предпочитать точки подключения IPv6 точкам IPv4. При наличии нескольких точек с одним протоколом (IPv6 или IPv4) реализация может использовать свю эвристику для выбора среди них. Если соединение TCP не удается организовать с любой из пар адрес-порт и механизм Discovery применяется, маршрутизатору следует возобновить передачу сигналов Peer Discovery. Если элементов Connection Point нет в сигнале Peer Offer, маршрутизатор должен использовать адрес отправителя из пакета UDP, содержащего Peer Offer, в качестве IP-адреса получателя и общеизвестный порт DLEP.

В состоянии Peer Discovery реализация модема должна слушать входящие сигналы Peer Discovery на общеизвестном порту DLEP группового локального адреса IPv6 и/или IPv4. При получении действительного сигнала Peer Discovery модем должен ответить сигналом Peer Offer.

Модемы должны быть готовы воспринять соединение TCP от маршрутизаторов, не использующих механизм Discovery, т. е. попытки соединения без предшествующего сигнала Peer Discovery.

Реализациям DLEP следует поддерживать и использовать протокол TLS7 [RFC5246] для защиты сессии TCP. «Выделенные развертывания» (4. Варианты развертывания) могут использовать DLEP без TLS. Для всех «сетевых развертываний» настоятельно рекомендуется поддерживать и использовать TLS. При использовании TLS сеанс протокола TLS должен быть организован до начала передачи каких-либо сообщений между партнерами. Маршрутизаторы, поддерживающие TLS, должны предпочитать точки соединения, использующие TLS.

После организации соединения TCP (и сессии TLS, если протокол используется), модем и маршрутизатор переходят в состояние Session Initialization. Продожение отправки сигналов Peer Discovery после перехода в состояние Session Initialization реализация выбирает самостоятельно. Реализации модемов должны игнорировать сигналы Peer Discovery от маршрутизатора, с которым уже организовано соединение TCP.

7.2. Состояние Session Initialization

При переходе в состояние Session Initialization маршрутизатор должен передать модему сообщение Session Initialization (12.5. Сообщение Session Initialization). затем маршрутизатор должен дождаться сообщения Session Initialization Response (12.6. Отклик Session Initialization Response) от модема. Прием Session Initialization Response с элементом данных (13.1. Данные состояния) Status, имеющим значение 0 ‘Success’ (таблица 2 в параграфе 13.1. Данные состояния), указывает, что модем получил и обработал сообщение Session Initialization и маршрутизатор должен перейти в состояние In-Session.

При переходе в состояние Session Initialization модем должен ждать от маршрутизатора сообщения Session Initialization. При получении Session Initialization модем должен передать сообщение Session Initialization Response, а затем должен перейти в состояние In-Session. При получении иного сообщения или отказе при анализе принятого Session Initialization модему недопустимо передавать какое-либо сообщение и он должен разорвать соединение TCP connection, а также перейти в состояние Session Reset.

DLEP поддерживает возможность согласования расширений в состоянии Session Initialization (9. Расширения). Поддерживаемые реализацией расширения должны быть объявлены возможным участникам DLEP с использованием элемента данных Extensions Supported (13.6. Extensions Supported). После обмена обоих участников DLEP инициализационными сообщениями реализации недопустимо передавать какие-либо сообщения, сигналы, элементы данных или коды состояния, связанные с расширениями, которые не были указаны в инициализационном сообщении от партнера.

7.3. Состояние In-Session

В состоянии In-Session сообщения могут передаваться в обоих направлениях между участниками DLEP для индикации изменений в состоянии сессии, добавления или исключения доступных адресатов, а также изменения состояний каналов к получателям.

Состояние In-Session поддерживается, пока не произойдет любое из приведенных ниже событий:

  • прерывание сессии сообщением Session Termination (12.9. Сообщение Session Termination);

  • прерывание сессии партнером с помощью сообщения Session Termination.

В этом случае реализация должна перейти в состояние Session Termination.

7.3.1. Сообщения Heartbeat

Для поддержки состояния In-Session периодически должны передаваться сообщения Heartbeat (12.20. Сообщение Heartbeat) между модемами и маршрутизаторами. Эти сообщения предназначены для сохранения сессии путем двухсторонней проверки связности между участниками DLEP. Рекомендуется устанавливать между сообщениями интервал 60 секунд. Интервал должен быть не менее 1 секунды и следует делать его настраиваемым.

Каждый участник DLEP отвечает за создание сообщений Heartbeat.

При получении любого действительного сообщения DLEP таймер сообщений Heartbeat должен сбрасываться в 0 (т. е. любое действительное сообщение выступает в качестве Heartbeat).

Реализация должна разрешать по меньшей мере 2 интервала без сообщений прежде, чем разрывать сессию с партнером. При разрыве сеанса должно передаваться сообщение Session Termination Message с элементом данных Status (13.1. Данные состояния), имеющим значение 132 ‘Timed Out’ (Таблица 2), после чего реализация должна перейти в состояние Session Termination.

7.4. Состояние Session Termination

При переходе реализации в состояние Session Termination после отправки сообщения Session Termination (12.9. Сообщение Session Termination) в результате ошибки или приема нейдествительного сообщения она должна дождать от партнера сообщения Session Termination Response (12.10. Отклик Session Termination Response). Отправителю следует выждать 4 интервал Heartbeat прежде, чем счесть партнера недоступным и продолжить разрыв сессии. Любые другие сообщения в процессе такого ожидания должны игнорироваться.

Когда отправитель Session Termination получает от партнера сообщение Session Termination Response или завершается время ожидания, отправитель должен перейти в состояние Session Reset.

Когда реализация получает от партнера сообщение Session Termination, она переходит в состояние Session Termination, а затем должна незамедлительно передать сообщение Session Termination Response и перейти в состояние Session Reset.

7.5. Состояние Session Reset

В состоянии Session Reset реализация должна выполнить указанные ниже действия:

  • освободить все выделенные для сессии ресурсы;

  • удалить всех получателей в базе данных, представленных сессией; передача сообщений Destination Down (12.15. Сообщение Destination Down) недопустима;

  • разорвать соединение TCP.

По завершении указанных действий реализации следует вернуться в подходящее исходное состояние:

  • модем — Peer Discovery;

  • маршрутизатор — Peer Discovery или Session Initialization в зависимости от конфигурации.

7.5.1. Неожиданный разрыв сессии TCP

Если соединение TCP между участниками DLEP разрывается, когда реализация не находится в состоянии Session Reset, реализация должна незамедлительно перейти в состояние Session Reset.

8. Модель транзакций

DLEP определяет простую модель транзакций для сообщений — в сессии может обрабатываться лишь один запрос на каждого получателя. Транзакция считается завершенной, когда получен отклик, соответствующий переданному ранее запросу. Если участник DLEP получает запрос для получателя, применительно к которому уже имеется незавершенный запрос, реализация должна прервать сессию сообщением Session Termination (12.9. Сообщение Session Termination), содержащим элемент данных Status (13.1. Данные состояния) с кодом 129 ‘Unexpected Message’ (Таблица 2), и перейти в состояние Session Termination. Не задается ограничений на общее число обрабатываемых одновременно транзакций, если каждая из них относится к своему получателю.

Следует отметить, что для выполнения некоторых запросов участникам DLEP может потребоваться достаточно большое время, например, модем, обрабатывающий групповой запрос Destination Up, может выполнять сложную реконфигурацию сети. Передающая реализация должна иметь возможность обработки длительных транзакций.

Кроме того, в каждый момент может обрабатываться лишь один сеансовый запрос, например, Session Initialization (12.5. Сообщение Session Initialization). Как отмечено выше, транзакция для сообщения считается завершенной при получении отклика, соответствующего переданному ранее запросу. Если участник DLEP получает сеансовый запрос в то время, когда обрабатывается другой сеансовый запрос, он должен прервать сессию сообщением Session Termination, содержажим элемент данных Status с кодом 129 ‘Unexpected Message’ и перейти в состояние Session Termination. Во время обработы сеансовой транзакции могут вводиться лишь сообщения Session Termination. Сообщения Heartbeat (12.20. Сообщение Heartbeat) недопустимо считать частью сеансовой транзакции.

Для транзакций DLEP не предусмотрены отказы и тайм-ауты, за исключением транзакий, не завершенных к моменту сброса сессии DLEP. При прерывании сессии отмена незавершенных транзакций должна выполняться как часть сброса конечного автомата состояний. Реализация может обнаруживать отказ партнера используя механизм Heartbeat в состоянии In-Session (7.3. Состояние In-Session).

9. Расширения

Расширения должны согласовываться на уровне сессии в процессе ее инициализации с помощью механизма Extensions Supported. Реализации в плане соответствия DLEP не обязана поддерживать какие-либо расширения.

Если требуются совместимые расширения протокола, они должны быть стандартизованы путем (1) обновления данного документа или (2) создания отдельной спецификации. Реестры IANA, указанные в разделе 15, содержат достаточно неискользованных кодов для сигналов, сообщений, элементов данных и состояний DLEP, что позволяет расширять протокол.

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

9.1. Экспериментальные расширения

Этот жокумент регистрирует пространство номеров Private Use [RFC5226] для сигналов, сообщений, элементов данных и кодов состояния DLEP, предназначенное для экспериментальных расширений. Цель заключается в предоставлении возможности экспериментировать с новыми сигналами, сообщениями, элементами данных и состояниями, сохраняя документированное поведение DLEP.

В процессе инициализации сеанса использование приватных (Private Use) значений для сигналов, сообщений, элементов данных и/или состояний должно анонсироваться как расширения DLEP с применением идентификаторов из пространства Private Use в реестре Extension Type Values (Таблица 3) с заранее согласованным между участниками значением. Расширения DLEP из пространства номеров Private Use обычно называются экспериментальными.

Можно анонсировать множество расширений в сообщении Session Initialization, однако применение разных расширений в одной сессии может создавать проблемы взаимодействия или приводить к неожиданным результатам (например, конфликты экспериментальных сигналов, сообщений, элементов данных и/или кодов состояния). Поэтому такое использование не рекомендуется. Реализациям оставлено право в таких случаях определять корректный путь обработки (например, прерывание сессии или установку приоритета для конфликтующих расширений).

10. Масштабируемость

Протокол предназначен для поддержки тысяч адресатов с данной парой модем-маршрутизатор. При масштабном развертывании реализации следует рассмотреть применение методов, препядствующих лавинной отправке большого числа сообщений за короткое время. Например, может применяться алгоритм демпфирования для предотвращения генерации устройством с нестабильным подключением большого числа сообщений Destination Up и Destination Down.

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

11. Структура сигналов и сообщений DLEP

DLEP определяет два протокольных блока, используемых разными способами, — сигналы и сообщения. Сигналы используются лишь механизмом обнаружения и передаются в дейтаграммах UDP. Сообщения передаются в обоих направлениях через соединения TCP между участниками в состояниях Session Initialization, In-Session, Session Termination.

Сигналы и сообщения включают заголовок, за которым следует неупорядоченный список элементов данных. Заголовок содержит поля типа (Type) и размера (Length), а элементы данных используют формат TLV (тип-размерзначение). Элементы данных после заголовка сигнала или сообщения называют содержащимися в сигнале или сообщении.

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

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

11.1. Заголовок сигнала DLEP

Поля заголовка сигнала DLEP показаны на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|      'D'      |      'L'      |      'E'      |      'P'      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type                   | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 3. Заголовок сигнала DLEP.


«DLEP»

Каждый сигнал должен начинаться с последовательности символовU+0044, U+004C, U+0045, U+0050.

Signal Type

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

Length

16-битовое целое число без знака, указывающее размер (в октетах) всех элементов данных, содержащихся в этом сигнале. В размере элементов данных DLEP недопустимо учитывать размер самого Signal Header.

После заголовка сигнала DLEP могут следовать элементы данных DLEP (Data Item) в формате TLV.

11.2. Заголовок сообщения DLEP

Поля заголовка сообщения DLEP показаны на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type                  | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 4. Заголовок сообщения DLEP.


Message Type

16-битовое целое число без знака, содержащее одно из значений DLEP Message Type, определенных в документе.

Length

16-битовое целое число без знака, указывающее размер (в октетах) всех элементов данных, содержащихся в этом сообщении. В размере элементов данных DLEP недопустимо учитывать размер самого Message Header.

После заголовка сообщения DLEP могут следовать элементы данных DLEP (Data Item) в формате TLV.

11.3. Базовый элемент данных DLEP

Все элементы данных DLEP используют показанный на рисунке заголовок.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Value...                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Рисунок 5. Базовый элемент данных DLEP.


Data Item Type

16-битовое целое число без знака, указывающее один из типов Data Item.

Length

16-битовое целое число без знака, указывающее размер (в октетах) поля Value в элементе данных. В этом поле недопустимо учитывать размер полей Data Item Type и Length.

Value

Поле размером Length октетов, содержащее данные конкретного Data Item.

12. Сигналы и сообщения DLEP

12.1. Базовые правила обработки

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

Если сигнал получен со значением TTL не равным 255, принимающая реализация должна игнорировать сигнал.

При получении нераспознанного сообщения принимающая реализация должна выдать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент данных Status (13.1. Данные состояния) с кодом 128 ‘Unknown Message’ (Таблица 2), и перейти в состояние Session Termination.

При получении неожиданного сообщения принимающая реализация должна выдать сообщение Session Termination, содержащее элемент данных Status с кодом 129 ‘Unexpected Message’, и перейти в состояние Session Termination.

Если полученное сообщение содержит нараспознанный или недействительный элемент данных или не разрешенные дубликаты Data Item, принимающая реализация должна выдать сообщение Session Termination, содержащее элемент данных Status с кодом 130 ‘Invalid Data’, и перейти в состояние Session Termination.

Если пакет в потоке TCP получен со значением TTL, отличным от 255, принимающая реализация должна незамедлительно перейти в состояние Session Reset.

Перед обменом сообщениями Destination Up (12.11. Сообщение Destination Up) и Destination Up Response (12.12. Отклик Destination Up Response) или Destination Announce (12.13. Сообщение Destination Announce) и Destination Announce Response (12.14. Отклик Destination Announce Response) нельзя передавать сообщения, относящиеся к адресатам. Реализация, принявшая сообщение с неанонсированным адресатом, должна прервать сессию сообщением Session Termination, с элементом данных Status = 131 ‘Invalid Destination’ и перейти в состояние Session Termination.

После обмена сообщениями Destination Down (12.15. Сообщение Destination Down) и Destination Down Response (12.16. Отклик Destination Down Response) не допускается передача других сообщений об адресатах, пока не будет выполнен новый обмен Destination Up или Destination Announce. Реализация, получившая сообщение об адресате, ранее объявленном как отключенный (down), должна прервать сессию сообщением Session Termination, с элементом данных Status = 131 ‘Invalid Destination’ и перейти в состояние Session Termination.

12.2. Обработка кода состояния

Поведение участника DLEP при получении элемента данных Status (13.1. Данные состояния) определяется режимом отказа, связанным с кодом состояния (Таблица 2). Для всех кодов меньше 100 при отказе выполнение продолжается (Continue), для остальных кодов — прерывается (Terminate).

Участник DLEP, получивший сообщение, отличное от Session Termination (12.9. Сообщение Session Termination), с элементом данных Status, для которого задан режим Terminate, должен незамедлительно передать сообщение Session Termination, включив в него полученный элемент Status, а затем перейти в состояние Session Termination.

Участник DLEP при получении сообщения, содержащего элемент данных Status, для которого задан режим Continue, может продолжать обычное использование сессии.

12.3. Сигнал Peer Discovery

Сигнал Peer Discovery маршрутизатору DLEP следует передавать для обнаружения в сети модемов DLEP (7.1. Состояние Peer Discovery.

Сигнал Peer Discovery должен передаваться в пакете UDP. В качестве получателя должен указываться общеизвестный адрес и порт DLEP. Маршрутизаторам, поддерживающим работу DLEP по протоколам IPv4 и IPv6, рекомендуется выбирать транспорт IPv6. В качестве IP-адреса отправителя должен устанавливаться адрес маршрутизатора, связанный с интерфейсом DLEP. Для порта отправителя DLEP не задает требований.

Для создания Peer Discovery Signal устанавливается Signal Type = 1 в Signal Header (15.2. Типы сигналов).

Сигнал Peer Discovery может включать Peer Type Data Item (13.4. Peer Type).

12.4. Сигнал Peer Offer

Сигнал Peer Offer должен передаваться модемом DLEP в ответ на корректно отформатированный и адресованный сигнал Peer Discovery (12.3. Сигнал Peer Discovery ).

Сигнал Peer Offer должен передаваться в пакете UDP. Поля отправителя и получателя IP должны быть значениями из сигнала Peer Discovery, которые поменяны местами. Сигнал Peer Offer завершает процесс обнаружения (7.1. Состояние Peer Discovery).

Для создания Peer Offer Signal устанавливается Signal Type = 2 в Signal Header (15.2. Типы сигналов).

Сигнал Peer Offer Signal может включать Peer Type Data Item (13.4. Peer Type).

Сигнал Peer Offer Signal может включать один или несколько перечисленных ниже Data Item с разными значениями:

  • IPv4 Connection Point (13.2. IPv4 Connection Point);

  • IPv6 Connection Point (13.3. IPv6 Connection Point).

Эти элементы указывают индивидуальные адреса, которые маршрутизатор должен использовать в сессии DLEP TCP.

12.5. Сообщение Session Initialization

Сообщение Session Initialization маршрутизатор DLEP должен передавать как первое сообщение в сессии DLEP TCP. Оно передается маршрутизатором после организации соединения TCP через адрес и порт, полученные в соотщении Peer Offer или заданные в конфигурации.

При создании сообщения Session Initialization устанавливается Message Type = 1 в Message Header (15.3. Регистрации Message Type).

Сообщение Session Initialization должно содержать по одному из перечисленных ниже элементов данных:

  • Heartbeat Interval (13.5. Heartbeat Interval)

  • Peer Type (13.4. Peer Type)

При поддержке расширения DLEP сообщение Session Initialization должно содержать элемент данных Extensions Supported (13.6. Extensions Supported).

Сообщение Session Initialization может включать 1 или несколько перечисленных ниже элементов данных с разными значениями и установленным (1) флагом Add/Drop (A) (13. Элементы данных DLEP):

  • IPv4 Address (13.8. IPv4 Address);

  • IPv6 Address (13.9. IPv6 Address);

  • IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);

  • IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

Если реализация поддерживает необязательные расширения, они должны быть указаны в элементе данных Extensions Supported. Если элемента Extensions Supported нет в сообщении Session Initialization, модем должен считать, что маршрутизатор не поддерживает расширений.

Сообщения DLEP Heartbeat не передаются до приема сообщения Session Initialization Response (12.6. Отклик Session Initialization Response), поэтому реализация должна применять свою эвристику для времени ожидания.

Исключением из общего правила поведения реализации, получившей в сообщении непонятный элемент данных (12.1. Базовые правила обработки), является сообщение Session Initialization с 1 или несколькими элементами Extensions Supported, анонсирующими поддержку непонятных для реализации расширений. Реализация может игнорировать непонятные элементы данных.

12.6. Отклик Session Initialization Response

Сообщение Session Initialization Response модем DLEP должен передавать в ответ на Session Initialization (12.5. Сообщение Session Initialization).

При создании сообщения Session Initialization Response устанавливается Message Type = 2 в заголовке сообщения (15.3. Регистрации Message Type).

Сообщение Session Initialization Response должно содержжать по одному элементу данных, указанному ниже:

  • Status (13.1. Данные состояния);

  • Peer Type (13.4. Peer Type);

  • Heartbeat Interval (13.5. Heartbeat Interval);

  • Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));

  • Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));

  • Current Data Rate (Receive) (13.14. Current Data Rate (Receive));

  • Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));

  • Latency (13.16. Latency).

Сообщение Session Initialization Response должно включать по одному из перечисленных ниже элементов данных, если он используется в сессии:

  • Resources (13.17. Resources);

  • Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));

  • Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));

  • Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Если поддерживаются расширения DLEP, сообщение Session Initialization Response должно содержать элемент данных Extensions Supported (13.6. Extensions Supported).

Сообщение Session Initialization Response может включать 1 или несколько перечисленных ниже элементов данных с разными значениями и установленным (1) флагом Add/Drop (A) (13. Элементы данных DLEP):

  • IPv4 Address (13.8. IPv4 Address);

  • IPv6 Address (13.9. IPv6 Address);

  • IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);

  • IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

Сообщение Session Initialization Response завершает организацию сессии DLEP. Модему следует переходить в состояние In-Session, когда это сообщение передано, а маршрутизатору следует переходить в In-Session при получении приемлемого сообщения Session Initialization Response.

Все поддерживаемые элементы данных метрики должны включаться в Session Initialization Response Message с использованием принятых по умолчанию значений в рамках сессии. Это можно считать «декларированием» всех поддерживаемых параметров метрики при инициализации сессии DLEP. Прием любого последующего сообщения DLEP с параметрами метрики, не включенными в Session Initialization Response, должен считаться ошибкой, ведущей к разрыву сессии DLEP между модемом и маршрутизатором.

Если модем поддерживает необязательные расширения, они должны быть указаны в элементе данных Extensions Supported. Если элемента Extensions Supported нет в сообщении Session Initialization Response, маршрутизатор должен считать, что модем не поддерживает расширений. После обмена сообщениями Session Initialization и Session Initialization Response реализация должна использовать лишь расширения, поддерживаемые обоими участниками DLEP (7.2. Состояние Session Initialization).

12.7. Сообщение Session Update

Сообщение Session Update может передать участник DLEP в рамках сессии для индикации смены локального адреса L3 и/или метрических параметров.

В заголовке Session Update устанавливается Message Type = 3 (15.3. Регистрации Message Type).

Сообщение Session Update может включать 1 или несколько указанных элементов данных с разными значениями:

  • IPv4 Address (13.8. IPv4 Address);

  • IPv6 Address (13.9. IPv6 Address);

  • IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);

  • IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

При передаче модемом сообщение Session Update может включать 1 или несколько элементов данных:

  • Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));

  • Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));

  • Current Data Rate (Receive) (13.14. Current Data Rate (Receive));

  • Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));

  • Latency (13.16. Latency).

При передаче модемом сообщение Session Update может включать 1 или несколько перечисленных ниже элементов данных, если они используются в сессии:

  • Resources (13.17. Resources);

  • Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));

  • Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));

  • Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Если в Session Update представлены параметры метрики (например, Maximum Data Rate), эти параметры считаются относящимися к сессии в целом и должны применяться ко всем адресатам из информационной базы, связанной с сессией DLEP. Это включает адресатов, для которых метрика может быть сохранена на основе полученных сообщений Destination Update.

Следует отметить, что сообщения Session Update могут передавать модемы и маршрутизаторы. Например, добавление адреса IPv4 на маршрутизаторе может служить основанием для сообщения Session Update подключенным модемам. Аналогично, смена модемом Maximum Data Rate (Receive) для всех адресатов может быть отражена в сообщении Session Update для подключенных маршрутизаторов.

Если модем способен понимать и пересылать информацию об адресах и подсетях L3 (механизмы не определены в DLEP), изменение таких сведений побудит все удаленные модемы с поддержкой DLEP передать Destination Update своим локальным маршрутизаторам с указанием новых (или удаленных) адресов и подсетей.

12.8. Отклик Session Update Response

Сообщение Session Update Response должно передаваться участником DLEP в ответ на Session Update (12.7. Сообщение Session Update).

В заголовке Session Update Response устанавливается Message Type = 4 (15.3. Регистрации Message Type).

Сообщение Session Update Response должно включать элемент данных Status (13.1. Данные состояния).

12.9. Сообщение Session Termination

Когда участник DLEP принимает решение о необходимости прервать сессию DLEP, он должен передать (или попытаться) сообщение Session Termination.

В заголовке Session Termination устанавливается значение Message Type = 5 (15.3. Регистрации Message Type).

Сообщение Session Termination должно включать элемент данных Status (13.1. Данные состояния).

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

12.10. Отклик Session Termination Response

Сообщение Session Termination Response должно передаваться участником DLEP в ответ на Session Termination Message (12.9. Сообщение Session Termination).

В заголовке Session Termination Response устанавливается Message Type = 6 (15.3. Регистрации Message Type).

Элементы данных ни включаются в Session Termination Response.

Прием сообщения Session Termination Response завершает разпыв сессии DLEP (7.4. Состояние Session Termination).

12.11. Сообщение Destination Up

Сообщения Destination Up модем может передавать для оповещения подключенного маршрутизатора о присутствии нового доступного получателя.

В заголовке Destination Up устанавливается значение Message Type = 7 (15.3. Регистрации Message Type).

Сообщение Destination Up должно включать элемент данных MAC Address (13.7. MAC Address).

В сообщение Destination Up следует включать 1 или несколько перечисленных ниже Data Item с разными значениями:

  • IPv4 Address (13.8. IPv4 Address);

  • IPv6 Address (13.9. IPv6 Address).

Сообщение Destination Up может включать по одному из перечисленных ниже элементов данных:

  • Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));

  • Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));

  • Current Data Rate (Receive) (13.14. Current Data Rate (Receive));

  • Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));

  • Latency (13.16. Latency).

Сообщение Destination Up может включать по 1 из перечисленных ниже элементов данных, если этот элемент используется в сессии:

  • Resources (13.17. Resources);

  • Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));

  • Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));

  • Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Сообщение Destination Up может включать по 1 из перечисленных ниже элементов данных с разными значениями:

  • IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);

  • IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

Маршрутизатор, получивший Destination Up выделяет необходимые ресурсы, создает в информационной базе запись с указанными значениями (MAC Address, Latency, Data Rate и т. п.) для получателя. Информация об этом получателе будет сохраняться в базе до получения маршрутизатором сообщения Destination Down (12.15. Сообщение Destination Down), указывающего, что модем потерял связь с удаленным узлом или реализация перешла в состояние Session Termination.

12.12. Отклик Destination Up Response

Маршрутизатор должен передавать сообщение Destination Up Response в ответ на Destination Up (12.11. Сообщение Destination Up) is received.

В заголовке Destination Up Response устанавливается Message Type = 8 (15.3. Регистрации Message Type).

Сообщение Destination Up Response должно содержать по одному из перечисленных ниже элементов данных:

  • MAC Address (13.7. MAC Address);

  • Status (13.1. Данные состояния).

Маршрутизатор, желающий получить дополнительную информацию о получателе, указанном в соответствующем сообщении Destination Up, должен установить в отклике Status = 0 ‘Success’ (Таблица 2). Если маршрутизатор не заинтересован в получателе, указанном в соответствующем сообщении Destination Up, он может установить в отклике Status = 1 ‘Not Interested’.

Модему, получившему Destination Up Response с элементом Status, отличным от 0 ‘Success’, недопустимо передавать другие сообщения Destination для этого адресата, например, Destination Down (12.15. Сообщение Destination Down) или Destination Update (12.17. Сообщение Destination Update) с тем же MAC-адресом.

12.13. Сообщение Destination Announce

Обычно модем обнаруживает присутствие одной или нескольких удаленных пар модем-маршрутизатор и анонсирует появление каждого получателя передачей маршрутизатору соответствующего сообщения Destination Up (12.11. Сообщение Destination Up). Однако могут быть случаи, когда маршрутизатор хочет выразить интерес к адресату, который еще не анонсирован (обычно групповой адресат). В таких случаях маршрутизатор может передать сообщение Destination Announce для обозначения своего интереса.

Сообщение Destination Announce маршрутизатор может также отправлять для запроса информации о получателе, (1) интерес к которому был ранее отвергнут статусом 1 ‘Not Interested’ в сообщении Destination Up Response (12.12. Отклик Destination Up Response, Таблица 2) или (2) который раньше был объявлен отключенным (down), в сообщении Destination Down (12.15. Сообщение Destination Down).

В заголовке сообщения Destination Announce указывается Message Type = 9 (15.3. Регистрации Message Type).

Сообщение Destination Announce должно включать элемент данных MAC Address (13.7. MAC Address).

Сообщение Destination Announce может содержать перечисленные ниже элементы данных с разными значениями:

  • IPv4 Address (13.8. IPv4 Address);

  • IPv6 Address (13.9. IPv6 Address).

Одним из преимуществ реализации DLEP является использование знаний модема о каналах между удаленными адресатами, что позволяет маршрутизатору избежать зондирования соседей, поэтому реализациям в модемах следует анонсировать доступных адресатов в сообщениях Destination Up, а не полагаться на Destination Announce.

12.14. Отклик Destination Announce Response

Модем должен передавать сообщение Destination Announce Response в ответ на Destination Announce (12.13. Сообщение Destination Announce).

При создании Destination Announce Response устанавливается Message Type = 10 (15.3. Регистрации Message Type) в заголовке сообщения. Сообщение Destination Announce Response должно содержать по одному элементу данных:

  • MAC Address (13.7. MAC Address);

  • Status (13.1. Данные состояния).

Destination Announce Response может включать один или несколько элементов данных с разными значениями:

  • IPv4 Address (13.8. IPv4 Address);

  • IPv6 Address (13.9. IPv6 Address);

  • IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);

  • IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

Сообщение Destination Announce Response может включать по одному элементу данных, перечисленных ниже:

  • Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));

  • Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));

  • Current Data Rate (Receive) (13.14. Current Data Rate (Receive));

  • Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));

  • Latency (13.16. Latency).

Destination Announce Response может включать по одному элементу данных, если он применяется в сессии:

  • Resources (13.17. Resources);

  • Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));

  • Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));

  • Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Если модем не способен незамедлительно сообщить запрошенные сведения (например, адресат в данный момент не доступен), он должен возвратить элемент данных Status = 2 ‘Request Denied’ (Таблица 2).

После передачи сообщения Destination Announce Response с элементом данных Status Data, содержащим отличное от 0 ‘Success’ значение, модем изменения на канале к адресату в сообщении Destination Update.

При получении Destination Announce Response маршрутизатору следует добавить данные об адресате в свою информационную базу.

12.15. Сообщение Destination Down

Модем должен передавать сообщение Destination Down для информирования о недоступности адресата (удаленный узел или multicast-группа).

Маршрутизатор может передать Destination Down для онформирования о том, что ему больше не нужна информация о получателе.

При создании Destination Down устанавливается значение Message Type = 11 в Message Header (15.3. Регистрации Message Type).

Сообщение Destination Down должно включать элемент данных MAC Address (13.7. MAC Address).

Следует отметить, что сообщения Destination Down могут передавать как модемы, так и маршрутизаторы, независимо от того, кто из них сообщил первым об активности (up) адресата.

12.16. Отклик Destination Down Response

Сообщение Destination Down Response должно передаваться получателем Destination Down (12.15. Сообщение Destination Down) для подтверждения того, что относящиеся к этому адресату данные удалены из базы.

В заголовке Destination Down Response указывается Message Type = 12 (15.3. Регистрации Message Type).

Сообщение Destination Down Response должно содержать по одному элементу данных:

  • MAC Address (13.7. MAC Address);

  • Status (13.1. Данные состояния).

12.17. Сообщение Destination Update

Модему следует передавать сообщение Destination Update при обнаруженииизменений в информационной базе для нанного адресата (удаленный узел или multicast-группа). Примерами изменений, вызывающих передачу Destination Update, являются:

  • изменение метрики канала (например, скорости);

  • смена адреса L3.

В заголовке Destination Update указывается Message Type = 13 (15.3. Регистрации Message Type).

Сообщение Destination Update должно включать элемент данных MAC Address (13.7. MAC Address).

Destination Update может включать по одному из перечисленных элементов данных:

  • Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));

  • Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));

  • Current Data Rate (Receive) (13.14. Current Data Rate (Receive));

  • Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));

  • Latency (13.16. Latency).

Destination Update может включать по одному из указанных элементов данных, если он применяется в сессии:

  • Resources (13.17. Resources);

  • Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));

  • Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));

  • Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Destination Update может включать один или несколько элементов данных с разными значениями, указанных ниже:

  • IPv4 Address (13.8. IPv4 Address);

  • IPv6 Address (13.9. IPv6 Address);

  • IPv4 Attached Subnet (13.10. IPv4 Attached Subnet);

  • IPv6 Attached Subnet (13.11. IPv6 Attached Subnet).

Параметры метрики, указанные в сообщении, переопределяют парметры, полученные ранее в сообщениях Session, Destination, Link Characteristics (например, Session Initialization, Destination Up, Link Characteristics Response).

Следует отметить, что для этого сообщения нет соответствующего отклика.

12.18. Запрос характеристик канала

Маршрутизатор может передавать сообщение Link Characteristics Request, чтобы запросить у модема инициирование изменений определенных характеристик канала. Запрос может указывать реального (например, удаленный узел) или логического (например, multicast-группу) адресата в сети.

В заголовке Link Characteristics Request указывается Message Type = 14 (15.3. Регистрации Message Type).

Сообщение Link Characteristics Request должно включать элемент данных MAC Address (13.7. MAC Address).

Сообщение Link Characteristics Request должно также включать по меньшей мере по одному элементу данных:

  • Current Data Rate (Receive) (13.14. Current Data Rate (Receive));

  • Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));

  • Latency (13.16. Latency).

Link Characteristics Request может включать один из элементов данных Current Data Rate (Receive) (CDRR) или Current Data Rate (Transmit) (CDRT) для запроса отличной от текущей скорости, а также элемент Latency для запроса значения максимальной задержки на канале.

Передающему сообщение маршрутизатору следует понимать, что выполнение запроса Link Characteristics Request может занять достаточно продолжительное время.

12.19. Отклик с характеристиками канала

Модем должен отвечать сообщением Link Characteristics Response при получении Link Characteristics Request (12.18. Запрос характеристик канала).

В заголовке Link Characteristics Response указывается Message Type = 15 (15.3. Регистрации Message Type).

Сообщение Link Characteristics Response должно включать по одному элементу данных:

  • MAC Address (13.7. MAC Address);

  • Status (13.1. Данные состояния).

В сообщение Link Characteristics Response следует включать по одному элементу данных:

  • Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive));

  • Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit));

  • Current Data Rate (Receive) (13.14. Current Data Rate (Receive));

  • Current Data Rate (Transmit) (13.15. Current Data Rate (Transmit));

  • Latency (13.16. Latency).

Сообщение Link Characteristics Response может включать по одному элементу перечисленных ниже данных, если такой элемент применяется в сессии:

  • Resources (13.17. Resources);

  • Relative Link Quality (Receive) (13.18. Relative Link Quality (Receive));

  • Relative Link Quality (Transmit) (13.19. Relative Link Quality (Transmit));

  • Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU)).

Сообщение Link Characteristics Response должно включать полный набор элементов данных метрики, указывая все параметры, объявленные в Session Initialization Response (12.6. Отклик Session Initialization Response). Значения метрических параметров в Link Characteristics Response должны отражать характеристики канала после выполнения запроса.

Если реализация не способна изменить характеристики канала в соответствии с запросом, она должна указать элемент данных Status с кодом 2 ‘Request Denied’ (Таблица 2).

12.20. Сообщение Heartbeat

Сообщение Heartbeat должно передаваться участником DLEP каждые N мсек, где N задается элементом данных Heartbeat Interval (13.5. Heartbeat Interval) в сообщении Session Initialization (12.5. Сообщение Session Initialization) или Session Initialization Response (12.6. Отклик Session Initialization Response).

При создании сообщения Heartbeat устанавливается значение Message Type = 16 в Message Header (15.3. Регистрации Message Type).

Элементы данных не используются в сообщениях Heartbeat.

Сообщения Heartbeat используются участниками DLEP для обнаружения обрыва связи с партнером по сеансу DLEP (модем или маршрутизатор), как описано в параграфе 7.3.1. Сообщения Heartbeat.

13. Элементы данных DLEP

Элементы данных DLEP (Data Item) перечислены в таблице.

Таблица 1. Типы элементов данных DLEP.

Код типа

Описание

0

Резерв

1

Status (13.1. Данные состояния)

2

IPv4 Connection Point (13.2. IPv4 Connection Point)

3

IPv6 Connection Point (13.3. IPv6 Connection Point)

4

Peer Type (13.4. Peer Type)

5

Heartbeat Interval (13.5. Heartbeat Interval)

6

Extensions Supported (13.6. Extensions Supported)

7

MAC Address (13.7. MAC Address)

8

IPv4 Address (13.8. IPv4 Address)

9

IPv6 Address (13.9. IPv6 Address)

10

IPv4 Attached Subnet (13.10. IPv4 Attached Subnet)

11

IPv6 Attached Subnet (13.11. IPv6 Attached Subnet)

12

Maximum Data Rate (Receive) (MDRR) (13.12. Maximum Data Rate (Receive))

13

Maximum Data Rate (Transmit) (MDRT) (13.13. Maximum Data Rate (Transmit))

14

Current Data Rate (Receive) (CDRR) (13.14. Current Data Rate (Receive))

15

Current Data Rate (Transmit) (CDRT) (13.15. Current Data Rate (Transmit))

16

Latency (13.16. Latency)

17

Resources (RES) (13.17. Resources)

18

Relative Link Quality (Receive) (RLQR) (13.18. Relative Link Quality (Receive))

19

Relative Link Quality (Transmit) (RLQT) (13.19. Relative Link Quality (Transmit))

20

Maximum Transmission Unit (MTU) (13.20. Maximum Transmission Unit (MTU))

21-65407

Не выделены (доступны для будущих расширений)

65408-65534

Резерв для приватного использования (доступны для экспериментов)

65535

Резерв

13.1. Данные состояния

Для сообщений Session Termination (12.9. Сообщение Session Termination) элемент данных Status Data указывает причину разрыва сессии. В остальных сообщениях этот элемент указывает успех или отказ предыдущего полученного сообщения.

Элемент Status Data включает необязательное поле Text, в котором может размещаться текстовое описание статуса. Использование поля Text полностью отдано на откуп принимающей реализации, например, оно может быть записано в системный журнал или просто отброшено. При отсутствии поля Text в элементе данных Status поле Length должно иметь значение 1. Структура Status Data Item показана на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status Code   | Text...                                       :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

1

Length

1 + размер Text (в октетах).

Status Code

Один из кодов состояния, указанных в таблице 2.

Text

Строка с кодировкой UTF-8 [RFC3629], описывающая причину состояния для целей, определяемых реализацией. Поскольку это поле служит для описания, реализации следует использовать лишь печатаемые символы. Реализации недопустимо считать поле Text строкой печатаемых символов с NUL-завершением.

Таблица 2. Коды состояния DLEP.

Код

Режим

Описание

Причина

0

Продолжение

Успех

Сообщение успешно обработано.

1

Продолжение

Не интересно

Получатель не заинтересован в предмете (теме) данного сообщения, например, в сообщении Destination Up Response (12.12. Отклик Destination Up Response), для индикации отсутствия других сообщений о получателе.

2

Продолжение

Запрос отвергнут

Получатель отверг выполнение запроса.

3

Продолжение

Несогласованные данные

Один или несколько элементов данных в сообщении описывают логически несогласованное состояние в сети, например, в сообщении Destination Up (12.11. Сообщение Destination Up) указана подсеть, не соответствующая текущей подсети адресата.

4-111

Продолжение

<Не выделено>

Для использования в будущем.

112-127

Продолжение

езерв для приватного использования>

Доступно для экспериментов.

128

Прерывание

Неизвестное сообщение

Сообщение не распознано реализацией.

129

Прерывание

Неожиданное сообщение

Сообщение не ожидается в текущем состоянии. Например, сообщение Session Initialization (12.5. Сообщение Session Initialization) в In-Session.

130

Прерывание

Недействительные данные

Один или несколько элементов данных в сообщении недействительны, не ожидаются или некорректно продублированы.

131

Прерывание

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

Адресат, указанный в сообщении, не соответствует анонсированному ранее, например, в сообщении Link Characteristics Response (12.19. Отклик с характеристиками канала).

132

Прерывание

Тайм-аут

Истекло время ожидания в сессии.

133-239

Прерывание

<Не выделено>

Для использования в будущем.

240-254

Прерывание

езерв для приватного использования>

Доступно для экспериментов.

255

Прерывание

Отключение

Партнер прерывает сессию по причине отключения.

13.2. IPv4 Connection Point

Элемент данных IPv4 Connection Point Data Item указывает адрес IPv4 и может также задавать номер порта TCP на модеме для организации соединения. При наличии информации маршрутизатор должен использовать ее для организации соединения TCP с модемом. Формат IPv4 Connection Point показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |               IPv4 Address...                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:  ...cont.     |   TCP Port Number (необязат)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

2

Length

5 (или 7 при включении порта TCP).

Flags

Поле флагов, описанных ниже.

IPv4 Address

Адрес IPv4, прослушиваемый модемом.

TCP Port Number

Номер порта TCP в модеме.

Если Length = 7, заданный номер порта должен использоваться для организации сессии TCP. Если порт TCP не указан (Length = 5), маршрутизатор должен использовать стандартный порт DLEP (15.4. Регистрации DLEP Data Item).

Поле Flags имеет форму, показанную на рисунке.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |T|
+-+-+-+-+-+-+-+-+


T

Флаг использования TLS, указывающий, защищено (1) или нет (0) соединение TCP с помощью TLS [RFC5246].

Reserved

Биты зарезервированы для использования в будущем и должны быть сброшены (0).

13.3. IPv6 Connection Point

Элемент данных IPv6 Connection Point Data Item указывает адрес IPv6 и может также задавать номер порта TCP на модеме для организации соединения. При наличии информации маршрутизатор должен использовать ее для организации соединения TCP с модемом. Формат IPv6 Connection Point показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |                IPv6 Address                   :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:  ...cont.     |   TCP Port Number (optional)  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

3

Length

17 (или 19 при включении порта TCP).

Flags

Поле флагов, описанных ниже.

IPv6 Address

Адрес IPv6, прослушиваемый модемом.

TCP Port Number

Номер порта TCP в модеме.

Если Length = 19, заданный номер порта должен использоваться для организации сессии TCP. Если порт не указан (Length = 17), маршрутизатор должен использовать стандартный порт DLEP (15.4. Регистрации DLEP Data Item).

Поле Flags имеет форму, показанную на рисунке.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |T|
+-+-+-+-+-+-+-+-+


T

Флаг использования TLS, указывающий, защищено (1) или нет (0) соединение TCP с помощью TLS [RFC5246].

Reserved

Биты зарезервированы для использования в будущем и должны быть сброшены (0).

13.4. Peer Type

Элемент данных Peer Type используется маршрутизаторами и модемами для указания дополнительных сведений о типе и свойствах беспроводной (over-the-air) плоскости управления.

В некоторых устройствах доступ к общей радиосреде (RF) строго контролируется. Примером могут служить спутниковые модемы, где протоколы (фирменные по природе) обеспечивают подключение к среде лишь уполномоченных модемов. Другим примером модемов такого класса являются правительственные и военные устройства, в которых применяются механизмы, обеспечивающие доступ к среде только разрешенных устройств. Существуют также модемы, где такого контроля доступа нет. Примером служат модемы, поддерживающие режим 802.11. Для индикации контроля доступа к среде используется флаг Secured Medium (S).

Peer Type Data Item включает текстовое описание партнера, которое предполагается используемым для информационных целей (например, для вывода на дисплей). Поля элемента данных Peer Type показаны на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         | Description...                                :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

4

Length

1 + размер Description (в октетах).

Flags

Поле флагов, описанных ниже.

Description

Текстовая строка UTF-8 [RFC3629]. Например, спутниковый модем может задать строку «Satellite terminal». Поскольку это поле предназначено для задания дополнительной информации в командах отображения, следует использовать в поле только печатаемые символы.

Реализациям недопустимо предполагать, что строка Description является строкой печатаемых символом с NUL-символом в конце.

 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|  Reserved   |S|
+-+-+-+-+-+-+-+-+


Поле Flags имеет форму, показанную на рисунке.

S

Флаг защищенной среды (Secured Medium), используемый модемом для указания контроля доступа к общей среде (RF) — (1) указывает контролируемый доступ, (0) — отсутствие контроля. Флаг имеет значение лишь в сигналах и сообщениях, передаваемых модемом.

Reserved

Биты зарезервированы для использования в будущем и должны быть сброшены (0).

13.5. Heartbeat Interval

Элемент данных Heartbeat Interval используется для задания периода (в мсек) передачи сообщений Heartbeat (12.20. Сообщение Heartbeat). Формат Heartbeat Interval Data Item показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Heartbeat Interval                      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

5

Length

4

Heartbeat Interval

Интервал (в миллисекундах) между сообщениями Heartbeat, указанный 32-битовым целым числом без знака. Значение 0 недопустимо.

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

13.6. Extensions Supported

Элемент данных Extensions Supported используется модемами и маршрутизаторами для согласования дополнительных функций, которые могут поддерживаться. Поле Extensions List содержит конкатенацию типов поддерживаемых расширений из реестра IANA Extension Type Values. Каждле определение Extension Type указывает дополнительные сигналы и элементы данных, которые будут поддерживаться. Формат элемента данных показан ниже.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions List...                                            :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

6

Length

Размер поля Extensions List в октетах (удвоенное число расширений.

Extensions List

Список поддерживаемых расширений, указанных 2-октетными значениями из реестра Extension Type Values.

13.7. MAC Address

Элемент данных MAC Address содержит адрес получателя на удаленном узле.

DLEP может поддерживать MAC-адреса в формате EUI8-48 и EUI-64, но все адреса в данной сессии DLEP должны иметь один формат и должны соответствовать MAC-адресу на подключенном модеме (например, если модем подключен к маршрутизатору EUI-48 MAC, все получатели, доступные через этот модем, должны использовать EUI-48).

Примерами виртуальных адресатов могут служить (1) групповой MAC-адрес (2) или широковещательный MAC-адрес FF:FF:FF:FF:FF:FF.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      MAC Address                              :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                MAC Address    :     (для EUI-64)              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

7

Length

6 для формата EUI-48 или 8 для EUI-64.

MAC Address

MAC-адрес получателя.

13.8. IPv4 Address

При включении в сообщение Session Update этот элемент данных содержит партнерский адрес IPv4, а в сообщениях Destination — адреса IPv4 для получателей. В любом случае элемент данных включает также индикацию того, задает ли этот элемент (1) новый или имеющийся адрес или (2) удаление известного ранее адреса. Формат элемента IPv4 Address показан на рисунке.


 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         | IPv4 Address                                  :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:  ...продолж.  |
+-+-+-+-+-+-+-+-+

Data Item Type

8

Length

5

Flags

Поле флагов, описанное ниже.

IPv4 Address

Адрес IPv4 для адресата или партнера.

Поле Flags имеет вид, показанный на рисунке.

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


A

Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).

Reserved

Резерв на будущее (должны иметь значение 0).

13.8.1. Обработка IPv4 Address

Обработка IPv4 Address должна выполняться в контексте сессии DLEP, где представлен элемент. Обработка ошибочных или логически противоречивых случаев зависит от типа сообщения в элементом данных и описана ниже.

Если сообщение относится к сессии, например, Session Initialization (12.5. Сообщение Session Initialization) или Session Update (12.7. Сообщение Session Update), получатель противоречивых данных должен передать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент Status (13.1. Данные состояния) с кодом 130 ‘Invalid Data’ и перейти в состояние Session Termination. Примеры таких случаев включают:

  • операцию Drop для адреса, не связанного с партнером в текущей сессии;

  • операцию Add для адреса, который уже добавлен партнеру в текущей сессии.

Если сообщение относится к адресату, например, Destination Up (12.11. Сообщение Destination Up) или Destination Update (12.17. Сообщение Destination Update), получатель противоречивых данных может передать отклик с элементом Status = 3 ‘Inconsistent Data’, но должен продолжать обработу сессии. Примерами могут служить:

  • операция Add для адреса, который уже добавлен получателю в текущей сессии;

  • операция Add для адреса, который связан с другим адресатом или партнером в текущей сессии;

  • операция Add для адреса, который не имеет смысла, например, определен как непересылаемый [RFC6890];

  • операцию Drop для адреса, не связанного с получателем в текущей сессии.

Если нет сообщения для ответа (например, Destination Update), реализация должна продолжать обработку сессии.

Модемы, не отслеживающие адреса IPv4, должны игнорировать элементы данных IPv4 Address.

13.9. IPv6 Address

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags         | IPv6 Address                                  :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        IPv6 Address                           :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: IPv6 Address  |
+-+-+-+-+-+-+-+-+


В сообщении Session Update этот элемент данных содержит партнерский адрес IPv6, а в Destination — адреса IPv6 для получателей. В любом случае элемент данных включает также индикацию того, задает ли этот элемент (1) новый или имеющийся адрес или (2) удаление известного ранее адреса. Формат элемента IPv6 Address показан на рисунке.

Data Item Type

9

Length

17

Flags

Поле флагов, описанное ниже.

IPv6 Address

Адрес IPv6 для адресата или партнера.

Поле Flags имеет форму, показанную на рисунке.

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


A

Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).

Reserved

Резерв на будущее (должны иметь значение 0).

13.9.1. Обработка IPv6 Address

Обработка IPv6 Address должна выполняться в контексте сессии DLEP, где представлен элемент. Обработка ошибочных или логически противоречивых случаев зависит от типа сообщения в элементом данных и описана ниже.

Если сообщение относится к сессии, например, Session Initialization (12.5. Сообщение Session Initialization) или Session Update (12.7. Сообщение Session Update), получатель противоречивых данных должен передать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент Status (13.1. Данные состояния) с кодом 130 ‘Invalid Data’ и перейти в состояние Session Termination. Примеры таких случаев включают:

  • операцию Drop для адреса, не связанного с партнером в текущей сессии;

  • операцию Add для адреса, который уже добавлен партнеру в текущей сессии.

Если сообщение относится к адресату, например, Destination Up (12.11. Сообщение Destination Up) или Destination Update (12.17. Сообщение Destination Update), получатель противоречивых данных может передать отклик с элементом Status = 3 ‘Inconsistent Data’, но должен продолжать обработу сессии. Примерами могут служить:

  • операция Add для адреса, который уже добавлен получателю в текущей сессии;

  • операция Add для адреса, который связан с другим адресатом или партнером в текущей сессии;

  • операция Add для адреса, который не имеет смысла, например, определен как непересылаемый [RFC6890];

  • операцию Drop для адреса, не связанного с получателем в текущей сессии.

Если нет подходящего сообщения для ответа (например, Destination Update), реализация должна продолжать обработку сессии.

Модемы, не отслеживающие адреса IPv6, должны игнорировать элементы данных IPv6 Address.

13.10. IPv4 Attached Subnet

Элемент данных DLEP IPv4 Attached Subnet позволяет устройству объявить о подключенной к нему подсети IPv4 (например, оконечной сети) и указать, что ему известно о присутствии или потере подсети у удаленного адресата. Элемент IPv4 Attached Subnet имеет форму, показанную на рисунке.


 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Flags        |          IPv4 Attached Subnet                 :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...продолж.   |Prefix Length  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Data Item Type

10

Length

6

Flags

Поле флагов, описанное ниже.

IPv4 Attached Subnet

Подсеть IPv4 доступная у адресата.

Prefix Length

Размер префикса (0-32) подсети IPv4. Префиксы, выходящие за указанный диапазон, должны считаться недействительными.

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


Поле Flags имеет форму, показанную на рисунке.

A

Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).

Reserved

Резерв на будущее (должны иметь значение 0).

13.10.1. Обработка IPv4 Attached Subnet

Обработка IPv4 Attached Subnet должна выполняться в контексте сессии DLEP, где представлен элемент.

Если сообщение относится к сессии, например, Session Initialization (12.5. Сообщение Session Initialization) или Session Update (12.7. Сообщение Session Update), получатель противоречивых данных должен передать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент Status (13.1. Данные состояния) с кодом 130 ‘Invalid Data’ и перейти в состояние Session Termination. Примеры таких случаев включают:

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

  • операцию Add для подсети, которая уже добавлена партнеру в текущей сессии.

Если сообщение относится к адресату, например, Destination Up (12.11. Сообщение Destination Up) или Destination Update (12.17. Сообщение Destination Update), получатель противоречивых данных может передать отклик с элементом Status = 3 ‘Inconsistent Data’, но должен продолжать обработу сессии. Примерами могут служить:

  • операция Add для подсети, которая уже добавлена получателю в текущей сессии;

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

  • операция Add для подсети, которая не имеет смысла, например, определена как непересылаемая [RFC6890];

  • операцию Drop для подсети, не связанной с получателем в текущей сессии.

Если нет подходящего сообщения для ответа (например, Destination Update), реализация должна продолжать обработку сессии.

Модемы, не отслеживающие подсети IPv4, должны игнорировать элементы данных IPv4 Attached Subnet.

13.11. IPv6 Attached Subnet

Элемент данных DLEP IPv6 Attached Subnet позволяет устройству объявить о подключенной к нему подсети IPv6 (например, оконечной сети) и указать, что ему известно о присутствии или потере подсети у удаленного адресата. Элемент IPv6 Attached Subnet имеет форму, показанную на рисунке.

  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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flags       |         IPv6 Attached Subnet                  :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                   IPv6 Attached Subnet                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                   IPv6 Attached Subnet                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                   IPv6 Attached Subnet                        :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ...продолж.   | Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

11

Length

18

Flags

Поле флагов, описанное ниже.

IPv6 Attached Subnet

Подсеть IPv6 доступная у адресата.

Prefix Length

Размер префикса (0-128) подсети IPv6. Префиксы, выходящие за указанный диапазон, должны считаться недействительными.

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


Поле Flags имеет форму, показанную на рисунке.

A

Флаг Add/Drop (добавление-отбрасывание), указывающий новый или имеющийся адрес (1) или отзыв адреса (0).

Reserved

Резерв на будущее (должны иметь значение 0).

13.11.1. Обработка IPv6 Attached Subnet

Обработка IPv6 Attached Subnet должна выполняться в контексте сессии DLEP, где представлен элемент. Обработка ошибочных или логически противоречивых случаев зависит от типа сообщения в элементом данных и описана ниже.

Если сообщение относится к сессии, например, Session Initialization (12.5. Сообщение Session Initialization) или Session Update (12.7. Сообщение Session Update), получатель противоречивых данных должен передать сообщение Session Termination (12.9. Сообщение Session Termination), содержащее элемент Status (13.1. Данные состояния) с кодом 130 ‘Invalid Data’ и перейти в состояние Session Termination. Примеры таких случаев включают:

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

  • операцию Add для подсети, которая уже добавлена партнеру в текущей сессии.

Если сообщение относится к адресату, например, Destination Up (12.11. Сообщение Destination Up) или Destination Update (12.17. Сообщение Destination Update), получатель противоречивых данных может передать отклик с элементом Status = 3 ‘Inconsistent Data’, но должен продолжать обработу сессии. Примерами могут служить:

  • операция Add для подсети, которая уже добавлена получателю в текущей сессии;

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

  • операция Add для подсети, которая не имеет смысла, например, определена как непересылаемая [RFC6890];

  • операцию Drop для подсети, не связанной с получателем в текущей сессии.

Если нет подходящего сообщения для ответа (например, Destination Update), реализация должна продолжать обработку сессии.

Модемы, не отслеживающие подсети IPv6, должны игнорировать элементы данных IPv6 Attached Subnet.

13.12. Maximum Data Rate (Receive)

Элемент данных Maximum Data Rate (Receive) (MDRR) служит для указания максимальной теоретически доступной скорости (бит/с) приема данных на канале. Формат Maximum Data Rate (Receive) показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MDRR (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        MDRR (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

12

Length

8

Maximum Data Rate (Receive)

64-битовое целое число без знака, указывающее максимальную теоретическую скорость приема (бит/с) на канале.

13.13. Maximum Data Rate (Transmit)

Элемент данных Maximum Data Rate (Transmit) (MDRT) служит для указания максимальной теоретически доступной скорости (бит/с) приема данных на канале. Формат Maximum Data Rate (Transmit) показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        MDRT (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        MDRT (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

13

Length

8

Maximum Data Rate (Transmit)

64-битовое целое число без знака, задающее максимальную теоретическую скорость передачи (бит/с) на канале.

13.14. Current Data Rate (Receive)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        CDRR (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        CDRR (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Элемент данных Current Data Rate (Receive) (CDRR) служит для указания текущей скорости (бит/с) приема данных на канале. При использовании в сообщении Link Characteristics Request Message (12.18. Запрос характеристик канала), Current Data Rate (Receive) представляет желаемую скорость приема в канале (бит/с). Формат Current Data Rate (Receive) показан на рисунке.

Data Item Type

14

Length

8

Current Data Rate (Receive)

64-битовое целое число без знака, указывающее текущую доступную скорость приема (бит/с) на канале.

Если Current Data Rate (Receive) и Maximum Data Rate (Receive) (13.12. Maximum Data Rate (Receive)) не различаются, значение Current Data Rate (Receive) должно устанавливаться равным Maximum Data Rate (Receive). Для Current Data Rate (Receive) недопустимо превышать значение Maximum Data Rate (Receive).

13.15. Current Data Rate (Transmit)

Элемент данных Current Data Rate (Transmit) (CDRR) служит для указания текущей скорости (бит/с) передачи данных на канале. При использовании в сообщении Link Characteristics Request Message (12.18. Запрос характеристик канала), Current Data Rate (Transmit) представляет желаемую скорость передачи в канале (бит/с). Формат Current Data Rate (Transmit) показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                        CDRT (bps)                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                        CDRT (bps)                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

15

Length

8

Current Data Rate (Transmit)

64-битовое целое число без знака, указывающее текущую доступную скорость передачи (бит/с) на канале.

Если Current Data Rate (Transmit) и Maximum Data Rate (Transmit) (13.13. Maximum Data Rate (Transmit)) не различаются, значение Current Data Rate (Receive) должно устанавливаться равным Maximum Data Rate (Transmit). Для Current Data Rate (Transmit) недопустимо превышать значение Maximum Data Rate (Transmit).

13.16. Latency

Элемент данных Latency служит для укаазния задержки на канале в микросекундах. Значение Latency указывает задержку при передаче. Расчет задержки зависит от реализации, например, это может быть средняя задержка, рассчитанная из внутренней очереди. Формат элемента данных Latency показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           Latency                             :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:                           Latency                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Data Item Type

16

Length

8

Latency

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

13.17. Resources

Элемент данных Resources (RES) служит для указания количества ограниченных (конечных) ресурсов, доступных для передачи и приема данных у адресата, в процентах от 0 (нет ресурсов) до 100 (полный доступ), в предположении прекращения передачи и приема данных при Resources = 0. Примером таких ресурсов может служить заряд батареи, память для очередей, загрузка процессора. Конкретные критерии выходят за рамки спецификации и зависят от реализации. Элемент данных предназначен для индикации тех или иных возможностей модема и/или маршрутизатора на стороне получателя. Формат элемента данных представлен на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     RES       |
+-+-+-+-+-+-+-+-+


Data Item Type

17

Length

1

Resources

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

Если устройство не может рассчитать Resources, использование элемента данных недопустимо.

13.18. Relative Link Quality (Receive)

Элемент данных Relative Link Quality (Receive) (RLQR) служит для индикации качества приема на канале к получателю в процентах. 0 указывает минимальное качество, 100 — наилучшее. Качество в данном контексте определяется стабильностью приема на канале — предполагается, что получатель с высоким значением Relative Link Quality (Receive) имеет стабильные параметры метрики DLEP, а при низком Relative Link Quality (Receive) метрика канала может быстро меняться в широком диапазоне. Формат Relative Link Quality (Receive) показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     RLQR      |
+-+-+-+-+-+-+-+-+


Data Item Type

18

Length

1

Relative Link Quality (Receive)

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

Если устройство не может рассчитать Relative Link Quality (Receive), использование элемента данных недопустимо.

13.19. Relative Link Quality (Transmit)

Элемент данных Relative Link Quality (Transmit) (RLQT) служит для индикации качества передачи на канале к получателю в процентах. 0 указывает минимальное качество, 100 — наилучшее. Качество в данном контексте определяется стабильностью передачи на канале — предполагается, что получатель с высоким значением Relative Link Quality (Transmit) имеет стабильные параметры метрики DLEP, а при низком Relative Link Quality (Transmit) метрика канала может быстро меняться в широком диапазоне. Формат Relative Link Quality (Transmit) показан на рисунке.

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     RLQT      |
+-+-+-+-+-+-+-+-+


Data Item Type

19

Length

1

Relative Link Quality (Transmit)

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

Если устройство не может рассчитать Relative Link Quality (Transmit), использование элемента данных недопустимо.

13.20. Maximum Transmission Unit (MTU)

 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Item Type                | Length                        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             MTU               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Элемент данных Maximum Transmission Unit (MTU) используется для указания максимального размера (в октетах) пакетов IP, которые можно передать без фрагментирования (с учетом заголовков, но не считая заголовки нижележащих уровней). Поля Maximum Transmission Unit Data Item показаны на рисунке.

Data Item Type

20

Length

2

Maximum Transmission Unit

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

Если устройство не способно рассчитать MTU, использование этого элемента данных недопустимо.

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

При использовании DLEP может возникать несколько проблем безопасности, отмеченных ниже.

  1. Атакующий может представиться участником DLEP путем инициирования сессии или вставки сообщений DLEP в существующую сессию.

  2. Атакующий может менять элементы данных, заставляя принимающую сторону вносить в свою базу некорректные сведения о сети.

  3. Атакующий может подключиться к незащищенной радиосети и инжектировать сигналы (over-the-air), влияющие на сведения, сообщаемые модемом DLEP, что может менять картину пересылки в маршрутизаторе.

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

По этим причинам защита транспорта DLEP должна рассматриваться как на транспортном уровне, так и на уровне L2.

При использовании на транспортном уровне протокола TLS каждому партнеру следует проверять действительность представленных другим партнером свидетельств (credential) в процессе организации сеанса TLS. При «выделенном развертывании» реализации, пытающийся использовать TLS, может потребоваться использование (1) заранее распространенных (pre-shared) ключей, (2) специальных методов проверки отождествления партнеров (3) или методов [RFC5487]. В модели «сетевого развертывания» (4. Варианты развертывания) следует использовать [RFC7525].

На уровне L2, поскольку работа DLEP ограничена одним интервалом (возможно, логическим), реализациям следует защищать также каналы L2. Примеры методов защиты каналов L2 включают [IEEE-802.1AE] и [IEEE-802.1X].

Проверяя флаг Secured Medium в элементе данных Peer Type (13.4. Peer Type), маршрутизатор может принять решение о доверии к информации, представленной модемом DLEP. В иных случаях маршрутизатору следует рассмотреть вопрос ограничения размера подключенных подсетей путем анонсирования элементов данных IPv4 Attached Subnet (13.10. IPv4 Attached Subnet) и/или IPv6 Attached Subnet (13.11. IPv6 Attached Subnet), учитываемых при выборе маршрута.

Для предотвращения возможных DoS-атак (отказ в обслуживании) реализациям, использующим механизм Peer Discovery, рекомендуется (1) поддерживать в информационной базе список хостов, с которыми были связаны отказы при инициализации сессии, даже если такие хосты предоставляют приемлемый сигнад Peer Discovery, и (2) игнорировать от таких хостов последующие сигналы Peer Discovery.

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

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

15.1. Регистрации

Агентство IANA создало новый реестр для протокола Dynamic Link Exchange Protocol (DLEP), включающий описанные ниже субреестры.

15.2. Типы сигналов

Агентстов IANA создало реестр DLEP под названием Signal Type Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Код типа

Описания, правила

0

Reserved

1

Peer Discovery Signal

2

Peer Offer Signal

3-65519

Unassigned / Specification Required

65520-65534

Reserved for Private Use

65535

Reserved

15.3. Регистрации Message Type

Агентство IANA создало реестр DLEP Message Type Values. В таблице приведены исходные значения и правила выделения в соответствии с [RFC5226].

Код типа

Описания, правила

0

Резерв

1

Session Initialization

2

Session Initialization Response

3

Session Update

4

Session Update Response

5

Session Termination

6

Session Termination Response

7

Destination Up

8

Destination Up Response

9

Destination Announce

10

Destination Announce Response

11

Destination Down

12

Destination Down Response

13

Destination Update

14

Link Characteristics Request

15

Link Characteristics Response

16

Heartbeat

17-65519

Не выделены, нужна спецификация

65520-65534

Резерв для приватного использования

65535

Резерв

15.4. Регистрации DLEP Data Item

Агентстов IANA создало реестр DLEP под названием Data Item Type Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Код типа

Описания, правила

0

Резерв

1

Status

2

IPv4 Connection Point

3

IPv6 Connection Point

4

Peer Type

5

Heartbeat Interval

6

Extensions Supported

7

MAC Address

8

IPv4 Address

9

IPv6 Address

10

IPv4 Attached Subnet

11

IPv6 Attached Subnet

12

Maximum Data Rate (Receive) (MDRR)

13

Maximum Data Rate (Transmit) (MDRT)

14

Current Data Rate (Receive) (CDRR)

15

Current Data Rate (Transmit) (CDRT)

16

Latency

17

Resources (RES)

18

Relative Link Quality (Receive) (RLQR)

19

Relative Link Quality (Transmit) (RLQT)

20

Maximum Transmission Unit (MTU)

21-65407

Не выделены, нужна спецификация

65408-65534

Резерв для приватного использования

65535

Резерв

15.5. Регистрации DLEP Status Code

Агентстов IANA создало реестр DLEP под названием Status Code Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Код состояния

Режим

Описания, правила

0

Продолжение

Success

1

Продолжение

Not Interested

2

Продолжение

Request Denied

3

Продолжение

Inconsistent Data

4-111

Продолжение

Не выделены, нужна спецификация

112-127

Продолжение

Приватное использование

128

Прерывание

Unknown Message

129

Прерывание

Unexpected Message

130

Прерывание

Invalid Data

131

Прерывание

Invalid Destination

132

Прерывание

Timed Out

133-239

Прерывание

Не выделены, нужна спецификация

240-254

Прерывание

Резерв для приватного использования

255

Прерывание

Shutting Down

15.6. Регистрации DLEP Extension

Агентстов IANA создало реестр DLEP под названием Extension Type Values. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Таблица 3. Типы расширений DLEP.

Код

Описания, правила

0

Резерв

1-65519

Не выделены, нужна спецификация

65520-65534

Резерв для приватного использования

65535

Резерв

15.7. Флаги DLEP IPv4 Connection Point

Агентстов IANA создало реестр DLEP под названием IPv4 Connection Point Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит

Описания, правила

0-6

Не выделены, нужна спецификация.

7

Индикатор использования TLS [RFC5246].

15.8. Флаги DLEP IPv6 Connection Point

Агентстов IANA создало реестр DLEP под названием IPv6 Connection Point Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит

Описания, правила

0-6

Не выделены, нужна спецификация.

7

Индикатор использования TLS [RFC5246].

15.9. Флаги DLEP Peer Type

Агентстов IANA создало реестр DLEP под названием Peer Type Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит

Описания, правила

0-6

Не выделены, нужна спецификация.

7

Индикатор использования Secured Medium.

15.10. Флаги DLEP IPv4 Address

Агентстов IANA создало реестр DLEP под названием IPv4 Address Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит

Описания, правила

0-6

Не выделены, нужна спецификация.

7

Индикатор Add/Drop.

15.11. Флаги DLEP IPv6 Address

Агентстов IANA создало реестр DLEP под названием IPv6 Address Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит

Описания, правила

0-6

Не выделены, нужна спецификация.

7

Индикатор Add/Drop.

15.12. Флаги DLEP IPv4 Attached Subnet

Агентстов IANA создало реестр DLEP под названием IPv4 Attached Subnet Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит

Описания, правила

0-6

Не выделены, нужна спецификация.

7

Индикатор Add/Drop.

15.13. Флаги DLEP IPv6 Attached Subnet

Агентстов IANA создало реестр DLEP под названием IPv6 Attached Subnet Flags. Ниже представлены начальные значения реестра и правила, соответствующие [RFC5226].

Бит

Описания, правила

0-6

Не выделены, нужна спецификация.

7

Индикатор Add/Drop.

15.14. Порт DLEP

Агентство IANA выделило значение 854 в реестре Service Name and Transport Protocol Port Number Registry (http://www.iana.org/assignments/service-names-port-numbers/) для протокола DLEP, определенного этим документом. Назначение действительно для протоколов TCP и UDP.

15.15. Групповой адрес DLEP IPv4 Link-Local

Агентство IANA выделило групповой адрес IPv4 224.0.0.117 в реестре http://www.iana.org/assignments/multicast-addresses для DLEP Discovery.

15.16. Групповой адрес DLEP IPv6 Link-Local

Агентство IANA выделило групповой адрес IPv6 FF02:0:0:0:0:0:1:7 в реестре http://www.iana.org/assignments/ipv6-multicast-addresses для DLEP Discovery.

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

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

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

[RFC3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.

[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, «The Generalized TTL Security Mechanism (GTSM)», RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.

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

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

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

[IEEE-802.1AE] «IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Security», DOI 10.1109/IEEESTD.2006.245590, <http://ieeexplore.ieee.org/document/1678345/>.

[IEEE-802.1X] «IEEE Standards for Local and metropolitan area networks—Port-Based Network Access Control», DOI 10.1109/IEEESTD.2010.5409813, <http://ieeexplore.ieee.org/document/5409813/>.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.

[RFC5487] Badra, M., «Pre-Shared Key Cipher Suites for TLS with SHA-256/384 and AES Galois Counter Mode», RFC 5487, DOI 10.17487/RFC5487, March 2009, <http://www.rfc-editor.org/info/rfc5487>.

[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman, «Special-Purpose IP Address Registries», BCP 153, RFC 6890, DOI 10.17487/RFC6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.

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

Приложение A. Потоки сигналов обнаружения

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор инициирует обнаружение,
|                                     запускает таймер и передает сигнал 
|-------Peer Discovery---->X          Peer Discovery.

         ~ ~ ~ ~ ~ ~ ~                Отсчет таймера завершается до приема
                                      Peer Offer.
|                                     
|-------Peer Discovery---------->|    Маршрутизатор повторяет Peer Discovery.
                                 |
                                 |    Модем получает Peer Discovery.
                                 |
                                 |    Модем передает Peer Offer с данными
|<--------Peer Offer-------------|    Connection Point.
:
:                                     Маршрутизатор МОЖЕТ отключить таймер
:                                     обнаружения и прекратить передачу 
:                                     Peer Discovery.

Приложение B. Потоки сообщений на уровне партнеров

B.1. Инициализация сессии

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор соединяется с найденной
|--Организовано соединение TCP--->    или заданной Modem Connection Point.
|
|                                     Маршрутизатор передает сообщение
|----Session Initialization----->|    Session Initialization.
                                 |
                                 |    Модем получает сообщение
                                 |    Session Initialization.
                                 |
                                 |    Модем передает сообщение Session 
|<--Session Initialization Resp.-|    Initialization Response с элементом 
|                                |    данных 'Success'.
|                                |
|<<============================>>|    Сессия организована.
:                                :    Начинается передача Heartbeat.

B.2. Отвергнутая инициализация сессии

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор соединяется с найденной
|--Организовано соединение TCP--->    или заданной Modem Connection Point.
|
|                                     Маршрутизатор передает сообщение
|----Session Initialization----->|    Session Initialization.
                                 |
                                 |    Модем получает сообщение
                                 |    Session Initialization, но не 
                                 |    поддерживает анонсированные расширения.
                                 |
                                 |    Модем передает сообщение Session 
|<--Session Initialization Resp.-|    Initialization Response с элементом 
|                                     данных 'Request Denied'.
|
|
|                                     Маршрутизатор получает негативный отклик
|                                     Session Initialization Response и
||---------TCP close------------||    разрывает соединение TCP.

B.3. Смена IP-адреса маршрутизатора

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор передает сообщение
|-------Session Update---------->|    Session Update с анонсом смены 
                                 |    адреса IP.
                                 |
                                 |    Модем получает Session Update
                                 |    и обновляет внутреннее состояние.
                                 |
|<----Session Update Response----|    Модем передает Session Update
                                 |    Response.

B.4. Изменение модемом метрики в масштабе сессии

Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                 |    Модем передает Session Update с
|<--------Session Update---------|    анонсом изменения метрики в сессии.
|
|                                     Маршрутизатор получает Session Update
|                                     и обновляет внутреннее состояние.
|
|----Session Update Response---->|    Маршрутизатор передает Session Update
                                 |    Response.

B.5. Разрыв сессии маршрутизатором

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор передает Session Termination
|------Session Termination------>|    с элементом данных Status.
|                                |
|-------TCP shutdown (send)--->  |    Маршрутизатор прекращает передачу сообщений.
                                 |
                                 |    Модем получает Session Termination,
                                 |    прекращает учет полученных Heartbeat
                                 |    и прекращает передачу Heartbeat.
                                 |
                                 |    Модем передает Session Termination
|<---Session Termination Resp.---|    Response с Status = 'Success'.
|
|                                     Модем прекращает передачу сообщений.
|
||---------TCP close------------||    Сессия прервана.

B.6. Разрыв сессии модемом

Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                 |    Модем передает Session Termination
|<----Session Termination--------|    Message с элементом Status.
|
|                                     Модем прекращает передачу сообщений.
|
|                                     Маршрутизатор получает Session
|                                     Termination,  прекращает учет
|                                     полученных Heartbeat и прекращает
|                                     передачу Heartbeat.
|
|                                     Маршрутизатор передает Session Termination
|---Session Termination Resp.--->|    Response с Status = 'Success'.
                                 |
                                 |    Маршрутизатор прекращает передачу сообщений.
                                 |
||---------TCP close------------||    Сессия прервана.

B.7. Сообщения Heartbeat

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|----------Heartbeat------------>|    Маршрутизатор передает Heartbeat.
                                 |
                                 |    Модем сбрасывает таймер Heartbeat.

         ~ ~ ~ ~ ~ ~ ~

|---------[Any Message]--------->|    Модем получает любое сообщение от
                                 |    маршрутизатора.
                                 |
                                 |    Модем сбрасывает таймер Heartbeat.

         ~ ~ ~ ~ ~ ~ ~

|<---------Heartbeat-------------|    Модем передает Heartbeat.
|
|                                     Маршрутизатор сбрасывает таймер Heartbeat.

         ~ ~ ~ ~ ~ ~ ~

|<--------[Any Message]----------|    Маршрутизатор получает любое сообщение
|                                     от модема.
|
|                                     Маршрутизатор сбрасывает таймер Heartbeat.

B.8. Маршрутизатор определил Heartbeat Timeout

Маршрутизатор                Модем    Описание сигнала  
========================================================================
         X<----------------------|    Маршрутизатор не получает Heartbeat.


|        X<----------------------|    Маршрутизатор не получает несколько
|                                     Heartbeat.
|
|
|------Session Termination------>|    Маршрутизатор передает Session 
|                                     Termination с Status = 'Timeout'
:
:                                     Прерывание...

B.9. Модем определил Heartbeat Timeout

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|---------------------->X             Модем не получает Heartbeat.


|---------------------->X        |    Модем не получает несколько
                                 |    Heartbeat.
                                 |
                                 |
|<-----Session Termination-------|    Модем передает Session Termination
                                 |    с Status = 'Timeout'
                                 :
                                 :    Прерывание...

Приложение C. Потоки сообщений на уровне адресата

C.1. Уведомления об адресатах

Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                 |    Модем обнаруживает доступность нового 
                                 |    логического адресата и передает 
|<-------Destination Up----------|    Destination Up.
|
|------Destination Up Resp.----->|    Маршрутизатор передает Destination Up
                                 |    Response.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    логического адресата и передает 
|<-------Destination Update------|    Destination Update.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    логического адресата и передает 
|<-------Destination Update------|    Destination Update.

            ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает недоступность
                                 |    логического адресата и передает 
|<-------Destination Down--------|    Destination Down.
|
|                                     Маршрутизатор получает Destination Down,
|                                     обновляет внутреннее состояние и 
|------Destination Down Resp.--->|    передает Destination Down Response.

C.2. Уведомление о групповом адресате

Маршрутизатор                Модем    Описание сигнала  
========================================================================
|                                     Маршрутизатор обнаруживает нового
|                                     группового получателя и передает
|-----Destination Announce------>|    Destination Announce.
                                 |
                                 |    Модем обновляет внутреннее состояние
                                 |    для отслеживания группового адресата
|<-----Dest. Announce Resp.------|    и передает Destination Announce
                                      Response.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    группового адресата и передает
|<-------Destination Update------|    Destination Update.

           ~ ~ ~ ~ ~ ~ ~
                                 |    Модем обнаруживает изменение метрики
                                 |    группового адресата и передает
|<-------Destination Update------|    Destination Update.

            ~ ~ ~ ~ ~ ~ ~
|                                     Маршрутизатор обнаруживает 
|                                     недоступность группового адресата
|--------Destination Down------->|    и передает Destination Down.
                                 |
                                 |    Модем получает Destination Down,
                                 |    обновляет внутреннее состояние и
|<-----Destination Down Resp.----|    передает Destination Down Response.

C.3. Link Characteristics Request

Маршрутизатор                Модем    Описание сигнала  
========================================================================
                                      Адресат уже анонсирован каким-либо
           ~ ~ ~ ~ ~ ~ ~              партнером.

|                                     Модему нужны другие характеристики
|                                     для адресата и он передает Link
|--Link Characteristics Request->|    Characteristics Request.
                                 |
                                 |    Модем пытается настроить свойства
                                 |    канала в соответствии с запросом
                                 |    и передает Link Characteristics
|<---Link Characteristics Resp.--|    Response с новым значением.

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

Спасибо членам группы разработки DLEP, предоставившим бесценную информацию. В эту команду входят Teco Boot, Bow-Nan Cheng, John Dowdell и Henning Rogge.

Хочется также отметить влияние и вклад Greg Harrison, Chris Olsen, Martin Duke, Subir Das, Jaewon Kang, Vikram Kaul, Nelson Powell, Lou Berger и Victoria Pritchard.

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

Stan Ratliff

VT iDirect

13861 Sunrise Valley Drive, Suite 300

Herndon, VA 20171

United States of America

Email: sratliff@idirect.net

Shawn Jury

Cisco Systems

170 West Tasman Drive

San Jose, CA 95134

United States of America

Email: sjury@cisco.com

Darryl Satterwhite

Broadcom

Email: dsatterw@broadcom.com

Rick Taylor

Airbus Defence & Space

Quadrant House

Celtic Springs

Coedkernew

Newport NP10 8FZ

United Kingdom

Email: rick.taylor@airbus.com

Bo Berry


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

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

nmalykh@protocols.ru

1Dynamic Link Exchange Protocol — протокол динамического обмена информацией о соединениях.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4Line-of-sight — прямая видимость.

5Demand Assigned Multiple Access — множественный доступ по запросу.

6Media Access Control — управление доступом к среде.

7Transport Layer Security — защита на транспортном уровне.

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




RFC 8126 Guidelines for Writing an IANA Considerations Section in RFCs

Internet Engineering Task Force (IETF)                         M. Cotton
Request for Comments: 8126                                           PTI
BCP: 26                                                         B. Leiba
Obsoletes: 5226                                      Huawei Technologies
Category: Best Current Practice                                T. Narten
ISSN: 2070-1721                                          IBM Corporation
                                                               June 2017

Рекомендации по написанию раздела «Взаимодействие с IANA» в RFC

Guidelines for Writing an IANA Considerations Section in RFCs

PDF

Тезисы

Многие протоколы используют идентификаторы, представляющие собой константы и другие общеизвестные (well-known) значения. Однако после определения протокола и начала его развертывания может потребоваться выделение новых значений (например, для нового типа опций DHCP, нового алгоритма шифрования или аутентификации для IPSec). Для того, чтобы такие параметры имели согласованные значения и интерпретацию в разных реализациях протоколов, требуется централизованное управление выделением значений. Для протоколов IETF функции управления возложены на агентство IANA1.

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

Этот документ служит заменой RFC RFC 5226.

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

Этот документ относится к категории обмена опытом (Internet Best Current Practices)

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

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

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

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

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

Оглавление

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

1. Введение

Многие протоколы используют точки расширения, которые применяют константы для идентификации разных протокольных параметров. Чтобы гарантировать непротиворечивость значений этих полей и возможность взаимодействие, выделение значений полей зачастую требует координации и централизованного хранения выделенных значений. Поле Protocol в заголовке IP [RFC791] и типы MIME [RFC6838] служат примерами такой координации.

IETF выбирает оператора IFO4 для параметров протокола, определяемого IETF. В соглашении между IETF и текущим IFO (ICANN), это называется оператором услуг протокольных параметров (IPPSO5). Для совместимости с прежней практикой IFO и IPPSO в этом документе обозначаются аббревиатурой IANA [RFC2860].

В этом документе мы будем называть наборы возможных значений полей «пространством имен» (namespace). Привязка или связывание конкретного значения из пространства имен с определенными целями называется выделение (назначением). Используются также термины assigned number (назначенное число), assigned value (назначенное значение), code point (код), protocol constant (протокольная константа), protocol parameter (параметр протокола). Акт назначения называется регистрацией и выполняется в контексте реестра. Термины «назначение» и «регистрация» чередуются в этом документе.

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

Обычно такая информация представляется в специальном разделе IANA Considerations (Взаимодействие с IANA).

1.1. Раздел IANA Considerations предназначен для IANA

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

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

Действия IANA обычно указываются в виде запросов к IANA (например, «агентство IANA просят выделить значение TBD1 из реестра Frobozz …»), а редактор RFC будет менять текст с учетом предпринятых действий («Агентство IANA выделило значение 83 из реестра Frobozz …»).

1.2. Обновление информации

IANA поддерживает web-страницу с дополнительными разъяснениями помимо предоставленных здесь, такими как незначительные обновления и краткое руководство. Авторам документов следует прочесть эту страницу. Все существенные обновления принятой практики будут вноситься в обновления BCP 26 (данный документ), который является определяющим.

<https://iana.org/help/protocol-registration>

1.3. Краткий контрольный список

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

В общем случае нужно выполнить указанные ниже действия.

  1. Указать всю информацию, которую нужно знать IANA в разделе «IANA Considerations» вашего документа (см. параграф 1.1).

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

  3. Отметим, что IESG имеет полномочия разрешения споров, связанных с регистрацией в IANA. При возникновении каких-либо вопросов или проблем следует получить консультацию у куратора вашего документа и/или руководителя рабочей группы, который может при необходимости привлечь руководителя направления — Area Director (см. параграф 3.3).

При создании нового реестра нужно выполнить указанные ниже действия.

  1. Дать реестру описательное имя и представить краткое описание его применения (см. параграф 2.2).

  2. Определить группу, в которую реестр следует включить (см. параграф 2.1).

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

  4. Задать начальный набор записей реестра, если они имеются (см. параграф 2.2).

  5. Убедиться, что правила внесения изменений понятны IANA на случай необходимости изменения формата или правил в будущем (см. параграф 2.3 и 9.5).

  6. Указать политику (или набор политик) регистрации для добавления записей в реестр (см. параграф 4 и обратите внимание на примечания в параграфах 4.11 и 4.12).

  7. При использовании политики, требующей назначения экспертов (Expert Review или Specification Required) разобраться с разделом 5 и предоставить рекомендации по рецензированию для экспертов (см. параграф 5.3).

  8. Если какой-либо диапазон значений реестра нужно зарезервировать для особых случаев или по иным причинам недоступности значений, обратитесь к разделу 6.

При регистрации в имеющемся реестре нужно выполнить указанные ниже действия.

  1. Четко указать реестр по его имени, возможно дополнив ссылкой (см. параграф 3.1).

  2. Если реестр имеет множество диапазонв для выделения значений, следует четко указать нужный диапазон (см. параграф 3.1).

  3. Следует избегать использования конкретных значений чисел и битов, оставив IANA выбор подходящего на момент регистрации значения (см. параграф 3.1). Это позволит избежать конфликтов между регистрациями.

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

  5. Следует определить (из справочного документа реестра), какая информация нужна для реестра и четко укажите всю требуемую информацию (см. параграф 3.1).

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

  7. Если правила регистрации еще не задают политику внесения изменений, следует убедиться, что IANA точно понимает правила внесения изменений на случай такой потребности в будущем (см. параграф 9.5).

Если создается документ «bis» или иным путем отменяется устаревший документ, следует обратиться к разделу 8.

Если нужна ранняя регистрация (например, для поддержки тестовых реализаций) до завершения документа, следует обратиться к [RFC7120].

Если нужно изменить формат/содержимое или правила для имеющегося реестра, см. параграф 2.4.

Если нужно обновить имеющуюся регистрацию, см. параграф 3.2.

Если нужно закрыть реестр за ненадобностью, см. параграф 9.6.

2. Создание и пересмотр реестров

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

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

2.1. Организация реестров

Все реестры IANA доступны на странице Protocol Registries по ссылке <https://www.iana.org/protocols>.

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

К сожалению здесь имеется некоторая непоследовательность в именовании. Имена групп называют «protocol category groups» (группы категорий протоколов), «groups» (группы), «top-level registries» (реестры верхнего уровня) или прочто «registries» (реестры). Реестры более низкого уровня называют «registries» или «sub-registries» (субреестры).

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

2.2. Документация, требуемая для реестров

Документы, которые создают новое пространство имен (или меняют имеющееся) и предполагают участие IANA в поддержке этого пространства (в качестве репозитория для зарегистрированных значений), должны содержать четкие инструкции для пространства имен в разделе provide IANA Considerations (Взаимодействие с IANA) или указанных в этом разделе документах.

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

Название (имя) реестра

Это имя будет указываться на web-странице IANA и в будущих документах, которым нужны значения из нового пространства. Следует указать полное имя и сокращения, если оно есть. Вестма желательно выбирать имена, которые не будут вносить путаницы с названиями других реестров.

При создании реестра должно быть указано название группы, в которую он включается, точно соответствующее указанному в списке Protocol Registries.

Предоставление URL для точного указания реестра поможет IANA понять запрос. Такие URL могут удаляться из RFC при окончательной публикации или сохраняться в документе. Если включен URL iana.org, IANA при необходимости будет корректировать ссылку.

Информация, требуемая для регистрации

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

Применимая политика регистрации

Правила, которые будут применяться для всех будущих регистрационных запросов. См. Раздел 4.

Размер, формат и синтаксис записей реестра

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

Предполагается указание строк в кодировке ASCII и следует четко указать, принимается ли во внимание регистр символов (например, все строки следует задавать в верхнем или нижнем регистре).

Строки, представляющие параметры протокола, редко (или никогда) будут использовать символы, отличные от ASCII. Если такие символы действительно нужны, следует четко указать их допустимость и требование представлять символы не-ASCII в кодировке Unicode с использованием соглашения (U+XXXX). При создании реестра нужно тщательно обдумать вопрос применения символов других языков и рассмотреть рекомендации (например, раздел 10 в [RFC7564]).

Начальное выделение и резервирование

Должны быть указаны все начальные назначения или регистрации. Кроме того, следует указать все значения, для приватного использования (Private Use), а также Reserved, Unassigned и т. п. (см. параграф 6).

Ниже приведен пример раздела IANA Considerations в документе, создающем новый реестр.

—————————————————————

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

Этот документ определяет новую опцию DHCP, названную FooBar (см. раздел y) и выделяет значение TBD1 из пространства имен DHCP Option <https://www.iana.org/assignments/bootp-dhcp-parameters> [RFC2132] [RFC2939].

Тег

Имя

Размер данных

Смысл

TBD1

FooBar

N

Сервер FooBar

Опция FooBar также определяет 8-битовое поле FooType field, для которого агенство IANA создает и поддерживает новый реестр «Значения FooType», используемый опцией FooBar. Начальные значения для реестра DHCP FooBar FooType приведены ниже, выделение новых значений будет происходить по процедуре Expert Review [BCP26]. Назначение включает имя DHCP FooBar FooType и связанное с ним значение.

Значение

Имя DHCP FooBar FooType

Определение

0

Резерв

1

Frobnitz

RFCXXXX, параграф y.1

2

NitzFrob

RFCXXXX, параграф y.1

3-254

Не выделены

255

Резерв

Примеры документов, создающих реестры, можно найти в [RFC3575], [RFC3968], [RFC4520].

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

2.3. Указание контроля изменений для реестра

Определения реестров и регистрации в них часто приходится менять после создания. Процесс внесения таких изменений усложняется при отсутствии четкого указания полномочий на изменения. Для реестров, созданных RFC в потоке IETF контроль изменений по умолчанию выполняется IETF через IESG. Это верно и для значений, зарегистрированных RFC из потока IETF.

Поскольку реестры могут создаваться и значения в них регистрироваться вне потока IETF, иногда желательно осуществлять контроль изменений без IETF и IESG. Всегда полезно иметь четко заданные правила контроля изменений.

Поэтому рекомендуется создавать все реестры с четким указанием правил изменения и полномочий на это. Для реестров, позволяющих регистрацию вне потока IETF, следует для каждого значения указывать контролера. Если определение или ссылку на зарегистрированное значение когда-либо придется менять, IANA важно знать, кто уполномочен вносить изменения. Например, реестр Media Types [RFC6838] включает поле Change Controller в шаблон регистрации. См. Также параграф 9.5.

2.4. Пересмотр имеющихся реестров

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

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

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

Примеры документов с рекомендациями для обновления имеющихся реестров можно найти в [RFC6895], [RFC3228], [RFC3575].

3. Регистрация новых значений в имеющемся реестре

3.1. Требования к документации для регистрации

Часто документы запрашивают выделение в имеющемся реестре (созданном ранее опубликованным документом).

Такие документы должны четко указывать реестр, в котором регистрируется значение. Используется точное имя реестра с web-страницы IANA и указывается, где определен реестр. При ссылке на имеющийся реестр полезно указывать URL для точной идентификации реестра (см. параграф 2.2).

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

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

Обычно численные значения выбираются IANA при утверждении документа и в проектах не следует указывать окончательные значения. Вместо этого в документе следует указывать заменители, такие как TBD1 и TBD2, указывая для каждого элемента свой заменитель. В разделе IANA Considerations следует попросить редактора RFC заменить эти значения назначенными IANA. Когда в проекте нужно указать значения для тестов или предварительных реализаций, нужно запрашивать раннее выделение (см. параграф 3.4) или использовать значения, которые уже были выделены для тестов и экспериментов (если соответствующий реестр позволяет это без явного назначения). Важно не назначать значений в проектах, чтобы агентство IANA не выделило такое значение другому документу. В проекте можно запросить конкретное значение в разделе «Взаимодействие с IANA» и IANA будет учитывать такие запросы, когда это возможно, но предложенное значение может быть выделено для иного применения, пока документ проходит утверждение.

Предлагаемые значения текстовых строк обычно указываются в документе, поскольку конфликты для них менее вероятны. При возникновении конфликта IANA будет обращаться к авторам для согласования иных значений. Когда в проекте нужно указать строковые значения для тестов или ранних реализаций, иногда используется предполагаемое окончательное значение. Однако зачастую лучше использовать черновое значение, возможно включающее номер версии чернового документа. Это позволит отличить ранние реализации от решений, использующих окончательную версию. В документе, предполагающем окончательное значение foobar, можно использовать, например, foobar-testing-draft-05 для версии проекта -05.

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

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

IANA предлагается назначить значение кода TBD1 для опции DNS Recursive Name Server и TBD2 — для Domain Search List из пространства номеров опций DHCP, определенного в параграфе 24.3 RFC 3315.

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

При запросе множества значений обычно полезно включать сводную таблицу добавлений/изменений. Полезно указывать такую таблицу в формате, применяемом на web-сайте IANA. Пример такой таблицы приведен ниже.

Значение

Описание

Ссылка

TBD1

Foobar

Данный RFC, параграф 3.2

TBD2

Gumbo

Данный RFC, параграф 3.3

TBD3

Banana

Данный RFC, параграф 3.4

Примечание. Если авторы считают, что включение таблицы приведет к многословию или повторам, они могут включить таблицу в проект с просьбой удалить ее перед публикацией RFC.

3.2. Обновление имеющихся записей

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

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

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

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

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

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

3.3. Переопределение процедур регистрации

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

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

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

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

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

3.4. Раннее выделение значений

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

IANA имеет механизм для обработки раннего назначения в некоторых случаях (см. [RFC7120]). Обычно не требуется указывать в реестре возможность раннего распределения, поскольку будут применяться общие правила.

4. Выбор политики регистрации и общеизвестные правила

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

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

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

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

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

Возможно самым важным является то, что непроверенные расширения могут препятствовать взаимодействию и снижать уровень безопасности (см. [RFC6709]).

Когда пространство имен по сути не ограничено и нет проблем взаимодействия или безопасности, выделение значение может выполняться без субъективного обзора. В таких случаях IANA может распределять значения напрямую, при условии наличия достаточных инструкций относительно типов запросов, которые следует удовлетворять.

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

Хотя иногда нужно ограничивать то, что регистрируется (например, для ограниченных ресурсов, таких как биты в байте или элементы, где неподдерживаемые значения могут нарушать работу протокола), во многих случаях наличие в реестре реально применяемых значений важнее. Чрезмерно строгие критерии и издержки (время и усилия) не позволяют людям попытаться зарегистрировать значения. Если реестр не отражает реально используемых элементов протокола, это может отрицательно влиять на развертывание протоколов в Internet и снижать ценность реестра.

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

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

  1. Private Use — приватное использование.

  2. Experimental Use — экспериментальное использование.

  3. Hierarchical Allocation — иерархическое выделение.

  4. First Come First Served — назначение в порядке очереди.

  5. Expert Review — рецензия эксперта.

  6. Specification Required — требование спецификации.

  7. RFC Required — требование публикации RFC.

  8. IETF Review — рецензия IETF.

  9. Standards Action — стандартизация.

  10. IESG Approval — одобрение IESG.

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

Точно так же бывает полезно задать несколько правил, применяемых «параллельно» в зависимости от обстоятельств. Этот вопрос более подробно рассмотрен в параграфе 4.12.

Ниже приведены примеры RFC, где задано несколько «параллельных» правил выделения значений:

LDAP [RFC4520];

идентификаторы TLS ClientCertificateType [RFC5246] (см. ниже);

реестр MPLS Pseudowire Types [RFC4446].

4.1. Приватное использование

Только для частного или локального использования в соответствии с потребностями и целями локального сайта. Не предпринимается попыток предотвращения использования разными сайтами одних и тех же значений с разными (и несовместимыми) целями. Для IANA нет необходимости рассматривать такие назначения и обычно они не важны зрения взаимодействия. Сайт самостоятельно отвечает за использование значений из диапазона Private Use и предотвращение конфликтов (в пределах своей зоны влияния).

Примеры:

специфические для сайта опции DHCP [RFC2939];

реестр Fibre Channel Port Type [RFC4044];

идентификаторы TLS ClientCertificateType из диапазона 224-255 [RFC5246].

4.2. Экспериментальное использование

Похожи на значения для приватного или локального применения, но предназначены для выполнения экспериментов. Более подробную информацию можно найти в [RFC3692]. IANA не записывает назначения из реестров и диапазонов этой категории (поэтому для них не нужен обзор IANA) и такие назначения обычно не важны с точки зрения глобальной совместимости. Если реестр явно не разрешает этого, для документов недопустимо выбирать явные значения из реестров или диапазонов на основе этой политики. Конкретные эксперименты выбирают для себя значения, применяемые в процессе экспериментирования.

Когда коды отведены для экспериментального использования, важно разъяснить предполагаемые ограничения сферы охвата для эксперимента. Например, можно указать, допустимы ли эксперименты с этими значениями в открытой сети Internet или их следует ограничивать замкнутыми средами. Пример этого можно найти в [RFC6994].

Пример:

экспериментальные значения в заголовках IPv4, IPv6, ICMPv4, ICMPv6, UDP и TCP [RFC4727].

4.3. Иерархическое распределение

Уполномоченные администраторы могут выделять значения в пределах находящейся под их контролем области пространства имен. IANA контролирует верхний уровень пространства имен в соответствии с одним из своих правил.

Примеры.

  • Имена DNS — IANA администрирует домены верхнего уровня (TLD6) и, как сказано в [RFC1591]:

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

  • Идентификаторы объектов, определенные в ITU-T X.208. В соответствии с <http://www.alvestrand.no/objectid/>, реестры включают:

    • IANA — назначение OID в ветви Private Enterprises (частные предприятия);

    • ANSI — назначение OID в ветви US Organizations;

    • BSI — назначение OID в ветви UK Organizations.

  • Пространства имен URN — IANA регистрирует идентификаторы URN для пространств имен (NID7 [RFC8141]), а получившая NID организация отвечает за назначение URN в своем пространстве имен.

4.4. Назначение в порядке очереди

Кто угодно может получить нужные значения в порядке подачи запросов. Здесь не требуется какого-либо рецензирования, за исключением проверки формальной корректности запроса и отсутствия дублирования. Запрос должен содержать минимальный объем информации, включающий сведения о контактах (в частности, адрес электронной почты) и краткое описание предполагаемого использования запрашиваемых значений. Также должна быть предоставлена дополнительная информация, специфичная для запрашиваемого типа, в соответствии с описанием пространства имен. Для чисел IANA обычно выделяет следующее по порядку значение, но могут быть запрошены и выделены иные значения при наличии смягчающих обстоятельств. Для текстовых строк запрашиваемые значения обычно указываются при запросе.

При создании нового реестра с политикой регистрации First Come First Served помимо поля или ссылки с контактными данными в реестр следует включать поле для контролера изменений. Наличие контролера для каждой записи этого типа делает полномочия внесения изменений в будущем более ясными (см. параграф 2.3).

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

Рабочая группа или иная организация, разрабатывающая протоколы с использованием кодов, назначенных по процедуре First Come First Served, должна быть очень осторожной, чтобы сохранить совместимость кодов в линии с уже выделенными кодами. Если это невозможно, новой работе следует перейти на использование иного кода (и зарегистрировать его использование в нужный момент).

Важно понимать, что процедура First Come First Served не имеет фильтрации и все корректно сформированные запросы выполняются.

Примеры:

имена механизмов SASL [RFC4422];

механизмы протокола LDAP и синтаксис LDAP [RFC4520].

4.5. Рецензия эксперта

Требуется рецензия и одобрение назначенного эксперта (см. раздел 5). Хотя формальное документирование этого не требуется, необходимо представить запрос для назначения эксперта, который оценит работу. В определении реестра нужно четко указать регистраторам, какая информация необходима. Фактический процесс запросов на регистрацию администрирует IANA (см. параграф 1.2).

Эта процедура в предыдущих версиях называлась Designated Expert, а текущее название — Expert Review.

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

При выборе процедуры Expert Review и подготовке рекомендаций для эксперта важно внимательно разобраться с разделом 5.

Хорошие примеры рекомендаций для назначенных экспертов приведены ниже.

Протокол EAP8 [RFC3748], раздел 6 и параграф 7.2

North-Bound Distribution of Link-State and TE Information Using BGP [RFC7752], параграф 5.1

При создании нового реестра с политикой Expert Review помимо поля или ссылки с контактными данными в реестр следует включать поле для контролера изменений. Наличие контролера для каждой записи этого типа делает полномочия внесения изменений в будущем более ясными (см. параграф 2.3).

Примеры:

EAP Method Types [RFC3748];

версии алгоритма HTTP Digest AKA [RFC4169];

схемы URI [RFC7595];

типы GEOPRIV Location [RFC4589].

4.6. Требование наличия спецификации

Для процедуры Specification Required требуется рецензия и одобрение назначенного эксперта (см. раздел 5), а значения и их трактовки должны быть документированы в постоянно и легко доступных публикациях с достаточным уровнем детализации для обеспечения совместимости независимых реализаций. Эта процедура совпадает с рецензированием экспертами (Expert Review), дополненным требованием выпуска спецификации. В дополнение к обычному обзору документа назначенный эксперт будет рецензировать открытую спецификацию, оценивая ее стабильность и доступность, а также четкость и техническую обоснованность для обеспечения совместимости независимых реализаций.

Слова «постоянно и легко доступны» означают, что документ можно будет найти и получить в течение достаточно продолжительного срока после того, как IANA выделит запрошенные значения. Публикация RFC является идеальным способом выполнения этих требований, однако процедура Specification Required может применяться не только к документам, опубликованным в форме RFC.

Для публикации RFC по-прежнему требуется формальная рецензия назначенного эксперта, но предполагается, что обычный процесс обзора RFC обеспечит необходимый уровень совместимости. Рецензия назначенного эксперта остается важной, но не менее важно отметить, что при наличии согласия IETF эксперт может быть чисто формальным (in the rough — см. также последний абзац параграфа 5.4).

Как и для процедуры Expert Review (параграф 4.5) следует предоставить четкие рекомендации для эксперта при определении реестра и важно разобраться с разделом 5.

При указании этой политики просто используется термин Specification Required. В некоторых спецификациях указывается «Expert Review with Specification Required» и это лишь вызывает путаницу.

Примеры:

идентификаторы Diffserv-aware TE Bandwidth Constraints Model [RFC4124];

идентификаторы TLS ClientCertificateType из диапазона 64-223 [RFC5246];

идентификаторы ROHC Profile [RFC5795].

4.7. Требование публикации RFC

Для политики RFC Required запрос регистрации и связанная с ним документация должны быть опубликованы в виде RFC. RFC не обязательно быть из потока IETF, это может быть любой поток RFC (в настоящее время IETF, IRTF, IAB, Independent Submission [RFC5742]).

Если не указано иное, подойдет RFC любого типа (например, Standards Track, BCP, Informational, Experimental, Historic).

Примеры:

номера алгоритмов DNSSEC DNS Security [RFC6014];

реестры Media Control Channel Framework [RFC6230];

использование сертификатов DANE TLSA [RFC6698].

4.8. Рецензия IETF

(Эта процедура называлась IETF Consensus в первой версии документа). В соответствии с политикой IETF Review новые значения выделяются только через RFC из потока IETF Stream, прошедших через IESG как AD-Sponsored или документы рабочих групп IETF [RFC2026] [RFC5378], прошедших процедуру IETF Last Call и одобренных IESG как имеющих согласие IETF.

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

Если не указано иное, подойдет RFC любого типа (например, Standards Track, BCP, Informational, Experimental, Historic).

Примеры:

типы алгоритмов IPSECKEY [RFC4025];

типы расширений TLS [RFC5246].

4.9. Стандартизация

Для политики Standards Action значения выделяются только через публикацию RFC серии Standards Track или Best Current Practice в потоке IETF.

Примеры:

типы сообщений BGP [RFC4271];

типы опций Mobile Node Identifier [RFC4283];

идентификаторы TLS ClientCertificateType из диапазона I0-63 [RFC5246];

типы пакетов DCCP [RFC4340].

4.10. Одобрение IESG

Новые назначения могут быть одобрены IESG. Хотя здесь отсутствует требование документирования запроса в RFC, IESG во своему усмотрению время от времени запрашивает документы или другие материалы в поддержку запроса.

Процедура IESG Approval не предназначена для частого использования или «общей практики», она применяется достаточно редко. Ее назначение заключается скорее в обеспечении совместно с другими процедурами запасного механизма на случай невозможности своевременно воспользоваться иной процедурой или при возникновении иных сложностей. Процедура IESG Approval не предназначена для обхода общественного рассмотрения, требуемого другими процедурами, для конкретного назначения. Однако эта процедура подойдет для тех случаев, когда желательна целесообразность и имеется согласованное мнение о выделении запрошенных значений (например, согласие рабочей группы).

До одобрения запроса IESG может провести консультации с сообществом путем запроса комментариев (call for comments), обеспечивающие как можно больше информации о запросе.

Примеры:

назначение адресов IPv4 Multicast [RFC5771];

значения типов и кодов IPv4 IGMP [RFC3228];

значения типов и опций заголовков Mobile IPv6 Mobility [RFC6275].

4.11. Использование общеизвестных правил регистрации

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

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

Например для регистрации типов носителей [RFC6838] учитывается множество разных ситуаций, которые включают процедуры IETF Review и Specification Required, а также имеются дополнительные критерии, которые следует принимать во внимание эксперту. Это предназначено не для представления процедуры регистрации, а в качестве примера того, что можно сделать при необходимости учесть другие обстоятельства.

Общеизвестные процедуры от «First Come First Served» до «Standards Action» задают диапазон правил с возрастающим уровнем сложности (указаны номера из полного списка в начале раздела 4).

4. First Come First Served

Без рецензирования с минимальной документацией.

5 и 6 (равносильны).

5. Expert Review

Рецензия эксперта с документацией, достаточной для рецензирования.

6. Specification Required

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

7. RFC Required

Публикация любого RFC (не обязательно в потоке IETF).

8. IETF Review

Публикация RFC в потоке IETF, но не обязательно Standards Track.

9. Standards Action

Публикация RFC в потоке IETF со статусом Standards Track или BCP.

Ниже приведены примеры ситуаций, когда может потребоваться процедура IETF Review или Standards Action.

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

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

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

При рассмотрении документов, запрашивающих у IANA создание нового реестра или изменении политики регистрации на более строгую, чем Expert Review или Specification Required, IESG следует запросить обоснование, позволяющее понять, были ли рассмотрены более мягкие процедуры и обоснована ли предложенная строгость.

Соответственно, разработчики документов должны предвидеть это и документировать свои соображения по выбору казанной политики (идеально сделать это в самом документе или в записке куратора работы). Куратор должен убедиться в обоснованности предлагаемой политики до передачи документа в IESG.

При пересмотре спецификации политику регистрации следует следует пересмотреть с учетом опыта применения существующей политики.

4.12. Использование комбинации нескольких процедур

В некоторых случаях необходимо определить несколько процедур регистрации. Например при регистрации в обычном процессе IETF иожет применяться одна процедура, а для регистрации извне — другая.

Таким образом, конкретный реестр может захотеть иногда применять процедуру RFC Required или IETF Review, а в других случаях назначенный эксперт использует Specification Required.

Альтернативой применению комбинации процедур является требование прохождения всех запросов через RFC или рецензирования запросов из RFC назначенными экспертами даже при наличии рецензии и согласия IETF.

Это можно указать в разделе IANA Considerations при описании создания рееста, как показано ниже.

У IANA запрашивается создание реестра «Fruit Access Flags» в группе «Fruit Parameters». Новые регистрации будут выполняться по процедуре IETF Review или Specification Required [BCP26]. Второй вариант следует применять лишь для регистраций, запрошенных SDO вне IETF. Регистрации, запрошенные в документах IETF обрабатываются по процедуре IETF review.

Такие комбинации обычно используют одну из процедур {Standards Action, IETF Review, RFC Required} вместе с одной из {Specification Required, Expert Review}. Следует предоставить рекомендации о применении каждой процедуры как в приведенном выше примере.

4.13. Временная регистрация

Политики некоторых имеющихся реестров разрешают временную регистрацию (см. схемы URI [RFC7595] и поля Email Header [RFC3864]). Регистрации, обозначенные как временные, обычно определяются как более легко создаваемые, изменяемые, переназначаемые или переводимые в другой статус. Схемы URI, например, позволяют выполнять временную регистрацию с неполной информацией.

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

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

5. Назначенные эксперты

5.1. Выбор экспертов

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

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

Зачастую полезно использовать назначенного эксперта лишь в качестве дополнения к другим процессам. Дополнительное рассмотрение этого вопроса приведено в параграфе 4.12.

5.2. Роль назначенного эксперта

Назначенный эксперт отвечает за инициирование и координацию подходящего обзора запроса на выделение. Широта обзора определяется ситуацией и мнением назначенного эксперта. Обзор может быть широким или узким в зависимости от ситуации и решения назначенного эксперта. Обзор может включать консультации с техническими специалистами, обсуждение в публичном списке рассылки, консультации с рабочей группой (или обсуждение в списке рассылки группы, если она уже распущена) и т. п. В идеальном случае назначенный эксперт следует конкретным критериям , документированным для протокола, который создает или будет использовать пространство имен. Примеры таких критериев можно найти в разделах «Согласование с IANA» (IANA Considerations) [RFC3748] и [RFC3575].

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

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

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

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

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

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

5.2.1. Управление назначенными экспертами в IETF

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

При возникновении конфликтов, связанных с назначенной группой экспертов применяется обычная процедура апелляции, описанная в параграфе 6.5.1 [RFC2026]. В таком случае назначенная группа экспертов считается рабочей группой.

5.3. Рецензии назначенных экспертов

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

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

  • Если назначенный эксперт не отвечает на запрос IANA в разумные сроки готовой рецензией или разумным объяснением причин задержки (например, сложность запроса) и это повторяется неоднократно, агентство IANA должно обозначить эту проблему в IESG. По причине проблем, вызываемых задержкой оценки и выделения значений, IESG следует принять адекватные меры, обеспечивающие гарантии понимания и принятия экспертом своей ответственности, или назначить другого эксперта.

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

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

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

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

  • Значения требуются для расширения протокола, но это расширение не согласуется с документированной (или понятной всем) архитектурой расширяемого базового протокола и будет мешать работе протокола при широком распространении. Несоответствия не являются «непреднамеренными», указывающими незначительные различия «на уровне личных предпочтений», и оказывают существенное влияние на безопасность, предполагают изменение семантики существующих типов сообщений или операций, требуют внесения необоснованных изменений в развернутые системы (по сравнению с другими путями достижения такого же результата) и т. п.

  • Расширения будут вызывать проблемы в работе развернутых систем.

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

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

Если запрос следует рассмотреть также в конкретном публичном списке рассылки, следует указать его адрес.

5.4. Рецензии экспертов и жизненный цикл документа

Рецензирование назначенным экспертом выполняется в определенный момент и представляет обзор конкретной версии документа. Хотя рецензирование обычно выполняется во время IETF Last Call, решение вопроса о времени рецензирования определяется здравым смыслом. В процессе рецензирования эксперт может узнать о существенном изменении документации для регистрируемого элемента и это требует внимательного и осторожного рассмотрения.

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

Для регистрация из документов Standards Track часто требуется одобрение эксперта (политика регистрации) в дополнение к согласию IETF (для утверждения Standards Track RFC). В таких случаях рецензия назначенного эксперта должна быть своевременной и поданной до оценки документа в IESG. Как правило, IESG не следует задерживать документ в ожидании запоздалого рецензирования. Кроме того, рецензия эксперта не предназначена для изменения решения IETF, поэтому IESG следует основываться на своей оценке, как это делается для других обзоров Last Call.

6. Терминология для общеизвестных правил

Ниже приведены значения статуса для регистрации значений или диапазонов.

Private Use — приватное использование

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

Experimental — эксперимент

Доступно для экспериментальных приложений, как описано в [RFC3692]. IANA не фиксирует выделение значений для каких-либо конкретных приложений.

Unassigned — не выделено

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

Reserved — резерв

Не распределено и недоступно для распределения. Резервные значения сохраняются для специальных целей типа расширения пространства имен по мере его исчерпания. Статус Reserved иногда применяется для значений, которые были выделены, но перестали использоваться, сохраняя их отложенными, пока имеются не распределенные значения. Отметим, что этот статус существенно отличается от Unassigned.

Резервные значения могут быть освобождены для распределения контролером изменений в реестре (это зачастую IESG для реестров, созданных RFC из потока IETF).

Known Unregistered Use — известное незарегистрированное применение

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

7. Ссылки на документы в реестрах IANA

Обычно реестры и записи в них включают ссылки на документацию (RFC или иные документы). Цель этих ссылок заключается в предоставлении разработчикам указателей для поиска требуемых в реализации деталей, а не просто в указании документа, создавшего реестр или запись. Поэтому следует соблюдать приведенные ниже рекомендации.

  • Если документ регистрирует элемент, определенный и описанный в другом месте, регистрируемой ссылке следует указывать документ с определением, а не документ, задающий регистрацию.

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

  • Если регистрируемый элемент описан большей частью в конкретном разделе документа, полезно указать этот раздел (например, параграф 3.2 в [RFC4637], а не просто [RFC4637]).

  • При документировании нового реестра в ссылке следует предоставлять информацию о самом реестре, а не просто указатель на его создание. Полезна будет информация о назначении реестра, мотивах его создания, документации о процессе и правилах регистрации, рекомендации для заявителей или назначенных экспертов и т. п. Однако следует отметить, что, несмотря на важность такой информации, ее не требуется полностью включать в раздел IANA Considerations (см. параграф 1.1).

8. Что нужно делать в документах «bis»

Время от времени выпускаются RFC, отменяющие предыдущую версию того же документа. Иногда их называют документами bis, например, как RFC 4637, отмененный документом draft-ietf-foo-rfc4637bis. Если в исходном документе был создан реестр и/или записи в реестре, возникает вопрос по части обработки раздела IANA Considerations в документе bis.

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

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

Например, если RFC 4637 регистрирует флаг BANANA в реестре Fruit Access Flags и документация для этого флага приведена в параграфе 3.2, текущий реестр может иметь вид

Значение

Описание

Ссылка

BANANA

Флаг для banana

[RFC4637], параграф 3.2

Если draft-ietf-foo-rfc4637bis отменяет RFC 4637 и в результате редактирования описание флага перенесено в параграф 4.1.2, раздел IANA Considerations документа bis может содержать текст вида:

У IANA запрашивается изменение регистрационной информации для флага BANANA в реестре Fruit Access Flags, как показано ниже.

Значение

Описание

Ссылка

BANANA

Флаг для banana

Данный RFC, параграф 4.1.2

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

Поскольку этот документ отменяет RFC 4637, у IANA запрашивается замена всех регистрационных записей, указывающих на [RFC4637], записями со ссылкой на [[данный RFC]].

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

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

9. Прочие вопросы

9.1. Когда участия IANA не требуется

До публикации документа Internet-Draft как RFC агентству IANA нужно знать, какие действия (если они есть) потребуются от него. Опыт показывает, что не всегда очевидно, нужны ли какие-то действия без детального обзора документа. Чтобы можно было четко видеть, что от IANA не требуется каких-либо действий (и автор осознает это), в документ следует включать раздел IANA Considerations (согласование с IANA), содержащий фразу:

This document has no IANA actions10.

IANA предпочитает сохранять такие «пустые» разделы IANA в документах для фиксации того, что в документе явно указано отсутствие требуемых от IANA действий (а не просто забыли их указать). Это отличается от прежней практики запроса удаления таких разделов редакторами RFC и авторам предлагается учитывать данное изменение.

9.2. Пространства имен без документированного руководства

For all existing RFCs that either explicitly or implicitly rely on IANA to make assignments without specifying a precise assignment policy, IANA will work with the IESG to decide what policy is appropriate. Changes to existing policies can always be initiated through the normal IETF consensus process, or through the IESG when appropriate.

All future RFCs that either explicitly or implicitly rely on IANA to register or otherwise administer namespace assignments must provide guidelines for administration of the namespace.

9.3. Регистрация «постфактум»

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

Это является одной из причин включения в параграф 3.1 рекомендации об использовании значений-заменителей (таких как TBD1) в процессе разработки документов. Проблемы зачастую возникают в результате открытого использования незарегистрированных значения после результатов успешных ранних реализаций, которые сохранили применявшиеся при разработке значения, не назначенные IANA.

9.4. Повторное заявление выделенных значений

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

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

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

  • Может оказаться целесообразным описать предлагаемые меры и запросить их оценку в соответствующем сообществе пользователей. В некоторых случаях может оказаться целесообразной подготовка соответствующего RFC и прохождение формальных процедур IETF (включая IETF Last Call), как было сделано при отзыве некоторых опций DHCP из числа зарезервированных для приватного использования (Private Use) [RFC3942].

  • Может оказаться полезным разделять отзыв, освобождение и перенос. Отзыв происходит, когда IANA удаляет назначение, освобождение происходит по инициативе правообладателя, а перенос — в тех случаях, когда отзыв или освобождение сопровождаются незамедлительным новым назначением. Полезным может быть указание процедур для каждого из этих случаев или явный запрет некоторых комбинаций.

9.5. Контактное лицо, правообладатель или владелец

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

Это важно, поскольку со временем человек может поменять работу или роль. Возможно, с ним уже нельзя связаться для обновления регистрации. IANA не имеет возможности узнать, какой компании, организации или человеку следует разрешить принять регистрацию. Для регистраций, основанных на RFC, владелец потока (такой как IESG или IAB) может принять решение о замене. Но в иных случаях некуда обратиться за помощью.

Реестры могут включать в дополнение к полю Contact поле Assignee (правообладатель) или Owner (владелец, которого называют также контролером изменений — Change Controller), которое может помочь при решении этой проблемы, давая IANA четкую информацию о фактическом владельце регистрации. Это настоятельно рекомендуется, особенно для регистраций, не требующих RFC для поддержки информации (т. е. для реестров с политикой First Come First Served — параграф 4.4, Expert Review — параграф 4.5 и Specification Required — параграф 4.6). Как вариант, организации могут указать себя в поле Contact, чтобы указать свое владение регистрацией.

9.6. Закрытие и отмена реестров и регистраций

Иногда возникают запросы на «закрытие» реестра для дальнейшей регистрации. В закрытых реестрах регистрация прекращается. Информация в реестре сохраняет свое действие и зарегистрированные ранее записи продолжают обновляться.

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

Конкретные записи реестра могут быть помечены как устаревшие (obsolete) и не используемые или как отмененные (deprecated), применение которых не рекомендуется.

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

10. Апелляции

Апелляции на регистрационные решения IANA можно подавать с использованием обычной процедуры апелляции IETF, описанной в параграфе 6.5 [RFC2026]. Т. е. пелляции следует направлять в IESG, а затем (при необходимости) в IAB.

11. Списки рассылки

Все списки рассылок IETF, связанные с оценкой или обсуждением запросов на выделение значений, как описано в этом документе, управляются в соответствии с правилами и методами, определенными в действующих документах BCP11 или решениях IESG.

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

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

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

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

Анализ вопросов безопасности в общем случае требуется для всех протоколов, применяющих параметры (типы данных, коды операций, ключевые слова и т. п.), документированные в протоколах IETF или зарегистрированные IANA. Обсуждение вопросов безопасности обычно включается в протокольные документы [BCP72]. Ответственность за обеспечение рассмотрения вопросов безопасности (если таковые имеются) при выделении новых значений и рецензирование такого рассмотрения ложится на IANA при рассмотрении соответствующих вопросов выделения значений.

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

Агентство IANA заменило все ссылки на RFC 5226 ссылками на этот документ.

14. Отличия от прежних версий BCP 26

14.1. 2016 — отличия этого документа от RFC 5226

Ниже перечислены существенные дополнения, внесенные в новую версию.

  • Удалены ключевые слова, шаблоны и ссылка на RFC 2119. Это простой текст, а не спецификация протокола.

  • Добавлен параграф 1.1. Раздел IANA Considerations предназначен для IANA.

  • Добавлен параграф 1.2. Обновление информации.

  • Добавлен параграф 2.1. Организация реестров.

  • Добавлено обобщение опыта для выбора подходящей политики в раздел 4.

  • Добавлен параграф 4.12. Использование комбинации нескольких процедур.

  • Добавлен параграф 2.3. Указание контроля изменений для реестра.

  • Добавлен параграф 3.4. Раннее выделение значений.

  • Все общеизвестные правила перенесены в отдельные параграфы раздела 4.

  • Добавлен параграф 5.4. Рецензии экспертов и жизненный цикл документа.

  • Добавлен раздел 7. Ссылки на документы в реестрах IANA.

  • Добавлен раздел 8. Что нужно делать в документах «bis».

  • Добавлен параграф 9.5. Контактное лицо, правообладатель или владелец.

  • Добавлен параграф 9.6. Закрытие и отмена реестров и регистраций.

Внесены разъяснения и иные правки:

  • некоторые части текста перемещены для ясности и удобочитаемости;

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

  • разъяснены различия между Unassigned и Reserved;

  • в параграф 4.5. Рецензия эксперта внесены разъяснения по поводу инструкций для эксперта;

  • в параграф 4.6. Требование наличия спецификации внесены разъяснения по части объявления политики;

  • внесены разъяснения и незначительные правки по всему тексту.

14.2. 2008 — отличия RFC 5226 от RFC 2434

Ниже перечислены основные изменения, внесенные в RFC 5226.

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

  • Многочисленные редакторские правки для удобочитаемости.

  • Название процедуры IETF Consensus (согласие IETF) заменено на IETF Review (рецензия IETF) и приведены дополнительные разъяснения. Опыт показывает, что люди, увидев слова IETF Consensus (и не глядя на определение этой процедуры) делают некорректное допущение о значении их в контексте IANA Consideration.

  • В список определенных правил добавлено RFC Required (требуется публикация RFC).

  • Существенно более явные указания и примеры того, что «следует включать в RFC».

  • Правило Specification Required (требуется спецификация) сейчас предполагает использование назначенных экспертов (Designated Expert) для оценки ясности спецификаций.

  • Добавлено описание временных регистраций.

  • Существенно изменено содержание раздела «Назначенные эксперты». Основной целью изменений служило указание того, что рецензенты несут ответственность перед сообществом, а также предоставление некоторых рекомендаций по критериям рецензирования в типичных случаях.

  • Изменен текст с целью удаления каких-либо специальных путей для апелляций. Используется описанный в RFC 2026 путь апеллирования.

  • Изменен текст с целью удаления каких-либо специальных путей для апелляций. Используется описанный в RFC 2026 путь апеллирования.

  • Добавлен раздел об отзыве неиспользуемых значений.

  • Добавлен параграф «Регистрация постфактум».

  • Добавлен раздел, указывающий, что почтовые рассылки, используемые для оценки возможности выделения значений (например, назначенным экспертом), подчиняются обычным правилам IETF.

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

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

[RFC2026] Bradner, S., «The Internet Standards Process — Revision 3», BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996, <http://www.rfc-editor.org/info/rfc2026>.

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

[BCP72] Rescorla, E. and B. Korver, «Guidelines for Writing RFC Text on Security Considerations», BCP 72, RFC 3552, July 2003, <http://www.rfc-editor.org/info/bcp72>.

[RFC791] Postel, J., «Internet Protocol», STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.

[RFC1591] Postel, J., «Domain Name System Structure and Delegation», RFC 1591, DOI 10.17487/RFC1591, March 1994, <http://www.rfc-editor.org/info/rfc1591>.

[RFC2434] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», RFC 2434, DOI 10.17487/RFC2434, October 1998, <http://www.rfc-editor.org/info/rfc2434>.

[RFC2860] Carpenter, B., Baker, F., and M. Roberts, «Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority», RFC 2860, DOI 10.17487/RFC2860, June 2000, <http://www.rfc-editor.org/info/rfc2860>.

[RFC2939] Droms, R., «Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types», BCP 43, RFC 2939, DOI 10.17487/RFC2939, September 2000, <http://www.rfc-editor.org/info/rfc2939>.

[RFC3228] Fenner, B., «IANA Considerations for IPv4 Internet Group Management Protocol (IGMP)», BCP 57, RFC 3228, DOI 10.17487/RFC3228, February 2002, <http://www.rfc-editor.org/info/rfc3228>.

[RFC3575] Aboba, B., «IANA Considerations for RADIUS (Remote Authentication Dial In User Service)», RFC 3575, DOI 10.17487/RFC3575, July 2003, <http://www.rfc-editor.org/info/rfc3575>.

[RFC3692] Narten, T., «Assigning Experimental and Testing Numbers Considered Useful», BCP 82, RFC 3692, DOI 10.17487/RFC3692, January 2004, <http://www.rfc-editor.org/info/rfc3692>.

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., «Extensible Authentication Protocol (EAP)», RFC 3748, DOI 10.17487/RFC3748, June 2004, <http://www.rfc-editor.org/info/rfc3748>.

[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <http://www.rfc-editor.org/info/rfc3864>.

[RFC3942] Volz, B., «Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options», RFC 3942, DOI 10.17487/RFC3942, November 2004, <http://www.rfc-editor.org/info/rfc3942>.

[RFC3968] Camarillo, G., «The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)», BCP 98, RFC 3968, DOI 10.17487/RFC3968, December 2004, <http://www.rfc-editor.org/info/rfc3968>.

[RFC4025] Richardson, M., «A Method for Storing IPsec Keying Material in DNS», RFC 4025, DOI 10.17487/RFC4025, March 2005, <http://www.rfc-editor.org/info/rfc4025>.

[RFC4044] McCloghrie, K., «Fibre Channel Management MIB», RFC 4044, DOI 10.17487/RFC4044, May 2005, <http://www.rfc-editor.org/info/rfc4044>.

[RFC4124] Le Faucheur, F., Ed., «Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering», RFC 4124, DOI 10.17487/RFC4124, June 2005, <http://www.rfc-editor.org/info/rfc4124>.

[RFC4169] Torvinen, V., Arkko, J., and M. Naslund, «Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA) Version-2», RFC 4169, DOI 10.17487/RFC4169, November 2005, <http://www.rfc-editor.org/info/rfc4169>.

[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., «A Border Gateway Protocol 4 (BGP-4)», RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.

[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, «Mobile Node Identifier Option for Mobile IPv6 (MIPv6)», RFC 4283, DOI 10.17487/RFC4283, November 2005, <http://www.rfc-editor.org/info/rfc4283>.

[RFC4340] Kohler, E., Handley, M., and S. Floyd, «Datagram Congestion Control Protocol (DCCP)», RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.

[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., «Simple Authentication and Security Layer (SASL)», RFC 4422, DOI 10.17487/RFC4422, June 2006, <http://www.rfc-editor.org/info/rfc4422>.

[RFC4446] Martini, L., «IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)», BCP 116, RFC 4446, DOI 10.17487/RFC4446, April 2006, <http://www.rfc-editor.org/info/rfc4446>.

[RFC4520] Zeilenga, K., «Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP)», BCP 64, RFC 4520, DOI 10.17487/RFC4520, June 2006, <http://www.rfc-editor.org/info/rfc4520>.

[RFC4589] Schulzrinne, H. and H. Tschofenig, «Location Types Registry», RFC 4589, DOI 10.17487/RFC4589, July 2006, <http://www.rfc-editor.org/info/rfc4589>.

[RFC4727] Fenner, B., «Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers», RFC 4727, DOI 10.17487/RFC4727, November 2006, <http://www.rfc-editor.org/info/rfc4727>.

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

[RFC5378] Bradner, S., Ed. and J. Contreras, Ed., «Rights Contributors Provide to the IETF Trust», BCP 78, RFC 5378, DOI 10.17487/RFC5378, November 2008, <http://www.rfc-editor.org/info/rfc5378>.

[RFC5742] Alvestrand, H. and R. Housley, «IESG Procedures for Handling of Independent and IRTF Stream Submissions», BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <http://www.rfc-editor.org/info/rfc5742>.

[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, «IANA Guidelines for IPv4 Multicast Address Assignments», BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>.

[RFC5795] Sandlund, K., Pelletier, G., and L-E. Jonsson, «The Robust Header Compression (ROHC) Framework», RFC 5795, DOI 10.17487/RFC5795, March 2010, <http://www.rfc-editor.org/info/rfc5795>.

[RFC6014] Hoffman, P., «Cryptographic Algorithm Identifier Allocation for DNSSEC», RFC 6014, DOI 10.17487/RFC6014, November 2010, <http://www.rfc-editor.org/info/rfc6014>.

[RFC6230] Boulton, C., Melanchuk, T., and S. McGlashan, «Media Control Channel Framework», RFC 6230, DOI 10.17487/RFC6230, May 2011, <http://www.rfc-editor.org/info/rfc6230>.

[RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, «Mobility Support in IPv6», RFC 6275, DOI 10.17487/RFC6275, July 2011, <http://www.rfc-editor.org/info/rfc6275>.

[RFC6698] Hoffman, P. and J. Schlyter, «The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA», RFC 6698, DOI 10.17487/RFC6698, August 2012, <http://www.rfc-editor.org/info/rfc6698>.

[RFC6709] Carpenter, B., Aboba, B., Ed., and S. Cheshire, «Design Considerations for Protocol Extensions», RFC 6709, DOI 10.17487/RFC6709, September 2012, <http://www.rfc-editor.org/info/rfc6709>.

[RFC6838] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <http://www.rfc-editor.org/info/rfc6838>.

[RFC6895] Eastlake 3rd, D., «Domain Name System (DNS) IANA Considerations», BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, <http://www.rfc-editor.org/info/rfc6895>.

[RFC6994] Touch, J., «Shared Use of Experimental TCP Options», RFC 6994, DOI 10.17487/RFC6994, August 2013, <http://www.rfc-editor.org/info/rfc6994>.

[RFC7120] Cotton, M., «Early IANA Allocation of Standards Track Code Points», BCP 100, RFC 7120, DOI 10.17487/RFC7120, January 2014, <http://www.rfc-editor.org/info/rfc7120>.

[RFC7564] Saint-Andre, P. and M. Blanchet, «PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols», RFC 7564, DOI 10.17487/RFC7564, May 2015, <http://www.rfc-editor.org/info/rfc7564>.

[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, «Guidelines and Registration Procedures for URI Schemes», BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, <http://www.rfc-editor.org/info/rfc7595>.

[RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, «North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP», RFC 7752, DOI 10.17487/RFC7752, March 2016, <http://www.rfc-editor.org/info/rfc7752>.

[RFC8141] Saint-Andre, P. and J. Klensin, «Uniform Resource Names (URNs)», RFC 8141, DOI 10.17487/RFC8141, April 2017, <http://www.rfc-editor.org/info/rfc8141>.

Благодарности за этот документ (2017)

Thomas Narten и Harald Tveit Alvestrand редактировали две первых версии этого документа (RFC 2434 и RFC 5226), а Thomas продолжил эту работу и с данной версией. Значительная часть текста RFC 5226 сохранена в этом издании.

Спасибо Amanda Baber и Pearl Liang за их многочисленные рецензии и предложения, сделавшие документ лучше.

Для документа были полезны внимательные обзоры и комментарии многих людей, включая Benoit Claise, Alissa Cooper, Adrian Farrel, Stephen Farrell, Tony Hansen, John Klensin, Kathleen Moriarty, Mark Nottingham, Pete Resnick и Joe Touch.

Отдельная благодарность Mark Nottingham за реорганизацию части текста в плане удобочитаемости, Tony Hansen за присмотр, а также Brian Haberman и Terry Manderson за спонсорство.

Благодарности из второго издания (2008)

Ниже приведен раздел благодарностей из RFC 5226.

В этот документ внесли существенный вклад отклики Jari Arkko, Marcelo Bagnulo Braun, Brian Carpenter, Michelle Cotton, Spencer Dawkins, Barbara Denny, Miguel Garcia, Paul Hoffman, Russ Housley, John Klensin, Allison Mankin, Blake Ramsdell, Mark Townsley, Magnus Westerlund, Bert Wijnen.

Благодарности из первого издания (1998)

Ниже приведен раздел благодарностей из RFC 2434.

Jon Postel и Joyce K. Reynolds подробно объяснили, что требуется IANA для эффективного управления распределением значений и терпеливо комментировали многочисленные варианты этого документа. Brian Carpenter внес полезные комментарии к ранним версиям документа. Один абзац раздела «Вопросы безопасности» был заимствован из RFC 204812.

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

Michelle Cotton

PTI, an affiliate of ICANN

12025 Waterfront Drive, Suite 300

Los Angeles, CA 90094-2536

United States of America

Phone: +1-424-254-5300

Email: michelle.cotton@iana.org

URI: https://www.iana.org/

Barry Leiba

Huawei Technologies

Phone: +1 646 827 0648

Email: barryleiba@computer.org

URI: http://internetmessagingtechnology.org/

Thomas Narten

IBM Corporation

3039 Cornwallis Ave., PO Box 12195 — BRQA/502

Research Triangle Park, NC 27709-2195

United States of America

Phone: +1 919 254 7798

Email: narten@us.ibm.com


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

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

nmalykh@gmail.com

1Internet Assigned Numbers Authority.

2Internet Engineering Task Force.

3Internet Engineering Steering Group.

4IANA Functions Operator — оператор функций IANA.

5IANA PROTOCOL PARAMETER SERVICES Operator.

6Top-level domain.

7Namespace ID.

8Extensible Authentication Protocol — расширяемый протокол аутентификации.

9Area Director.

10Для этого документа не требуется действий IANA.

11Best Current Practice — обмен опытом.

12В оригинале ошибочно указан RFC 4288. См. https://www.rfc-editor.org/errata/eid5772. Прим. перев.